Encouraged is a funny word, seeing as there's no other choice... but that's beside the point.

Having to dig out multiple libraries to make any non-trivial project is a pain. Having to worry about TinyXML's lack of standards compliance and proneness to buffer overruns (in an older version at least, not sure if it's still there), gsoap's godawful API, wrapping libpng's setjmp/longjmp error handling in exceptions, wrapping libcurl with RAII objects, or XYZ's exception safety, etc.

There's something nice to be said about having a very cohesive set of libraries by default. Same level of quality, same familiar style, same level of documentation, same integration with the rest of the library and language. C++ getting these things would not force you to use them, it would simply let devs bootstrap their apps a lot quicker, and far more robustly.

The C++ standard library is probably the highest quality standard library of any language I've seen.

It is documented down to an very low level. I can't count the number of time I've been using some .NET library only to find out that it has some undocumented requirement, quirk, or wildly unexpected time complexity. You never get things like that in the C++ standard library -- assuming you've read the documentation thoroughly, you should never be surprised.

The standard library takes full advantage of the language, and it's as lean as ever with the "don't pay for what you don't use" mantra generally remaining in full effect.

A downside? I may be able to develop something that uses a tenth the RAM and half the CPU in C++, but despite the strengths mentioned above, it's going to take me at least twice as long and I'm going to need to juggle a number of inconsistent 3rd party libraries -- no doubt some of them being plain C so I'll need to make some RAII wrappers, etc. -- it remains incredibly low-level.

Boost picks up some of the slack, but C++ really needs more of the things commonly used today. Things like HTTP, XML, web services, SQL, configuration, and cryptography should be built in, but they're only just now looking at a simple sockets library. This is a huge weakness. C++ is used in a lot of low-level situations so I don't know if these should be part of the standard library proper, but at the minimum an additional "framework" standard that implements high-level stuff for the more common unconstrained users would be immensely useful.

The language itself is very strong, and C++14 cements even more useful things into it. The only things I wish they'd add is LINQ and async functionality similar to C#.

If Theo had a more constructive outlook, this would go a lot different and we'd all benefit.

Instead of screaming vitriol at someone's app architecture inadvertently defeating his platform-specific feature, he should be asking why they felt the need to go with that architecture (hint: it was a perfectly reasonable need), and perhaps if he can do something to make integrating his security feature easier for that type of architecture.

Like you say, freelists are an extremely common design choice when performance is critical. This security feature could be hugely beneficial to many apps that use them (like, say, Apache HTTPd). Instead you've got the too-common case of an unbending programmer mad at someone for having needs other than his own.

People who don't use goto for error handling in C more often than not either have incorrect error handling or way too much error-prone duplication of resource cleanup code. It makes sense to very strictly warn newbies away from goto, much in the same sense that you warn them from multithreading. You don't want them used as a universal hammer for every nail in the code. At some point though, people need to jump off the bandwagon and learn to respect, not fear, these things that actually have some very compelling uses.

Unless a programmer is working for a very large company, there's a good chance they're in pretty direct contact with their users.

Throwing someone into contact with users doesn't help someone become good at UX. Just look at the multitude of Open Source projects -- most of them interact directly with users and still end up with pretty atrocious UX that is designed based on the programmer's workflow and how easy it is to implement.

Every time I hear this from a developer, I cringe. Good UX is a choice. You can train in it, but until you really alter your mindset towards user interaction and embrace it, your projects will suffer. It's so easy, too:

malloc's core functionality is to allocate memory. Any security additions are platform-specific and irrelevant.

A lot of large performance-sensitive projects implement custom allocators in the form of arenas and freelists. Lots of platforms have a fast malloc implementation these days, but none of them will be as fast as this for the simple reason that the program knows more about its memory usage patterns than any general-purpose allocator ever could.

Not to say I can't understand Theo's point of view -- if he wants maximum security, then a program which bypasses one of his layers in the name of performance might not be the best for him.

On the flip side, the standards have no notion of such security layers and I feel it is perfectly reasonable for a team to not throw away performance in the interests of some platform-specific behavior. This was a bug, pure and simple. There's nothing wrong with using custom allocators. To say that "OpenSSL is not developed by a responsible team" is simply nonsense.

People who buy TRD are generally going for either aesthetics (the TRD exhaust for GT86 is rather unique looking), warranty/insurance, or loans. Increase my payment by $10/mo for the TRD catback? Warrantied and insured without question? Awesome, go for it!

People looking for perf will always go third party. You'll never see a TRD intake that gives large gains because it needs to work with the stock ECU. Go third party and you can get a giant intake that requires MAF scaling or a catless header etc. -- so many more options that TRD simply won't offer.

I think you've misread my comment, or perhaps I've not expressed my position well enough. You're speaking like I've dismissed functional programming. I haven't. In fact, I really love it! The parts of it that have bled through into the more imperative/OO-focused languages, like C#'s LINQ and your Python example, are phenomenal and a joy to use.

So, here it is again: not saying functional is bad. Certainly not being dismissive or skeptical of it. I'd just like to see what compelling features haven't yet bled through. What makes pure functional or even just mostly-functional languages useful, that isn't yet in other languages? What is the killer feature, the killer problem they can still solve way easier?

If a good, experienced programmer dives deep into a language for a month and doesn't surface with anything compelling, how much more time should they spend? I'm not looking to master F#, I'm looking for a reason to master F#.

Can you give some examples? Many C-based languages have benefited by gaining strong functional aspects. With that, I haven't really found a reason to use a functional-focused language.

A while ago I decided to dedicate a month to coding in nothing but F# (my usual choices are C++ or C#) in attempt to find the areas they really kick-ass in, and just couldn't land on anything. There are some rare circumstances that I found it to be useful, but I just didn't find it compelling enough to warrant applying elsewhere. I'd never done functional programming before, I'm fully aware a month isn't long enough to master anything, but usually it's enough to discover if something has a really cool, earth-shattering aspect about it. So I'm honestly interested here -- what did I miss?

Every few months someone announces a new fad language despite them rarely bringing anything new to the table, or the new things they do bring not being significant enough to warrant switching from some other well-established one.

I'm actually happy with this one, because it serves an easier to justify purpose: migrating your existing PHP codebase and developers to something that is immediately better and familiar.

I wouldn't badmouth a former employer, specifically because future hiring managers would see it as a huge red flag. And that's kind of pathetic, if you think about it -- if you're having a terrible experience that your higher-ups show no care of fixing, is it not ethical to warn others away from a poisonous company? The industry has scored fear into us under a facade of "professionalism".