[nice_byte]

I'm a professional and you can take the lambdas out of my cold, dead hands.

Also, their examples are removed from reality. I've never seen people use lambdas like that. Most of the use cases I've seen are callbacks that get triggered on certain events (i.e. "display notification when background loading thread completes") and predicates (i.e. find_if). I see neither in their examples.

[jonstewart]

Of course students had problems—-it's one more damn thing for them to learn about C++, likely from professors that don't know it very well either. But <algorithm> is way more useful these days, and boost::asio is a dream.

[pjmlp]

Unfortunately most teachers aren't like Kate Gregory, and I fully agree with her, they should stop teaching C -> C++.

Already in 1994 it was obvious to me that it leads to bad unsafe code and worse, the mentality to micro-benchmark each code line.

[alfalfasprout]

There's pitfalls to everything. I find that a lot of people that only learned C++ end up writing nice-looking safe code that's very well organized but has awful memory usage and dubious performance characteristics. It's not that they're bad programmers or made poor algorithmic choices. It's that they've been indoctrinated with the fear of "premature optimization". Moreover, they don't really know any better if they do have optimization opportunities.

On the flip-side, the C programmer who starts out learning C++ will often spit out some hideous abomination that uses no namespaces, consists of obscure function names, pointers everywhere, and tons of callbacks.

Thing is, sometimes performance really matters. A large part of the HN audience focuses only on web-oriented programming. But in scientific computing, finance, etc. being able to squeeze out a few more operations/CPU cycle can be incredibly important.

I think rather than being dogmatic about the issue, as programmers tend to do, it's important to introduce students to C but be very clear about why you might want to use some of its features vs. relying on the safer C++ variants.

[pjmlp]

Agree, but most of the time performance matters less than people think.

In all my years as developer, even back on Spectrum, MS-DOS and Amiga, I never bothered turning off bounds checking and it seldom mattered for the type of applications I was writing.

The very few times it mattered, I was writing big chunks of Assembly anyway.

Everyone thinks their applications have the same performance requirements as Microsoft, Apple, Google, Facebook, CERN, Wall Street, Sony ... have, but they don't.

It is like the native code version of going web scale on day 1, when everything that one has are a few pages to display.

[sidlls]

Fear of premature optimization, fear of pointers, and fear of how computers work in general, yes.

Pointers should be used very sparingly, and much of the time in code I've seen they could have and should have been avoided. But it seems like we've come to some far extreme other side of that thought to the point where seeing a pointer instills an exaggerated fear of memory stomping, leaks, and a variety of other things. These are important concerns, but, like optimization, ought not make a person afraid of their use. Anybody who needs to do non-trivial programming at the systems level had better get over those fears and focus on learning how best to use the tools they need to, in my view.

[72deluxe]

Out of interest, I never learned C but went straight to C++. What in particular about C++ makes you believe that you'll write memory hogging programs?

[alfalfasprout]

Specifically, the STL has a lot of slow containers that people readily use. For example, a beginner might see a std::map<T> and think "wow, a handy hash table class!". First off, it's not a hash table (usually a RB tree). Second, the closest thing to a hash table in the STL (std::unordered_map<T>) is still pretty slow.

Then there's std::string. Super nice in 95% of cases but can cripple an application if you have millions of strings you need to deal with (TONS of dynamic memory allocation).

And then there's std::shared_ptr. Super convenient but potentially a huge impact if you have items with very short durations in hot loops. std::unique_ptr on the other hand has no added overhead. Sure, you can look these things up. But it's not really obvious.

C++ is an incredibly useful language. It's far from the safest, prettiest, etc. But when used properly it's a very powerful tool. But knowing C can help you to better understand when you're not getting something for free and when undefined behavior can rear its ugly head.

[72deluxe]

I see, interesting, thanks. I suppose the same problems arise attempting to use STL algorithms instead of using algorithms that are better suited to a specific container, eg. std::set::find instead of std::algorithm::find.

Being aware of what is happening and the best tools for the job I suppose! And knowing the STL inside out and its idiosyncrasies and foibles.

[jeremiep]

I've seen a game engine built on shared_ptr that had trouble getting a 2D game performing well on the PS3.

Its not that C++ will bloat your program, its that many programmers don't understand the tradeoffs of the primitives they're using, or don't have the experience or vision to see what they become at scale.

[72deluxe]

That last bit of your sentence is a great point - no vision to see what they become at scale, ie normally monstrous

[jeremiep]

I see that mentality in every language, even if its worse in C++ because "close to metal" and "we know C++, therefore we must be good programmers".

What usually happens is that the code gets unreadable/unmaintainable quickly and is still a complete unoptimized mess at the macro level.

Once you realize this you don't need C++ for most application domains. And for the domains where C++ matters you also realize you'd be better off in C with a scripting language on top.

[pjmlp]

Actually that is how I have been using C++ since around 2006, as an infrastructure language when JVM, .NET or ML languages cannot fulfil my use case, which happens very seldom.

And even though it was one of the languages I enjoyed most using after Turbo Pascal and I even gave C++ classes at the university, I am a firm believer that if Java, VB.NET and C# had been fully AOT compiled from day 1, just like many other alternatives that used to exist, C++ might have not taken off as it did.

The rise of VM languages, with other AOT compiled languages fading away and rise of FOSS written mostly in C, made C and C++ the only languages we could turn to when the performance was lacking, thus arriving at the actual situation.

As for using C with a scripting language, without the safety of strong type checking, real enumerations, support for arrays and strings, no namespaces, no RAII, new/delete instead of malloc()/free() and many of safety improvements from C++ over C, that is not something I will ever advise.

I already did that once with Tcl for two years, no need to repeat it.

[_hao]

In my university we started with C++ and pretty much everything was done in it (4 years). Although I've had C experience before that, I'd say that teaching C -> C++ to a complete beginner will be pretty hard on them and won't recommend it.