How Chipotle, Pinkberry, and others win big by doing just a few things well - <AUTHOR> http://37signals.com/svn/posts/2007-how-chipotle-pinkberry-and-others-win-big-by-doing-just-a-few-things-well <comment><USER2> Taco Bell has at least fifty menu items (not to mention their multi-brand restaurants). In-N-Out has, well, burgers, fries, shakes and soft drinks.

Okay, In-N-Out does a great job. But a Taco Bell kitchen is about the same size, yet produces a substantially larger menu.

How do they pull it off? Middleware. At In-N-Out, they make food out of potatoes, buns and refrigerated beef. At Taco Bell, they make food out of ingredient bags which are processed and packaged off-site. In-N-Out is something that a chef can respect -- Taco Bell is not.

But it's worth pointing out that In-N-Out can thrive only because their market doesn't demand a wide-ranging product. Sometimes markets move in that direction, and the artisans -- who cannot abide using middleware, who want to make everything to their high standards -- have a hard time competing.

<comment><USER3> But every In-N-Out I've ever been to has a line out the door. Taco Bell may have a larger menu but I doubt they have anywhere near the per-store revenues or profit margin of an In-N-Out.

<comment><USER4> > But every In-N-Out I've ever been to has a line out the door.

That could also be explained by the fact that there are far less In-N-Out locations than Taco Bell, so one store has to handle demand from over a larger area than Taco Bells.

If In-N-Out has the same density of locations as a Taco Bell, the per-store revenues will be quite different.

<comment><USER3> Sure but lets put it in context of this article. If I were looking to open one fast food franchise, I'd much rather be in the In-N-Out, do one thing well camp then Taco Bell's give them anything world.

(this isn't to say Taco Bell's business is poor, I'd just rather do what In-N- Out does)

<comment><USER4> Taco Bell is also pretty successful, and that contradicts the article. Other contradictory examples are Olive Garden and The Cheesecake Factory, both of which have extensive menus and are wildly succesful, the latter also having the same scarcity dynamics and lines as In-N-Out.

Articles like this are annoying. There are multiple ways to success, and presenting one as clearly better than others when there are so many counterexamples is disingenuous.

In-N-Out has a simple menu, above average ingredient quality, and treats their workers pretty well. All great qualities. But it's pretty evident, especially when it comes to food, that you can be bad in all those areas and still be successful, and perhaps even outcompete those who are better than you, if you focus on price and consistency, even if the thing you're consistent at is being mediocre.

</comment></comment></comment></comment></comment><comment><USER5> I'm starting to feel like this advice isn't so great anymore.

Everyone is trying to do less and what we end up with is a million little apps that do one thing really well, which is great, but you're still dealing with a million separate apps. The iPhone wasn't just a really great phone, it was a phone, an iPod, and an 'Internet Communicator' but because those things were combined in such a great package it really spoke to people and made it something they would want. Of course the App Store is what is driving the popularity now but that is still because customers can come to one place, the iPhone, and get tons of different uses out of their one device.

I think we're starting to enter an era where users are more interested in packages of functionality that are easy to use and work really well over a bunch of tiny solutions.

Maybe I'm wrong, but I know that I prefer products/applications that let me do lots of things reasonably well in one place instead of getting the 'perfect' thing for each problem I have.

What do you think?

<comment><USER6> You may need to factor in the "minimal viable product." A few years ago, an mp3 player could be consider enough for a high-end (read non-knockoff) product. However, fast forward a few years and you now need a mp3 player, video player, and app store driven device.

So I think you need to factor in the minimum requirements of the device (or foodchain) and then execute with the highest level of quality.

</comment></comment><comment><USER7> "Simple" as a discussion-starter? Great. "Simple" as a universal prescription? Maybe not.

Chipotle thrives on its simple offering; Cheesecake Factory thrives on its deep menu.

Larry Ellison fought against the "best of breed" concept to promote a unified Oracle Applications. A Cheesecake Factory style package.

The argument for "complex" is that once you've earned the trust of a customer, you can provide the spectrum of products/services that customer needs. You can be counted on to pick up all dropped balls.

(But maybe there is a completely pointless complexity - proliferation of marginal features - which we can simply avoid.)

The only reliable guide is complete focus on the customer's needs.

</comment><comment><USER8> I'm not so sure that the Nintendo Wii should be considered as a good example for this sort of thing anymore.

They _had_ won big with the Wii, turning profits on each console sold while the competition lost with each sale. But now they're facing the problem with the Wii being abandoned in households rather quickly and the decrease in software sales that brings.

DS aside, can Nintendo really be considered as a company that does few things well when the longevity of 1/2 their flagship lineup is in jeopardy?

<comment><USER9> >> "But now they're facing the problem with the Wii being abandoned in households rather quickly and the decrease in software sales that brings."

First I've heard of it, can you point to anything to back that up?

<comment><USER8> Here are some software sales stats for the past 3 years. The Wii has shown strong sales so far but has plateaued this year: <http://www.gamasutra.com/php-bin/news_index.php?story=25740> (though it could be due to lack of meaningful choice this year in comparison to last year, not due to abandonment)

Admittedly my remark about the console being abandoned quickly was a hasty generalization. I took into account some reports from 2007 that questioned the longevity of the Wii and had gathered the percentage of people in Japan that used the system frequently. That and experiences my friends and others I know online have had with their Wiis.

<http://games.ign.com/articles/827/827313p1.html>

</comment></comment></comment><comment><USER10> In-N-Out in California reinforces this very well.

<comment> brown9-2 Same thing with Five Guys (not sure if they've spread beyond the East Coast).

Very simple menus seems to be a hot trend recently.

<comment><USER11> They've recently made it to Colorado.

<comment><USER12> Really? I don't see any on <http://www.in-n-out.com/locations.asp>, and none came up when I searched for various cities.

<comment><USER13> They're talking about Five Guys.

</comment></comment></comment></comment></comment><comment><USER14> This was also true for Domino's Pizza back when they began to take off like a rocket: a very limited menu, and low delivery time.

</comment><comment><USER15> Sure, and other companies win big by doing lots of things. Still worth restating though that doing 1 thing well can work great.

<comment><USER16> Like most 37signals articles, this presents a platitude backed by two examples. There are thousands of companies that succeed with the opposite strategy, and thousands that do something simple and fail.

It's not even clear that Pinkberry succeeded because of its small product offering or due to some other factor. In fact, the first time I heard about it, a fan was raving about the incredible selection of toppings to choose from.

A whole economics thesis could be dedicated to a controlled study of which strategy is actually preferable. This being the internet, simple narratives tend to win over rigorous results.

<comment><USER7> Can you suggest any way of gaining a broader perspective? Both companies mentioned in the article are B2C and highly visible. They may have "visual punch" outweighing their "economic punch".

How can we get a broader, more realistic picture of what's really happening in the economy?

</comment></comment></comment><comment><USER17> This is a typical exapmle of market focus and niching based on focusing on core competency.

</comment><comment><USER18> It's no surprise 37signals is based in Chicago (I just did a whois) if they think Chipotle does Mexican food "well".

<comment><USER19> Chipotle is a national chain that is highly-profitable. Consider it the Starbucks of Mexican food. Not as good as the "local" place, but consistently okay everywhere you go.

<comment><USER18> Why consider it the Starbucks of Mexican when it's owned by McDonald's, a better example than any of the companies mentioned thus far.

<comment><USER20> McDonald's bought into it early, expanded it, then spun it off as an IPO. They don't own a majority stake (if any of it) anymore.

<comment><USER21> They got involved because the first Chipotle was right near the McDonald's corporate offices in Denver -- the executives were eating there so much, they bought into the company!

</comment></comment></comment></comment></comment><comment><USER22> I tried Chipotle once: I'd rather eat a piece of rug.

But maybe if they get everyone to try it _once_ as I did, that will define success?

<comment><USER23> i think chipotle is delicious. it is the mcdonald's of mexicali

<comment><USER12> Somewhat literally: McDonalds holds a huge stake in Chipotle. Except Chipotle is way healthier and works better than most fast food joints.

<comment><USER24> McDonalds holds no stake at all in Chipotle. They did a ways back, but spun it off onto its own through an IPO and divested all shares.</comment></comment></comment></comment>


Brake lights sensitive to braking force - <AUTHOR> http://blog.pedro.si/brake-lights-sensible-to-braking-force

<comment><USER2> I've seen some semi-trucks that have something like this (except it was simpler in that it was a straight light that would grow from the inside out), but do you really need them? If you just leave enough space in between you and the person in front you will never have a problem. Plus, it already is a pain to change out bulbs in some of these newer cars... I would hate for it to get harder (and more expensive).

<comment><AUTHOR> Many crashes are caused by the lack of such lights. And if such a system can be implemented at low cost (which it is), then why not use it? A saved life is worth more that the implementation cost.

Maybe it can be at least partially be achieved with LED lights that last many years and don't break easily, if at all. Anyways I have the impression that the quality of light bulbs has increased a lot since the burst of the auto industry.

</comment></comment><comment><USER3> It exists already -

[http://www.usautoparts.net/bmw/technology/brake_force_displa...](http://www.usautoparts.net/bmw/technology/brake_force_display.htm)

<http://www.google.com/search?q=break+force+display+bmw>

</comment><comment><USER4> Had this discussion with a friend 13 years ago in college. Didn't know how get it to market and IIRC my friend found someone else had a patent on it.

</comment><comment><USER5> I completely agree. In 2008, some students actually made this already: <http://www.physorg.com/news125773212.html>

I wrote about it back then (in Dutch, <http://micheljansen.org/blog/entry/471>) and at that time, there were some laws preventing this from really catching on. I guess those have been changed in the mean time?

</comment><comment><USER6> This is a really useful idea and gives useful more fine-grained information without compromising the overall message: "I'm slowing down."

Along a similar vein, I want car horns to be as loud inside a car as they are outside, to ensure they're _only_ used for emergencies. I live in a city and car horns dramatically reduce quality of life because "no honking, $350 penalty" are never actually enforced by the police.

<comment><USER7> Re: honking. Don't travel to SE Asia; you'll be horrified.

</comment></comment><comment><USER8> Funny, a very similar idea was discussed here a couple of months ago, when jgrahamc mentioned it was idea 999 in one of his ideas notebooks: <http://blog.jgc.org/2010/10/1000-bad-ideas.html>

Here's the discussion: <http://news.ycombinator.com/item?id=1779339>

</comment><comment><USER9> I suspect this is one of those cool ideas that in practice doesn't work so well, unfortunately.

But increasing brake light intensity overall on new cars or replacement brake lamps would increase safety even though old cars might have weaker brake lights. Essentially an "Omigod!" mode.

</comment><comment><USER10> Best one I ever saw was at Carnegie Mellon. They integrated this onto a CAN bus and were in talks with Bosch.

<http://www.ece.cmu.edu/~ece549/spring10/team7/index.html>

</comment><comment><USER11> I remember reading about a similar concept by Citroen I think about 15 years ago. The brake lights would be a much pinker shade if the brakes were applied sharply.

</comment><comment><USER12> Strong braking normally == hazard lights + brake lights on new cars.

It's quicker to recognise than a graded red brake light.

</comment><comment><USER13> If you are close enough behind to really tell the difference you are probably already too close.

<comment><AUTHOR> That's what the blue 'max deceleration' border is necessary. At least it makes it easier to see it from further away.

Maximum deceleration values of a car are about up to 1G for normal cars (found the data on an unofficial forum, so it may not be right)

Suppose a car in front of you brakes slowly, but for some reason you press harder the pedal, say to a deceleration of -5ms^-2 (1/2 G). Suppose a town with speed limit of 50km/h, and you and all cars drive at max speed. Suppose an initial car separation of 20m. If you do the calculations, you'll see that it will take less than 3 seconds for the back car to crash your car end. 3 secs sounds like a lot in reaction time, but the driver may be distracted, which may make him notice your braking a bit later, but not too late to apply appropriate braking and causing a car on his end.

</comment></comment><comment><USER12> s/sensible/sensitive/;

<comment><AUTHOR> Thanks for the notice. I fixed it.

</comment></comment><comment><USER14> The new Ford Mustangs have a kit you can install that does just that. I thought about this a few years back and want it so bad!</comment>


New equation might unite quantum mechanics and general relativity - <AUTHOR> http://www.sciencealert.com/this-new-equation-might-finally-unite-the-two-biggest-theories-in-physics-says-physicist <comment><AUTHOR> Paper is here: [http://arxiv.org/pdf/1604.02589v2.pdf](http://arxiv.org/pdf/1604.02589v2.pdf)</comment>


The economics of awful blockbuster movies - <AUTHOR> http://qz.com/102902/the-economics-of-awful-blockbuster-movies/

<comment><USER2> This article seems to imply that there used to be some sort of highly intellectual, dialogue driven summer blockbuster that we're moving away from as a direct result of them not translating well to non-English speaking audiences. Off the top of my head, I can't think of a single "intellectual" summer blockbuster even years and years ago (maybe Forrest Gump?).</comment>


This Guy's Wife Got Cancer, So He Did Something Unforgettable.  - <AUTHOR> http://www.viralnova.com/wifes-cancer/ <comment><USER2> Maybe link directly to the guy's site, instead of some random content aggregator:

[http://mywifesfightwithbreastcancer.com/](http://mywifesfightwithbreastcancer.com/)

<comment><USER3> Thank you. I read the article, looked at the pictures, and when I got to the end with the "Like us on Facebook!" crap it it cheapened everything.

The traffic needs to go to the source page, not this bottom-feeder site.

</comment></comment><comment><USER4> Very touching. My own wife (at 33) was diagnosed with breast cancer this year, but I feel almost guilty to say everything turned out okay (we believe).

The disease is a motherfucker. I can't imagine watching someone I love going through the later stages, unable to protect them.

Now back to my regularly scheduled trolling.

<comment><USER5> Don't feel guilty. It's stories like yours that give other people hope that breast cancer can be and will be beaten. Thank you for sharing.

</comment></comment><comment><USER6> At a previous job, I helped out on the web side for a photojournalist who spent a year documenting a mom and her young son's last year fighting cancer.

[http://www.pulitzer.org/archives/8358](http://www.pulitzer.org/archives/8358)

I saw those photos countless times up to production, and even years later when I come across them (the project won a Pulitzer and so is occasionally linked to today) I'll still tear up. It's funny that the blogspam title for the OP says the "The Last 3 Photos Destroyed Me"...In photoseries like these, I always find the photos of the patients struggling to live yet knowing the end is near to be much more heartwrenching than photos after the death.

<comment><USER7> God...

what can I say? Disease is such a sad part of humanity. What a shame we can't eradicate it. People are having so many children in poorer parts just because they know not many will make it, from either disease or poverty, thinning out our resources even further. When will it stop?

When will captialism be thrown under the rug so that real medical and scientific progress can erupt?

</comment></comment><comment><USER8> This touches a personal chord. My dad recently died of IPF and while its not in the same category as cancer I'd say its a terrible journey to have a disease that literally takes your breath away, and not in a good way.

I personally understood how support systems fail, how folks would rather always hear that you are getting better but with IPF - you only get worse. IPF is as common in the US as breast cancer, the difference being that it is 100% fatal in 2-5 years on average. (Lung transplants can improve longevity but eventually fail)

This person's story is deeply meaningful and told in a profoundly beautiful way. I wish I could tell my dad's story with IPF in a similar way. I'm trying to spread awareness with a blog on IPF and by donating to the pulmonary fibrosis foundation, just wondering about what else I could do. Awareness is super important!

IPF - Idiopathic Pulmonary Fibrosis - [http://en.m.wikipedia.org/wiki/Idiopathic_pulmonary_fibrosis](http://en.m.wikipedia.org/wiki/Idiopathic_pulmonary_fibrosis)

</comment><comment><USER9> What bothers me the most about this article, the charity work, the pink ribbons.

We have no idea what causes cancers, particularly breast cancer, in those who are young. We know some people carry risk factors (BRCA1 and BRCA2, certain subvariations of each) in their genes, and yet not all cases of people with the genes will get cancer, and not all people who get cancer young have any gene (in fact, most don't).

We also don't know why some cancers metastasized and some don't. Most women who get breast cancer at her age (39-40) survive.

I say this as someone who is extremely high risk (high enough that I have not hit thirty and I'm hunting for a new breast specialist who can get me MRIs instead of mammograms). I'd like to be able to know what to cut out to decrease my risk, beyond generic eat right and exercise (and I do eat right and exercise). I'm a tad angry that information is not available to me (I've looked). Because on a personal level, I'd like to stop seeing younger cancer cases.

</comment><comment><USER10> It's upon seeing things like this I wonder what I'm doing with my life. Am I really making the world a better place? Am I really making life better? With software? I feel I have so much but have really and truly contributed back so little.

</comment><comment><USER11> These pictures are beautiful, and I wish I had thought of doing this as well. As someone who has seen this disease run its course on a loved one, they brought back a lot of memories. Especially the effect chemo and a mastectomy usually has on that someone and their family. From losing their hair to having a swollen face due to retention of water, to being bedbound etc. The last 3 pictures are unfortunately all too familiar.

</comment><comment><USER12> as someone who had a family member taken by cancer, i cried at the last 3 photos. thanks for sharing this.

</comment><comment><USER13> I just can't imagine what it would be to suffer from a cancer. This is a horrible thing. A lot of pills and a lot of radiation treatment and watching yourself getting ___. I just can't even think about it. Rest in peace and I hope your husband will be happier now.

</comment><comment><USER14> Very touching. I took some similar pictures of my mom as she fought pancreactic cancer, and of the emptiness she left on rooms and objects.

I find that contemplating the pain in this straightforward way prevents it from growing into some kind of monster in your memories.

</comment><comment><USER15> Very depressing. These pictures may serve some purpose but I'd rather avoid anything that would reminds me of this horrible disease.

<comment><USER16> I do understand your reaction. However, the fact that he can extract such beauty from utter despair is a testament to the human spirit. It might not be uplifting in a simple sense and it might not serve some immediate tangible purpose (raise money/awareness perhaps ?) but I did feel the series was worthwhile and deserving of attention.

</comment></comment><comment><USER17> I guess all that above ground nuclear testing wasn't all that great an idea...

</comment><comment><USER18> I cried when I made it to the last photo.

<comment><USER19> [http://cdn.viralnova.com/wp- content/uploads/2013/10/11-T86Pc...](http://cdn.viralnova.com/wp- content/uploads/2013/10/11-T86Pc6I.jpg)

I think that photo did it for me. Just the contrast between people with a smile on their face going about their everyday life, and someone a few feet away fighting for their life.

</comment></comment><comment><USER20> That...physically hurt to read.

</comment><comment><USER21> This is "news.ycombinator.com", not "www.reddit.com".

Far too many of these posts lately.</comment>


Top Algorithms in Data Mining (2008) [pdf] - <AUTHOR> http://www.cs.uvm.edu/~icdm/algorithms/10Algorithms-08.pdf <comment><USER4> Wow this paper is great. Back in November, I implemented the "Trend or No Trend: A Novel Nonparametric Method for Classifying Time Series"[1] paper in node.js and then I hooked it up to Twitters API. The algorithm was able to find trending topics pretty quickly and accurately. Does anyone know if the source for these algorithms is implemented anywhere?

[1] - [http://dspace.mit.edu/bitstream/handle/1721.1/85399/87030495...](http://dspace.mit.edu/bitstream/handle/1721.1/85399/870304955.pdf)

<comment><USER5> These algorithms are implemented in just about every major language, as they are standard tools. I'd say your best bet for leveraging them is python scikit learn (super good documentation)

</comment></comment><comment><USER6> I'm surprised that there aren't any PCA/Feature-Extraction/Dimension-Reduce algos on this list. And there's also a really strong emphasis on clustering and classification.

Is this an artifact of how the list was put together or is clustering really that much more common than feature extraction? Is PCA thought to be too trivial to qualify?

<comment><USER7> PageRank is a similar eigenvalue based algorithm and I think PCA can be seen as a relaxation of k-means so they sort of did.

But yes, if i wrote the list it eigenvector based methods would be more prominent.

Also If I wrote it the tree based methods would have been replaced with random forests which are similar to CART but use the crucial ideas of sample bagging and random feature subsets which have proven themselves over and over.

I think it may just be out of date.

<comment><USER8> Any suggestions for something more recent?

<comment><USER7> The machine learning reddit recently started a faq:

[http://www.reddit.com/r/MachineLearning/comments/20i0vi/meta...](http://www.reddit.com/r/MachineLearning/comments/20i0vi/meta_collection_of_links_for_beginners_faq/)

They also have a good selection of articles though they tend to be somewhat deep learning/neural network focused. These algorithms have seen a big surge in interest and success of late but may not be as applicable to "data mining" (as opposed to say image or speech recognition).

</comment></comment></comment></comment><comment><AUTHOR> This article was eventually expanded into a full fledged book with more in depth descriptions of each algorithm:

[http://www.crcpress.com/product/isbn/9781420089646](http://www.crcpress.com/product/isbn/9781420089646)

</comment><comment><USER9> Is it just me, or was anyone else taken aback by an academic article using a linkbait-esque title? I'm sure the title is perfectly reasonable, given that it's a survey paper, but the past few years of being bombarded with articles like "10 weird tricks to optimize your everything" immediately triggers my skeptical meter. Funny how the internet warps the brain.

<comment><USER10> Unlike most Top 10 lists that are deliberately designed with unexpected choices for shock value, the paper cites exactly how the 10 were chosen and attempts to justify why each choice was made.

If the paper was titled "Wow, The Top 10 Algorithms in Data Mining Are Incredible, And I Can't Believe Where Naive Bayes Placed," then yeah, that might be link-baity.

</comment></comment><comment><USER11> Q: What's the difference between working on data mining and designing missiles?

A: When you build missiles, you can at least take comfort knowing that they'll only be used to harm people who are far away.

<comment><USER12> What are you talking about?

<comment><USER13> He's on about the problem of data mining being used by NSA and corporate America to do Bad Things.

And what are you on about?

I'm guessing you're on about the "tool is only as good or evil as the wielder."

Trying to take this back out of the meta, our society needs to figure out how to stop hurting each other. I think a good dose of critical thinking skills for our youngsters would go a good distance toward helping that.

<comment><USER12> I guess that's sort of like saying computers are evil because they are used by the NSA. Is there even any evidence that they do use it for anything significant? Let alone that this guys work is contributing to it.

<comment><USER11> Computers have _many_ applications, while data mining is generally used with working sets consisting of information about large groups of people - <USER2> to get a strategic leg up on them (say, price discrimination or advertising susceptibility), or to single out deviant individuals.

I don't think the entire field is strictly a universal evil per se, but with the current climate of centralization I think any good that it can bring is massively dwarfed by the bad.

Similarly, missiles themselves aren't a universal bad as they can be used for self defense, but in the current world basically their entire purpose is to preserve empires.

<comment><USER12> I don't think that's the case. In theory it can be used to "find deviants", but has that actually ever been done and to what degree? Improving advertisements isn't _horrible_.

It has a lot of applications in science, could vastly improve medicine, it's used to predict energy usage for power plants, filter spam, recommend movies or products, improve harvests for farming, etc. But I guess those things don't sell papers.

And lastly calling a technology "bad" isn't actually helpful. We can't stop bad people from using the technology or "uninvent" it. You'll just damage the people using it for good. See the Halo Effect where people told about the risks of nuclear power perceive the benefits as less ([http://lesswrong.com/lw/lj/the_halo_effect/](http://lesswrong.com/lw/lj/the_halo_effect/)).

<comment><USER11> By "finding deviants", I mean exactly what the NSA is doing, and what every Keystone police department will be doing in ten years. And yes, improving advertisements _is_ horrible - this is precisely one of the anti-human facets I am talking about.

> _It has a lot of applications in science, could vastly improve medicine, it > 's used to predict energy usage for power plants, filter spam, recommend > movies or products, improve harvests for farming, etc_

You're right. My initial comment was way too harsh and broad for indicting the whole field rather than just the in-our-face web scene applications.

> _lastly calling a technology "bad" isn't actually helpful. We can't stop bad > people from using the technology_

Of course you can't uninvent something, but you can slow down or speed up it's progress. _Path dependence_ is a thing. Currently, most people do not feel empowered with respect to computers. The more we put them at the mercy of seemingly unpredictable computer systems that are actually trying to outwit them, the harder it is going to be for them to get over those feelings of disempowerment so that we can get to a place where people expect their computers to work for them.

<comment><USER12> I've seen no evidence that the NSA does that, and really it makes no sense. Doing a search for "abnormal" behavior would mostly get you people that visit odd websites, or are awake at atypical hours, or spend too much time online, etc. Nothing remotely useful. There is a lot of hype around data-mining but there are diminishing returns on what can be done with it.

I agree that ads are bad, but they aren't that bad. Targeted advertisement is mostly just finding things that are relevant to the website or viewer. And it's so incredibly easy to block ads on the internet I don't really have much sympathy for those that don't and complain about them. Ads were _way_ worse in the age of television where 25% of all content was commercials.

>Of course you can't uninvent something, but you can slow down or speed up it's progress. Path dependence is a thing.

Perhaps, but for the most part the technology _already exists_. At it's core it's just basic statistics or sometimes even simpler techniques. Diminishing returns have already been hit long ago - I can't think of much that would improve the "bad" applications more than the "good".

>The more we put them at the mercy of seemingly unpredictable computer systems that are actually trying to outwit them, the harder it is going to be for them to get over those feelings of disempowerment so that we can get to a place where people expect their computers to work for them.

I.. what? On the rare occasions where machine learning is used in apps, it's to improve user experience, or do something that would otherwise be too complex or inefficient to code by hand. I'm sure someone, somewhere, abused the technology in their app - just like every programming technology ever. But in general I don't see how this is bad or even that it makes computers more "unpredictable".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Kevin Murphy's treatment of Kernel Methods in "Machine Learning - <USER3> Probabilistic Perspective" offers a take on SVMs that I don't often find in most discussions. He makes the case that SVMs are generally rather unusual from a Bayesian point of view. Apropos to other sparse vector machines, Murphy opines:

"Note that SVMs are very unnatural from a probabilistic point of view. First, they encode sparsity in the loss function rather than the prior. Second, they encode kernels by using an algorithmic trick, rather then being an explicit part of the model. Finally, SVMs do not result in probabilistic outputs, which causes various difficulties, especially in the multi-class classification setting.

"It is possible to obtain sparse, probabilistic, multi-class kernel-based classifiers, which work as well or better than SVMs, using techniques such as L1VM or RVM... However, we include a discussion of SVMs, despite their non- probabilistic nature, for two main reasons. First, they are very popular and widely used, so all students of machine learning should know about them. Second, they have some computational advantages over probabilistic methods in the structured output case... [specifically, SSVMs]

...

"The conclusion is as follows: if speed matters, use an RVM, but if well- calibrated probabilistic output matters (e.g., for active learning or control problems), use a GP. The only circumstances under which using an SVM seems sensible is the structured output case, where likelihood-based methods can be slow. (We attribute the enormous popularity of SVMs not to their superiority, but to ignorance of the alternatives, and also to the lack of high quality software implementing the alternatives.)"

\----

the tl;dr is that SVMs are an important tool for their historical impact and popularity, but the modern data scientist has a range of cookie-cutter algorithms to choose from that could possibly be much more useful.

</comment><comment><USER15> Okay, given a box of data, shove it into one of these algorithms, let the computer run, and now what? What do we have?

E.g., for some 'classifier', what the heck do we have? That is, what guarantees do we have? That is, is there something specific and guaranteed that the algorithm has actually done?

I know; I know; in some vague, unspecific sense, that seems to work in some practical cases, the algorithm will 'classify'. Still, we don't have precise description of (1) in what cases does the algorithm work and (2) how well.

E.g., what is the rate (probability) of false classifications? Sure, we'd need some hypotheses to say. Okay, what the heck are the algorithms assuming for hypotheses that would let there even be a rate of false classifications. Then with those hypotheses, what are the probabilities of a false classification?

Without such considerations, about all we have is some code that runs.

Uh, where's the beef?

<comment><USER16> The body of literature you are looking for is called statistical learning theory. If you are interested, you can _start_ with Vapnik's two books, but that is what I said, a start. The theory of Learning has shifted quite a bit, but the fundamentals remain the same. Once you are up to speed with Vapnik you can start reading proceedings of COLT and ALT (computational learning theory and algorithmic learning theory respectively).

You will find the following 3 types of guarantees

i) Strong assumptions on the knowledge of the stochastic process generating the data to back guarantees on the algorithm

ii) No assumptions on the on the data generating process except that it is governed by some unknown independent stochastic process. Prove guarantees on the output of the algorithm

iii) Don't even assume that the data generation process is stochastic yet provide guarantees on the output.

What exactly is guaranteed will of course differ.

Little advice, smugness as demonstrated with ...I figured it out 16 years ago yo bitches, will not help your cause whatever that might be. BTW are you H. A. Dye, 'cause Dye figured out group structures on measure preserving transformations in 1959 a little bit earlier than 16 years ago...just saying.

<comment><USER15> I was commenting on the OP. I started reading it but found just 'algorithms' with no indication of anything like any guarantees or qualities for them.

Your i) sounds good. E.g., in stochastic dynamic programming with assumptions reasonably expected, e.g., essentially a Markov assumption, we can easily prove that the number crunching yields the decisions with the least possible expected cost from any 'measurable' means of manipulating the data. And once when I argued this, I also included a proof that additional data independent of what we already wouldn't help either. This result is, of course, 'obvious' although obvious is not a proof. The proof turned out to be just a light tap with Fubini's theorem.

So, good: Some people actually argue that some of the algorithms actually have some desirable qualities. So, the world is not totally coming apart at the seams or being turned over to naive hackers who only know to watch the code run and then conclude qualitative that it seems 'nice'.

On your ii), "some unknown independent stochastic process", that's not so clear. So, for some index set I and random variables X(i) for i in I, the set

{ X(i) | i in I }

is independent? That's something of an unusual and, in practice, not very interesting stochastic process. Maybe some EEs would call that 'white noise'.

On your iii), sorry, but essentially everything is 'stochastic'. Even a 'deterministic' process is stochastic, in practice usually is also Markov (past and future conditionally independent given the present).

Thanks for the reference to H. A. Dye. I went on to show how such a group leads easily to statistical hypothesis tests. That is, in particular I was making sense out of 'resampling' and 'bootstrap' plans.

In part I got the idea of considering 'measure preserving', of course, from ergodic theory where measure preserving transformations are central, but the transformations I used, and needed for the statistics, are the ones that ergodic theory throws out.

No, I'm not Dye. That's the first I heard of Dye's paper. Thanks. At one point long after publishing I saw remark in one of the volumes of Dunford and Schwartz, as I recall, attributed to Norbert Wiener, that maybe something could be done with the 'periodic' case where, thus, there is a finite group.

Never heard of Vapnik. Thanks for the reference. From a simple Google, found at

[http://vserver1.cscs.lsa.umich.edu/~crshalizi/reviews/vapnik...](http://vserver1.cscs.lsa.umich.edu/~crshalizi/reviews/vapnik- nature/)

a review

The Bactra Review: Occasional and eclectic book reviews by Cosma Shalizi The Nature of Statistical Learning Theory by V. N. Vapnik

Okay, Vapnik is trying to do some mathematics to show some desirable mathematical properties of some of statistical learning theory, maybe in particular some of the algorithms. Good.

The review is a bit tough on Vapnik's writings from when he was writing in Russia. That's sad: The famous Russian texts on probability and stochastic processes, usually from Springer, were exemplary and with beautifully done translations to English, e.g., E. Dynkin, R. Lipster, etc.

I can'f find where I said "yo bitches".

But I do believe that a proposed algorithm should _do_ something, that what it does should be clear, good, and demonstrated, hopefully with some theorems and proofs. Knuth's TACP was big on 'analysis' of algorithms, but from the OP and, say, Prof Ng's course on machine learning it appears that the analysis part is being omitted.

Broadly, it looks like (1) statistics, optimization, stochastic processes are old fields and no longer very popular, at least in the US where they might be in departments of mathematics which, however, in the US, mostly don't like those fields; (2) computing is a new field and has lots of grant money, interest, and students; (3) for an actual application, those old fields need computing to do the specified data manipulations; (4) computing wants to take on some of the problems the old fields worked on and, then, is at risk of putting poor versions of good old wine in new bottles with new labels. This is a form of 'academic theft'? Well, if not, if the new wine is poor, then it's a form of academic dilution. Not good.

<comment><USER16> Well its a HN comment not a scientific communication.

Scenario (i) is mostly considered uninteresting and "solved" because it assumes that the particular stochastic process generating the data is known (this was the pre-Vapnik model). In most practical cases, however, one does not know the corresponding measure from which the data was generated (and will be generated in future). The old school thinking was that one should estimate the generating distribution, and then solve for the optimal decision, based on the estimate. Vapnik showed that it is far better to do it directly without bothering to estimate the distribution which in itself is a non-trivial problem.

So (ii) is the more interesting case that machine learners care to handle and Vapnik's was one of the first breakthrough fundamental result in this formalism. It applies to all algorithms that does something called structural risk minimization, not just one specific algorithm. His bound applies to all generating distributions, all samples, and all structural risk minimization algorithms ! However in this set up we still need to assume independence. Some form of independence, even in some weak form needs to be present. But it is quite remarkable that you can give guarantees on performance _regardless_ of what actual distribution generated the data. I should also mention Leslie Valiant. Lookup PAC learning you will understand the basic premise of this style. One genuine criticism is that it is overly conservative (and it has to be, because it is giving guarantees that applies for the worst distribution, worst training sample, worst algorithm...).

(iii) Removes the need for independent draws. If you want to read up on these, search for "regret minimization." In this setup the guarantees hold for all sequence of data, even if adversarially generated by someone who knows the algorithm you will employ. Some geometric assumptions are necessary on the domain and some function analytic ones on the function that you are trying to minimize (typically convex. Non-differentiable functions are allowed).

       -- Shalizi's Review --

Shalizi writes good stuff but this review of Vapnik's book is surprisingly mean spirited. The field of course has progressed after Vapnik and there are legitimate criticisms that one can raise, but the review exhibits bad form, I think. Prior to Vapnik there were very few results that one could state outside of the statistical physics community (that worked with strong assumptions, typically Gaussian noise etc)

        -- Aside --

No you did not say the word "yo bitches" but that was the attitude you demonstrated. Before casting judgments as you did at least make an effort to familiarize yourself with the background. And that is exactly what it is, background. A machine learner will not even mention these things because you are expected to know these things if you are in this field.

        -- Re: Analysis being omitted  --

Think of it this way, one doesn't really need to know precise chemistry of hydrocarbon combustion to drive a car, conversely, knowledge of such chemistry _alone_ is useless unless it is teamed up with good engineering and in this case algorithm. There is a huge difference between showing that minimizing a particular function has nice properties and actually coming up with a piece of code to efficiently minimize such a function, not just in theory where constants can be conveniently swept under the rug, but also in practice. So dont be too quick to dismiss the "naive coders".

Most importantly, practice, almost always precedes explanation and analysis in engineering. Usually practitioners find the algorithms in their hacky ways. The analyst/theorist smoothens the kinks and explains why the method works so well after it has been demonstrated to work so well-- not always, but almost always.

</comment></comment></comment></comment><comment><USER17> These algorithms are all good, but they seems to be missing recurrent ANN, that is, the form of datamining tool our brains are using. I can add this paper as relevant for those being interested [http://orre.neurologic.org/pubdoc/abstract/complex2003-abstr...](http://orre.neurologic.org/pubdoc/abstract/complex2003-abstract.html)

<comment><USER18> The actual link is here [http://orre.neurologic.org/pubdoc/abstract/complex2003-abstr...](http://orre.neurologic.org/pubdoc/abstract/complex2003-abstract.html)

</comment></comment><comment><USER17> It was published in 2007 not 2008 ;)

</comment><comment><USER19> i understand some of these words</comment>


Ask HN: How to stop OS X resizing a window dragged to the menubar? - <AUTHOR> If I drag a window up until the top edge is touching the menubar, some part of the screen will turn semi-transparent blue, indicating the target resize. How do I stop this annoying behaviour? <comment><USER2> As Ezhik mentions, this doesn't happen for me either so you might have installed a third party software that does this.

</comment><comment><USER3> OS X doesn't seem to do this for me. Did you install something simulating Windows' Aero Snap?

</comment><comment><USER4> Change BetterSnapTool behavior

<comment><USER5> I can confirm betterSnapTool does that. When you install certain utilities (like Ubar dock replacement), it even tells you to disable window snapping.

</comment></comment><comment><USER6> Do you have the Window Tidy utility installed? Could be that.

</comment><comment><AUTHOR> Thanks, it was HyperDock!</comment>


Rosetta Stone rallys to support one of theirs - <AUTHOR> http://www.youcaring.com/other/please-help-andrea-crew-s-family-in-this-difficult-time-/79436

<comment><AUTHOR> Rosetta Stone employs hundreds of Coaches that teach several different languages to learners around the world. I am an English Coach. A few days ago a fellow Coach, Andrea Crew, was allegedly killed.

[http://www.washingtonpost.com/local/crime/slain-mother- wante...](http://www.washingtonpost.com/local/crime/slain-mother-wanted- children-to-leave-country-court- papers/2013/08/13/6b62c07a-042c-11e3-9259-e2aafe5a5f84_story.html)

The Coaches and the company have been very supportive for her two young daughters so far. Really great to see.</comment>


Why I don't spend time with Modern C++ anymore - <AUTHOR> https://www.linkedin.com/pulse/why-i-dont-spend-time-modern-c-anymore-henrique-bucher-phd <comment><USER2> In my experience, the opposite of what the author claims is true: modern C++ leads to code that's easier to understand, performs better and is easier to maintain.

As an example, replacing boost::bind with lambdas allowed the compiler to inline functor calls and avoided virtual function calls in a large code base I've been working with, improving performance.

Move semantics also boosted performance. Designing APIs with lambdas in mind allowed us to get rid of tons of callback interfaces, reducing boilerplate and code duplication.

I also found compilation times to be unaffected by using modern C++ features. The main problem is the preprocessor including hundreds of thousands of lines for a single compilation unit. This has been a problem in C and C++ forever and will only be resolved with C++ modules in C++2x (hopefully).

I encourage the author to try pasting some of his code into [https://gcc.godbolt.org/](https://gcc.godbolt.org/) and to look at the generated assembly. Following the C++ core guidelines ([http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)) is also a good way to avoid shooting yourself in the foot (which is surprisingly easy with C++, unfortunately).

<comment><USER3> > In my experience, the opposite of what the author claims is true: modern C++ > leads to code that's easier to understand, performs better and is easier to > maintain.

Can you comment on the memory safety of modern C++? I am wondering if I should learn Rust or modern C++.

<comment><USER4> std::unique_ptr, move constructors, etc and you're pretty safe, but it's still not in the same league as Rust.

In my opinion you should probably learn Rust unless you want to get a job writing C++ (e.g. game development).

<comment><USER5> I never quite understood why unique_ptr and move semantics are supposed to improve memory safety over new and delete. They reduce leaks, sure, since the compiler inserts free for you at a hopefully-useful place. But you still effectively have to decide when to free, and there is no protection against dangling iterators, references, or pointers. From a security point of view, use after free is far worse than leaking, since UAF can lead to remote code execution.

In fact, move semantics create a _new_ type of hazard that wasn't in earlier versions of C++: dereference of a unique ptr after moving it.

<comment><USER6>
      class fail
      {
          foo * p;
          void init()
          {
             p->some_init();
             if(p->some_error())
             {
                 delete p;
                 throw some_exception();
             }
          }
      public:
          fail()
          {
              p = new foo;
              init();
          }
          ~fail()
          {
              delete p;
          }
          void reinit()
          {
              init();
          }
      };

vs.

      class ok
      {
           unique_ptr<foo> p;
           void init()
           {
               p->some_init();
               if(p->some_error())
               {
                   throw some_exception();
               }
           }
      public:
           ok()
           {
                p = make_unique<foo>();
                init();
           }
           void reinit()
           {
                init();
           }
      };

<comment><USER5> What fraction of security-sensitive UAF bugs in the real world have had to do with exception safety?

<comment><USER6> It isn't limited to exception safety. The problem previously had been that there was no clear answer to the question, when should "delete" (and "~foo()") be called for a pointer? If you do it before some other code expected you to then you have UAF. If you do it in more than one place then you may have double free (and two calls to ~foo()).

Now the answer is that unique_ptr will do it when the pointer itself goes out of scope.

<comment><USER5> > Now the answer is that unique_ptr will do it when the pointer itself goes > out of scope.

And my claim is that this doesn't effectively reduce UAF. It doesn't eliminate dangling references, etc.

<comment><USER6> It seems like you're making the perfect the enemy of the good.

Look at my example above. The problem isn't just exception safety, the first class is five kinds of catastrophe waiting to happen.

If the user calls reinit() then init() may delete the pointer (because it was written expecting to be called during construction). So now the object exists but the pointer is invalid and any further use of the object will be UAF. Even if the caller understands the exception to mean that the object should not be used anymore, the ~fail() destructor is going to call the ~foo() destructor again and double free anyway.

On top of that, the default copy and move constructors and assignment operators for a naked pointer just copy the pointer, which produces UAF as soon as the first copy to be destroyed frees the pointer the others still hold.

None of that happens with the unique_ptr version. No explicit call to delete is required so we lose that opportunity to accidentally call it before the surrounding object ceases to exist. The default move constructor actually works and the default copy and assignment operators are deleted, so attempting to copy without an explicit deep copy implementation becomes a compile error instead of runtime UAF. And it's less code too.

It can't actually stop you from having dangling references because if it did then it wouldn't be able to compile existing code anymore. But how is it not an improvement over the status quo?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> HFT is a pretty limited and extreme application case.

From what I understand - _everything_ is not enough for HFT - network cards, kernel drivers, cables, etc.

You have milliseconds (edit: nanoseconds !) to receive, process and push your orders before someone else does it and gets the prize.

It's an arms race between technologists for the purpose of making a small number of people rich.

I doubt that these requirements apply to other application fields where C++ is used - and it's used almost everywhere, with great success I might add.

In my view C++ is actually a couple of languages mixed into one.

The hard part is knowing which part of the language to use for which part of the problem.

The "modern" C++ solves a lot of the nuisances of the "old" C++, but you can do without these features just fine. I apply them carefully to my code and so far it's been a pleasant experience. Even if I don't use all of the new features, it's nice to know that I can (and I will some day!).

So I don't really buy this rant..

<comment><USER8> Not milliseconds. Nanoseconds. Competitive tick-to-trade times are on the order of 1000ns or less.

<comment><USER9> How do you tune the machine for that type of latency? User space drivers? Could you elaborate? Not having to go beyond L1 cache doesn't mean much if it takes a few milliseconds to get that trade out of the network card and on to the wire right?

<comment><USER8> FPGAs

</comment></comment></comment></comment><comment><USER10> There are two separate rants here that aren't delineated well.

1) C++ is too complicated, and therefore hard to reason about and slow to compile.

We're going to argue about this forever, but you'll have to agree that the spec is very large and warty compared to other languages, and that C++ tends to take far longer to compile (this was already a problem a decade ago, it's not specific to "modern" C++).

2) The future of software development will include more of what I'm going to call ""non-isotropic"" software; rather than assuming a flat memory model and a single in-order execution unit, and exerting great effort to pretend that that's still the case, programmers will have to develop effectively on GPUs and reconfigurable hardware. Presumably this speculation is based on the Intel-Altera acquisition.

You can sort of do hardware programming in C (SystemC) but C++ is really not a good fit for hardware. Personally I'd like to see a cambrian explosion of HDLs, but the time is not yet right for that.

It sounds like the author favours the "C with classes" programming style, maybe including smart pointers, and is probably not keen on lambdaization of everything.

<comment><USER11> Can't really argue about 1.

About 2, in-order single instruction execution hasn't been an assumption for a very long time; c and c++ optimizers (and programmers) have been able to take advantage of these CPU features for a while. There are language extensions (Cilk++, OpenMP), to take advantage of extra cores for fine grained parallelism.

Regarding GPUs, arguably C and C++ have the most mature and transparent offloading support all around (OpenACC, again OpenMP, whatever MS offloading extensions are called) and the most popular GPU programming language (CUDA) is a C++ dialect.

Regarding the flat memory model, for large scale programming the only sane model is a flat, cache coherent one; those architectures that don't provide that, either evolve to provide it or die (cf. CELL) supplanted by those that do (yes, that doesn't mean that all memory is the same, but that is true with your standard CPU anyway).

I don't have an opinion on FPGAs, I expect that, if they ever go mainstream, initially people will just assemble predefined blocks via high level languages, but who knows what the future reserves us.

<comment><USER10> Parallelism: yes, although OpenMP isn't nearly as accessible as e.g. Swift async closures. C++ only got proper language-native threading in C++11.

 _for large scale programming the only sane model is a flat, cache coherent one_

Do google view their datacenters as a single flat cache-coherent memory space? No, they built mapreduce instead. That's the point of view I'm coming from: distributed systems engineering working downwards. Rather than a single large program operating on a single memory space, a set of fragments whose programmers are aware that there is latency when communicating between nodes. DRAM is just another "node" that you have to send messages to and wait for a response.

<comment><USER11> "Parallelism: yes, although OpenMP isn't nearly as accessible as e.g. Swift async closures."

I'm not familiar with them, do you have a pointer? Cilk does have powerful semantics and a very light weight syntax.

"C++ only got proper language-native threading in C++11."

Sure, but OpenMP and Cilk are significantly older.

"Do google view their datacenters as a single flat cache-coherent memory space?"

No, but I'm pretty sure they whish they could. Many HPC clusters do present a single memory image across thousands of machines.

"they built mapreduce instead."

Mapreduce (and its extensions) is not a general programming model though.

<comment><USER12> > I'm pretty sure they whish they could [view their datacenters as a single > flat cache-coherent memory space]. Many HPC clusters do present a single > memory image across thousands of machines.

No not really, at some point when you're dealing with PetaBytes of RAM and millions of cores, the Law of Physics kicks in, your RAM is spreading across a large physical area no matter how clever you are. If you want a flat memory space you have to guarantee an access to _any_ memory address in less than X cycles otherwise you have a NUMA architecture[1]

While this is true that HPC clusters present a single memory image _per cluster node_ (where one node = 8-32 processors (maybe 64)), the other nodes's memory has to be access with Message passing or other mechanisms.

You need a different programming model, MapReduce is too specific, that's why Google is trying things like their "DataFlow" platform.

[1][https://en.wikipedia.org/wiki/Non- uniform_memory_access#NUMA...](https://en.wikipedia.org/wiki/Non- uniform_memory_access#NUMA_vs._cluster_computing)

<comment><USER11> "If you want a flat memory space you have to guarantee an access to any memory address in less than X cycles otherwise you have a NUMA architecture[1]"

There is nothing wrong with NUMA (well, ccNUMA, but today that's a given). Even a simple modern two socket server is a NUMA machine.

Anyways, as I've commented elsewhere, I'm not arguing that shared memory is practical today on a large HPC cluser.

<comment><USER13> > Anyways, as I've commented elsewhere, I'm not arguing that shared memory is > practical today on a large HPC cluser.

I think the point that was being made was that it'll _never_ be practical purely for physical reasons. Any physical separation means that light takes a certain amount of time to travel and no known law of physics will let you circumvent that... A distance of a foot will _always_ incur a latency of ~1ns (at best), so our models _must_ account for latency. (At _some_ point -- it's not obvious that we've reached the end of how compact a computer can be, but there _is_ a limit where you just end up with a tiny black hole instead of computer.)

<comment><USER11> I don't get it, our models have been accounting for latency for the last 30 years at least. We routinely use three level of caches and higly out of order memory accesses for trying to make latency manageable.

Now it is possible that our best coherency protocols simply aren't effective at high latencies, but that doesn't mean we can't come up with something workable in the future. Is there any no-go theorem in the field?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern features are not good for _any_ developers. For example:

>It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change.

This is simply a bogus statement with respect to what at least 90% of c++ developers do on a daily basis.

I have benchmarked unique_ptr, auto, brace initialization, lambdas, range- based-for and other modern idioms and found them all to be at least as fast, and often faster, than their older counterparts. Now, if I were to instead go off and write template-heavy code using new features, that would be different. But in reality, the vast majority of c++ developers -- I'd wager at least 95% -- are _not_ writing variadic templates on a daily basis (nor should they be).

The memory safety and many benefits from unique_ptr [0] is one of many modern tools that is a non-brainer to use in nearly all contexts. No, not nearly all contexts, allow me to rephrase: _all_ contexts. It just is, and if you compare its use to manual new/delete code, the benefits are solid and faster.

The author further claims that modern C++ is less maintainable and more complex. The absolute opposite is true in nearly all cases. Using unique_ptr again as an example, it leads to less code, less complex code, more clear code, and better maintainability and code readability. Uniform brace initialization is another example that prevents many common older problems in the language.

FYI the author keeps talking about high frequency trading as an example of why modern c++ is a bad choice. Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. This author is either naive or political.

I think the title of this article is highly misleading, and the contents are not relevant. Overall, this article is just bad advice for most of us.

[0] [https://news.ycombinator.com/item?id=11699954](https://news.ycombinator.com/item?id=11699954)

<comment><USER15> (re 10 minute compile times)

> This is simply a bogus statement

I work on a C++ project and believe me, 10 minute compile times would be great :)

<comment><USER16> have you tried ccache? the 5x to 10x improvement isn't a bogus statement in my experience

<comment><USER17> ccache eliminates spurious rebuilds, but doesn't make compilation of things which actually need to be recompiled any faster. It's basically just a workaround for that Make only uses file mtimes and not the contents to decide what needs to be built.

<comment><USER16> In theory, agreed. In practice I see a lot of re-compilation in large projects.

</comment></comment></comment></comment></comment><comment><USER18> As has always been the case, effective use of modern C++ requires knowing which subset of the language to use and which to avoid.

I agree with the author's criticisms of many C++ features. At the same time, I think that a proper simple, modern subset of C++ exists that is much more productive and safer than C, without sacrificing performance. You can also optimize progressively, for example start with using std::string and std::vector and then replace the stock implementations if they aren't performant on your target architecture. I would not, however, recommend using C++ for GPU kernel code - a mix of C++ for CPU code and C for GPU kernel code works best. It is not ideal, but it's the best toolset available for serious industrial development.

FPGAs are exciting, but they've also been the "next big thing" in general purpose computing forever. Obviously it makes sense to use FPGAs for certain HFT and embedded applications, but that's not the same as general purpose computing which is what C/C++ is for. Not to mention, FPGA compile times can take hours or even days, which pales in comparison to most C++ template overhead. I would also say that for IOT, I'm not sure why it is obvious that "$10 FPGAs" should dominate. Why not a $0.50 microcontroller? Or the $5 Raspberry Pi Zero board? Both of which are eminently programable in C and even C++. Embedded devices have been around long before "IOT" became a buzzword, and we can see that microcontrollers, FPGAs, SOCs, and custom ASICs all have a role to play depending on the application.

<comment><USER19> "Not to mention, FPGA compile times can take hours or even days, which pales in comparison to most C++ template overhead."

It's really funny to see him bitching about iterations with templates then suggest using a FPGA and synthesis tools. I'm glad it amused someone else, too. :)

</comment></comment><comment><USER20> If he is complaining about C++ being bad and suggesting Verilog on FPGAs as an alternative, boy do I have some bad news for him.

HDLs (yes including Systemverilog) have 10x worse design than the worst software languages. This is why there are entire companies out there that make high level synthesis tools or high level HDL specification languages (like Bluespec).

And I haven't even said anything about the quality of FPGA tool chains.

<comment><USER21> This, a thousand times. If you want minimum latency, FPGAs are of course a possible solution, but selling it as a "better C++" is just laughable. When you have an IP core which fits your problem, then by all means use it (and hope it works as advertised), but otherwise: the less you need to do in an FPGA, the better.

</comment></comment><comment><USER22> > If you cannot figure out in one minute what a C++ file is doing, assume the > code is incorrect.

This statement at first resonated with me, and then I thought about it: this doesn't reduce the complexity of the overall application or service, it just means that one file is simple. You could have 10,000 files instead of 1 much shorter one; is that any more simple?

<comment><USER23> Yes. If each file makes sense in isolation then the whole will as well. Just splitting code into lots of files won't necessarily produce files that you can figure out in 1 minute though (you have to define the boundaries between files such that they make sense).

<comment><USER24> I disagree. A complicated function may be made of a bunch of statements where each statement makes sense easily. The entire function may still be complicated. The same argument can be extended for files and projects. Even if each file is simple, if the code in those files interact with each other in a complicated manner, the project becomes complicated. This can happen despite having neat boundaries between files. Nothing stops a new programmer from writing new simple files that interact with the existing files in a complicated manner. Simplicity of source code in individual files or functions is just one of the factors behind a simple project. Simplicity of design has to go hand in hand with it.

On the other hand, a couple of files may be very complicated but the entire project could still be simple if those complicated files hide the complexity behind neatly exposed functions, and the remainder of the project does not make use of those functions in a complicated manner.

<comment><USER23> > A complicated function may be made of a bunch of statements where each > statement makes sense easily. The entire function may still be complicated.

 _Statement_ yes, but I avoid them where possible - the complexity comes from their interactions because their interactions are unmanaged, implicit and arbitrary. If you make each function an expression made up of expressions and functions, then I think it becomes true that if each expression makes sense easily then the whole will also make sense easily.

<comment><USER25> As far as the complexity of programs are concerned, there is a similarity between statements at one level of abstraction and functions at a higher level. I have seen many cases where small functions have been assembled into complicated programs. These programs often have a proliferation of 'helper' classes and functions, where you have to trace through long series of calls to get to where the work is done. They often seem to come from a poor design that has been repeatedly patched instead of fixed, or from programmers who write functions because they think they will be part of the solution, but not backing out and replacing them them when they find a complication they had not anticipated.

Using small functions is a necessary, but not sufficient, condition for making understandable code.

<comment><USER23> I think what you're describing is a case where you can't understand what those helpers do, and therefore can't understand what the function that calls them does. I maintain that if each individual function makes sense then the whole will too.

<comment><USER26> This holds if the small functions are built around a coherent top-down design, respecting each other's invariants. Once the project is too large to fit in one's head, it is no longer sufficient for each function to be 'correct' in a local sense.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> I know why I don't like C++ anymore, it's just no fun.Its slow to compile, the errors are like 6 lines long full of template and class hierarchy that makes it hard to understand what exactly happened, and then of course there's the common coding shortcut of declaring everything auto. (What type is this list? I don't know, it's auto all the way down.) Then there's the whole thing about making constructors, but leaving the bodies empty because everything should be on initialize lists now, and now there's wrapped pointers for some reason.

I hated writing modern C++. It was just so depressing and frustrating.

<comment><USER28> I had to write C++ yesterday and hated every second of it, from the clunky header files, to the errors that make no sense, to the can't make a cyclic dependency between classes i.e.

          class A { B: b}
          class B { a: A}

Long story short - I was to create a wrapper around a Poco::Runnable, so you can use the wrapper as a Poco::Runnable (don't ask why, it's TEH LAW) but without extending it.

<comment><USER29> C++noob here, but: Given that the members in your example are no pointers but actual substructures within your data structure, wouldn't that result in an infinite data structure? Therefore it sewms quite logical to me it's not allowed.

Disallowing cyclical dependencies via pointer would make no sense though.

<comment><USER30> Right. C++ objects are values, not references to values like in almost all other languages. So C++ needs to know the sizes of everything to construct them. If you tried to write out the mathematical series describing the ultimate size you would need to allocate for A or B, you would end up with a value approaching infinity.

<comment><USER31> This is probably my favorite thing about C++. Values are so much easier to reason about than references.

</comment></comment></comment></comment></comment><comment><USER32> This article is coming from a frustrated developer and lacks any scientific evidence. The frustration (understandably) is coming from the overwhelming complex new features and patterns that barely a compiler can understand.

C++11 onward revamped the language to make up for the lack of progress in the past 10 years. The majority of C++ developers that aren't keeping up with the new features because they are busy with their daily jobs feel that they are falling behind and the language they thought they new has changed underneath them.

C++03 already had a steep learning curve, but with C++11+ that learning curve is orders of magnitude more.

On the upside, you can use C++11 without understanding most of the details and it will do the right thing _most_ of the them. And I think that's the bet that the language is making.

</comment><comment><USER33> Ok. Try a different language :)?

A single language needed to solve all problems is a fallacy.

I don't see FPGA programming ousting c++, but expect higher level languages with strong parallel semantics to gain "market share". You can always call a dedicated process written in optimized c for the hottest components. Compose the rest in go, elixir, or any high level language (lisp).

Architectures will naturally gravitate to higher level languages that support cleaner composition. The tools and interfaces will push towards higher abstraction without impacting build or run time. Maybe this process is related to Kevin Kelly's inevitable. I'm an optimist here.

<comment><USER34> > _A single language needed to solve all problems is a fallacy._

Has that been proven and do we have pointers to any peer reviewed papers on that?

Because else its just an old's wives tale.

I don't see any logical impossibilities for one language to solve all problems (meaning, to work well for at least 4 domains: OS and drivers a la C, apps/games a la C++, network programming a la Go, Java etc, and scripting a la Python).

It's just cultural, monetary, design and community issues with most current languages.

And even if we want to have different profiles for each domain, ideally I'd do it with a 2-layered language implementation like this:

1) Base library: network, threads/fibers, UI, database etc of Python/Java SDK proportions

2) A "close-to-the-metal" layer without a (big or any) runtime (can use RAII, ARC, etc).

3) A "scripting" layer that is a GC'ed an easier to use superset of the (2)'s syntax. Ideally all (2) code should also be valid (3) code.

Both use the same base library (written in the "metal" layer or C). (3) can be embedded into (2) as a scripting engine, and (3) can call all (2) APIs trivially (e.g. no need for declarations like for using C from Go, Python etc -- just import and call).

Programmers can use (2) or (3), mix them, share code between the two. And what's best, the core APIs are all the same -- which is most difficult part to master in a language.

(Think like Java and Groovy, but with the parent language closer to the metal and the later closer to C).

<comment><USER35>
      > I don't see any logical impossibilities for one
      > language to solve all problems

There are no logical impossibilities in constructing a vehicle that can serve as a passenger vehicle, dump truck, submarine, and airplane, but tensions in design will very likely result in a compromise that is more complicated, more expensive, and less capable than a dedicated solution. Not only that, but your vehicle will be just as inadequate as every other once the landscape changes and someone now needs a space shuttle.

All-in-one compromise solutions only excel when a market is both small (so that niche solutions that serve only a percentage of the market don't pass the absolute mindshare threshold for viability) and uncompetitive (so that there's no competitive advantage to ditching generality in favor of efficiency in a specific space). As long as the software market keeps growing and remains competitive, specialization and fragmentation will only increase (in the long run, anyway; we'll still be subject to the same bust-and-boom cycles, so it will still be possible for fragmentation to decrease in the short-term).

<comment><USER36> > a passenger vehicle, dump truck, submarine, and airplane

The problem with using metaphors to make your argument is we generally have to argue about whether the metaphor is even appropriate enough that the conclusions apply to the original topic... It's simpler just to argue the topic.

Within a huge class of problems, I don't need to get a new computer to solve each new thing that comes up. That's a very general tool. Why do I need different programming languages?

> All-in-one compromise solutions only excel [...]

Who asked for a compromise? I could make a short list of all the features I want in a language, and while there isn't one single languages that currently has all those features, I doubt you could make a proof that creating such a language is impossible or would involve some horrible trade off. Your list might be different than mine, but that's not the point.

<comment><USER35>
      > The problem with using metaphors

Then ignore the metaphor and focus on the longer paragraph that succeeds it. :P

      > I don't need to get a new computer to solve each new
      > thing that comes up

Except that, in practice, you do. I have a smartphone in my pocket, a laptop in my bag, a desktop in my office, and two personal servers in the cloud. Just because two computers are both effectively Turing machines does not automatically invalidate the importance of form factors, power draw, integrated peripherals, physical location, and other practical differences. This also ignores the existence of domains that _actually_ demand dedicated hardware, like supercomputing. We are never going to live in a world where microcontrollers are just as capable at running weather simulations as the TOP500, because the economics don't pan out. So no, you're right, it is not logically impossible to construct a language that is capable of performing all imaginable tasks, though that's not something that I've ever disputed. Rather than being logically impossible, it's merely economically infeasible. :P

<comment><USER36> > Then ignore the metaphor and focus on the longer paragraph that succeeds it. > :P

Your second paragraph had a bunch of economic pseudo-theory about what sells... Maybe that explains why we don't have a good general purpose programming language, but it said little about whether there could be one.

<comment><USER35> Economics is a social science, pseudo-theory is the bulk of it. :P However, I welcome you to prove me wrong by creating the language to end all others.

<comment><USER36> > :P However, I welcome you to prove me wrong by creating the language to end > all others.

Yes yes, I'll be sure to let you know. In the meantime, I hope you'll keep up the great work maintaining the status quo and contributing to a language which avoids problems that experienced programmers don't really have.

:P

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER37> I've come to the conclusion that one should "use C++ when they absolutely have to and C when you can." There just aren't many areas where C++ is absolutely required when plain old simple C can be used. (Not to mention using higher languages if possible).

</comment><comment><USER38> Such rant appears once every few months on HN, this one is one of the least convincing. Many problems he mentioned are not "Modern C++" problems, but problems with C++ from beginning, some of them already have reasonable solutions, for example ccache + distcc for speeding up compilation.

The real problem with C++ is the standard committee, the design by committee approach for such a complex language is failing. If C++ is taken over by a company, it will be a much better language.

</comment><comment><USER39> "There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Stroustrup.

C++30, might end up being D, today.

<comment><USER40> Or Rust, or Go.

C++ is like Java, it will pull in features of other languages years after they have been proven to be valuable and useful, not that there is anything wrong with that. There is something to be said for a slow moving target that you can kinda rely on to work well. If anything I think C++ went off the rails when they started innovating in the language space and tried to introduce all sorts of novel features that other languages hadn't prototyped. I think of all the nonsense around templates that they introduced and how generally the consensus is not to use any advanced template features.

</comment></comment><comment><USER41> This sounds like it's written from the point of view of implementing something inhouse. I fail to see how FPGA programming will be relevant if one wants to distribute software for consumers (or am I technologically clueless...).

<comment><USER42> According to the writer's LinkedIn profile, he comes from the world of High Frequency Trading. That's an area where performance is so important, that it might make sense to design your own hardware. And you certainly don't want to distribute it to anyone...

I do agree with the writer that with each release, C++ has become more and more complicated, seriously hurting the maintainability of C++ code.

<comment><USER43> I also agree that c++ is getting more and more complex over time. However if you build things from scratch and you cherry pick your language features, C++ can be quite pleasant.

<comment><USER44> That's the problem - C++ isn't one language, it's at least three generations of languages living together in the same compiler, like an extended family crammed into a tiny apartment.

No one has moved out since 1983, and new additions just keep on coming.

<comment><USER11> We c++ programmers are very welcoming. We have yet to meet a paradigm that we didn't like.

On a more serious note, any old system acquires cruft with time and you don't always have the luxury of throwing away pieces or even restarting from scratch.

</comment></comment></comment></comment></comment><comment><USER45> I find the beginning and end of the article quite contradictory. Basically that C++ is too complicated; and oh by the way we should start programming FPGAs, which are much harder to get right.

I like modern C++, because I think it simplifies a lot of things (RAII for the win here). Templates let you engage in duck typing, but with (if you are careful) very performant results.

</comment><comment><USER46> While some pretty good points were stated in this post, I cannot but feel OP is a bit biased. Too narrow sort to say.

I feel totally opposite in terms of new Modern C++. I guess the thing is how, where and when you use it will define your opinion/experience.

</comment><comment><USER47> > Today the "Modern Technologist" has to rely on a new set of languages: > Verilog, VHDL

That was a complete surprise ending! :)

I like surprise endings, and he makes a lot of good points, whether or not I agree with them. But, I totally wasn't expecting "I'm done with C++ because: hardware." I was expecting because web or because awesome new high performance functional scripting language <X>.

A lot of what he's talking about there will still run compiled software though... FPGA programming and C++ aren't exactly mutually exclusive, right?

<comment><USER10> _FPGA programming and C++ aren 't exactly mutually exclusive, right?_

I would say yes: you can't really run C++ on an FPGA. There are all sorts of tools which promise this (SystemC etc), but it requires you to stick to a careful subset of language constructs. You don't have a heap, for example.

</comment></comment><comment><USER48> 20 year C++ programmer here. I work on multithreaded server code. Stopped using modern C++ features 5 years ago. I'd compare my use of C++ to be roughly equivalent to the use of C++ in the NodeJS project or the V8 project. I'm not a user of Boost.

I have to agree with the author of the article. It takes longer to train developers to write idiosyncratic modern C++ code and compilation times explodes. Compiler support for bleeding edge C++ features is spotty at best. Harder to reason about the correctness of modern C++ code.

<comment> Const-me 15 years here.

I'm mostly in MS ecosystem, so I don't have issues with C++ compiler support. But I totally agree with the rest of your comment.

</comment></comment><comment><USER49> One of the biggest users (some would say abusers) of template metaprogramming I know works on HFT software. He trades extremely long compile times for performance at runtime and finds that C++ allows him to do this and maintain a decent architecture (through what amounts to compile-time polymorphism as well as RAII).

For him, it's actually the older features of C++ that have no use. He doesn't use deep class inheritance and never touches virtual functions, for example.

</comment><comment> Const-me I never programmed HFT software, but I agree with the criticism of the modern C++.

It's bad the author hasn't defined what exactly's "modern" is. I saw some comments compared boost with C++/14\. I think boost is also modern. Even Alexandrescu's Loki is also modern, despite the book was published in 2001.

I think that modern stuff was introduced in C++ because in end 90s-start 2000s there was expectation C++ will remain dominant for some time. There was desire to bring higher-level features to the language, to make it easier to learn and safer to use — even at the cost of performance.

People didn't expect C++ will lose its market that fast: very few people now use C++ for web apps or rich GUI. However, due to the inertia and backward compatibility, the features remain in the language.

Personally, I'm happy with C++.

C++ is excellent for system programming, also for anything CPU bound. For those you barely need those modern features, and fortunately, they're completely optional: if you don't like them, don't use them.

But if you do need higher-level language for less performance-critical parts of the project, I find it better to use another higher-level language and integrate it with that C++ library. Depending on the platform, such higher- level language could be C#, Lua, Python, or anything else that works for you.

</comment><comment><USER50> > After 1970 with the introduction of Martin-Löf's Intuitionistic Type Theory, > an inbreed of abstract math and computer science, a period of intense > research on new type languages as Agda and Epigram started. This ended up > forming the basic support layer for functional programming paradigms. All > these theories are taught at college level and hailed as "the next new > thing", with vast resources dedicated to them.

This seems pretty dubious. Dependently typed languages and other projects embracing advanced type theory are still the realm of niche enthusiasts. While some of the more academic colleges might teach them in one or two courses, the vast majority of education a CS college student receives will be taught in traditional imperative languages. If "vast resources" have been devoted to Agda and Epigram, then I'm not sure what kind of language should be used to describe the resources devoted to C, C++, Java, etc. Also as the author mentions, Intuitionistic Type Theory has been around since the 70's, in fact the same year that C was introduced. Certainly it hasn't been taking over the CS world by storm since its inception, as he seems to claim.

Beyond that, the author's argument seems to be a bit incoherent. He critiques the readability of Modern C++, but C++ is notoriously hard to understand, including or especially prior to the development of C++11. It's never going to be an easy language to read except to seasoned developers. If anything, modern C++11 seems to provide abstractions that increase readability and safety. He critiques the performance of modern C++, but then he ends up recommending that people ditch C++ entirely and learn VHDL/verilog instead. Not even vanilla C++ is fast enough for him, then why criticize modern C++ on the grounds of performance?

</comment><comment><USER51> I recently had to switch a project to -std=c++11 because a header I include now uses C++11 files. This change alone made compilation at least twice if not three times as slow. The new safety and convenience features are nice but compile times seem to be out of focus and getting slower and slower every year. I don't know how I feel with g++ 6.1 defaulting to -std=gnu++14.

<comment><USER52> How do you know that it is c++11 switch that dramatically increased your compile time, instead of the header file and the headers it includes? Two conditions are changed, and you feel confident that _one_ of them is responsible for the outcome. Why?

<comment><USER51> Because it's a C++11 header that doesn't exist in C++98. And I cannot compile that version without switching to C++11 mode.

Edit: there appears to be some confusion here. I don't include the C++11 header myself. I include a public API header of another project which now happens to include a C++11 header in their public include file. Unless I want to stay on the old version of that API and accept the risks, I don't have a choice whether I compile my consumer module in C++11 mode or not. And it's a major fault of the C++ language that there are no modules and therefore this include file overhead and mess. They appear to be working towards a module system, thankfully.

<comment><USER52> > Because it's a C++11 header that doesn't exist in C++98.

That is supposed to be a fault of C++11?

<comment><USER51> I don't understand your argument. An upstream project I use put a C++11 header in their public API's header. Now, I also have to build in C++11 language mode. If you're saying it's not the language standard's fault that CXX is slower, sure, but how or why should I differentiate between ISO C++ and g++/clang++ with libstd++/libc++?

<comment><USER12> I think what the GP was saying is: Ignore the new feature you're using from that upstream project for a minute. Did you try compiling _your_ project with -std=c++11 before doing any other change? That is the only way you'd clearly see the difference of switching to C++11 in your project. Maybe it won't add any compilation time, it could even be faster...

And then you add the new feature and your compile time goes crazy, that's unfortunate indeed, but that's the price of not being penalized at run time with the [cool new C++11 feature the upstream project is using], you have to endure a longer compile time. But you can't blame C++11 for it, without it that feature wouldn't even exist!

<comment><USER51> This makes more sense, but why is it not C++11's fault if compiler writers have a hard time keeping the compile time overhead in reasonable bounds? Compiler writers actually do not enable some optimization passes or cap some passes at a certain search level because they know the algorithmic complexity would be unacceptable for most users, although the performance benefit is clear.

The planned C++ module system will most likely solve a large set of the pain points.

</comment></comment></comment></comment></comment></comment></comment><comment><USER53> Just started to relearn c++ and QT for cross-platform GUI programs, c++ is not easy, but its performance is still unbeatable and in certain use cases, e.g. games or video-related-performance-critical-apps or GPU-opencl-etc, c++ seems to be the sole candidate still.

</comment><comment><USER54> I have a few problems with this article: >structure leads to complex code that eventually brings down the most desired characteristic of a source code: easiness of understanding.

If done well, the structure of things like variadic templates make libraries easier to use, and make coding faster (granted, code bloat can be an issue with N different function signatures).

>C++ today is like Fortran: it reached its limits

Not quite. Fortran died because well, object oriented programming came out and lots of people like it. And well, C was always more popular regardless so...C-like C++ was the obvious next choice. There is a lot of cruft in any new library, so some things aren't as performant as if you wrote them in say assembly, which is what the author seems to suggest. Yes, if I built a bare metal iostream-like functionality it would be more performant (ha, used the word :) ). People know iostream isn't that performant. Could it be better? Perhaps. Is it safe? Yes! If you want perf, use the C interface directly. Is that safe to use, probably not for the general careless user.

>To handle the type of speed that is being delivered in droves by the technology companies, C++ cannot be used anymore because it is inherently serial, even in massively multithreaded systems like GPUs.

Well, yes but so is just about every language. People are trained to write sequentially (left to right, top to bottom), with many exceptions...but none the less, sequentially. There are very few languages that do multithreading natively. There are lots of additions/libraries to C++ that enable very nice ways to consider parallelism (including w/in standard: std::thread), outside of standard (raftlib.io,hpx([https://github.com/STEllAR- GROUP/hpx](https://github.com/STEllAR-GROUP/hpx)),kokkos ([https://github.com/kokkos](https://github.com/kokkos)), etc.). There are lots, some are quite easy to use. C++ is inherently serial, but there is no better way to write. It is fairly easy to pull out "parallel" pieces of code to execute. It is even easier if the programmer gets quick feedback (like the icc loop profiler,etc.) on things like ambiguous references and loop bounds that can be fixed quickly.

Interesting read, but don't agree at all.

</comment><comment><USER55> I agree with the author; I still long for the not-overly-complicated C++ back in the 00s I could write super-fast 3D rendering engine without much bloat. I find it very appalling when C++ went from a poster child of imperative programming to implementing monads in its libraries (mind you, monads are used to "simulate" imperative programming in functional programming). Something went wrong there...

</comment><comment><USER56> I was once a C++ programmer but migrated first to Java, when I thought it was better designed and more convenient, and then to Python when I wanted less verbosity while having greater freedom to choose between a procedural style or OO.

C++ may still be an ideal choice in some problem spaces but I think the number and size of them has shrunk as more and better alternate choices have appeared and ate away at the C++ share.

</comment><comment><USER57> How are Verilog and VHDL a "new set of languages"? That set has been around 30 years, almost as long as C with classes.

</comment><comment><USER58> The problem with modern C++ is that it wants to be everything. Now this behemoth is crushing under its own weight.

People who are not forced to use C++ should consider other languages which are way cleaner and even more performant. Code written in Ada and Nim for instance is much easier to maintain.

</comment><comment><USER59> Wonder if they tried IncrediBuild to reduce their compile time? They are right that C++ - while faster than ever before - takes much longer to compile than many other languages.

<comment><USER60> Things like Incredibuild can only help so much. You still need to have a decent project structure, and enough computers to effectively cut down compile time.

Though (as mentioned in another comment) if your project is a big ball of inter dependencies then the link time will dominate.

I've seen compile times with Incredibuild that are less than a minute, but the link takes 5-10 minutes. Or better yet crashes due to the pdb size.

</comment></comment><comment><USER61> Am I the only one being redirected to a linkedin sign up screen?

<comment><USER62> I'm redirected too. I'm not signing up with Linked-In, agreeing to their policies, letting them spam me, etc just so I can read this article.

</comment></comment><comment><USER63> Being an expert FPGA programmer is easy, the problem is that small things take a really, really long time.

</comment><comment><USER64> > "that is where the unicorns are born: by people that can see on both sides > of the fence"

</comment><comment><USER65> Functional language programs have to run as interpreted. If compiled they will be too bloated.

</comment><comment><USER66> Anybody got an idea to which video series of Chandler Carruth he is referring to?

<comment><USER30> Here's a few:

\- "Tuning C++: Benchmarks, and CPUs, and Compilers! Oh My!" [https://www.youtube.com/watch?v=nXaxk27zwlk](https://www.youtube.com/watch?v=nXaxk27zwlk)

\- "Understanding Compiler Optimization" [https://www.youtube.com/watch?v=FnGCDLhaxKU](https://www.youtube.com/watch?v=FnGCDLhaxKU)

\- "Optimizing the Emergent Structures of C++" [https://www.youtube.com/watch?v=eR34r7HOU14](https://www.youtube.com/watch?v=eR34r7HOU14)

\- "Efficiency with Algorithms" [https://www.youtube.com/watch?v=fHNmRkzxHWs](https://www.youtube.com/watch?v=fHNmRkzxHWs)

The first one is really good if you've never benchmarked anything in a Linux environment. Or if you otherwise want to learn how to investigate how C++ gets turned into machine code.

</comment></comment><comment><USER67> Actually, the Author wants GO.

</comment><comment><USER68> His argument about simplicity resonates with me. Sure you can learn variadic templates and all that fancy stuff but in practice when you are working on production software in any company involving more than one person using the code base, it just pays in heaps to write the simplest easiest to understand code; meaning all that nice fancy stuff is almost never used.

</comment><comment><USER69> Kernel is my new home;

</comment><comment><USER69> Me too :)

</comment><comment><USER70> It just sounds like someone who couldn't handle C++ whining and making a bunch of blanket statements without really having any proper understanding.

I agree that some of the features such as lambdas can use to hard to track bugs (lifetime issues) and difficult to follow code when abused. When used nicely though they can lead to simple, elegant and straightforward code (anyone who tried to use the STL algorithms before lambdas knows what a pita it was most of the time).

Bottom line, if your code base is a mess don't blame the tool. Blame the programmers.

<comment><USER71> _Bottom line, if your code base is a mess don 't blame the tool. Blame the programmers._

The problem is the attitude towards these new features that naturally leads to programmers abusing them, building overabstracted complex bloated behemoths to accomplish the simplest of tasks.

I'd say the vast majority of programmers, for some reason, seem to have an appetite for complexity --- they tend to feel that overly complicating things somehow makes their code better, especially if they can use some new shiny fancy features in the process. I don't think like that so I don't know exactly why that is the case, but perhaps it has to do with the feeling of accomplishment from having written something "big", solving simple problems with complex solutions. Instead, I'm the opposite --- I like solving complex problems with simple solutions, which means code that is usually very straightforward and only occasionally makes use of some more advanced features of the language, when it helps simplify the solution.

<comment><USER72> A common assumption among C++ programmers seems to be that if an ounce of prevention is worth a pound of cure, the value of a ton of prevention must scale up similarly. But a ton of anything is too much weight for most projects to handle.</comment></comment></comment>


Goodbye privacy: Amazon Echo, the home robot who hears it all - <AUTHOR> http://www.theguardian.com/technology/2015/nov/21/amazon-echo-alexa-home-robot-privacy-cloud <comment><USER2> This Amazon product is not new and many cellphones have basically the same functionality that brings the same privacy issues.</comment>