"And its going to fail for the same reasons that C++ failed"
If only my successes were as successful as that failure. Back then, if you had a code base in C, migrating to C++ was easier than migrating to Smalltalk or Eiffel.
Similarly, today, migrating a C code base to C++ or and using its functional 'extensions' or starting to use those features in a C++ code base is easier than migrating it to Haskell or Scheme.
C++ is far from perfect, but it beat other contenders because of that feature.
And yes, if, as I expect, C++ remains popular, we will have books describing the pitfalls of functional-style programming (Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses"). For example, we will see blog posts lamenting the heavy nesting of map/apply/select chains because the resulting code, in some cases, will run out of instruction cache space, degrading performance.
Of course C++ didn't fail in the sense that it would lack popularity; I think the parent meant that C++ is a complex, horrible mess and that it failed in the "beauty contest" sense.
It also failed in the sense that it didn't eliminate all competition.
Yes, that is what I meant. Thanks for the clarification, although I think the term "beauty contest" trivialises the issue. Its not about beauty, its about buggy software.
Right. But until we have a comparable body of production software written in pure functional code -- and by comparable, I mean closer to the volume of code written in today's mainstream languages and by average developers, not a few applications written by elite developers -- we can't say for sure whether the pure functional approach does in fact prevent buggy software, or whether it simply leads to different kinds of bugs.
A lot of advocacy for functional programming and languages like Haskell makes claims about being safer because certain types of programmer error are prevented. However, relatively little commentary also highlights downsides like the need for accumulating parameters and strictness annotations just to achieve acceptable performance, or the maintenance hazards of having both monadic and non-monadic implementations of algorithms. Until someone finds a way to prove that a large-scale lazy functional program can't exceed the available system resources with an explosion of thunks, any claim that this approach is inherently safe seems rather premature.
So, library code and critical infrastructure would fall outside of the "vast majority of cases". :)
And again, the question there is "Did Heartbleed keep people from getting value out of OpenSSL?". The answer is no, even if the value provided wasn't as advertised. It was more useful to have something--anything!--than nothing.
'So, library code and critical infrastructure would fall outside of the "vast majority of cases".'
Arguably, though the limited sandboxes in wide deployment are sufficiently full of holes that most code provides some access to something that might be considered critical infrastructure.
'And again, the question there is "Did Heartbleed keep people from getting value out of OpenSSL?". The answer is no, even if the value provided wasn't as advertised. It was more useful to have something--anything!--than nothing.'
Possibly. Belief that you're secure when you aren't can quite definitely be much worse than no belief that you're secure, but I'm significantly less sure that Heartbleed moved many people from "sufficiently secure" to "insufficiently secure" in many individual cases (the possibility exists, I just lack the data to make any determination).
Also, for many use cases, there exist (and existed then, of course) alternatives that are probably more secure. If "nothing" meant using those instead it was quite a bit better to have "nothing".
If only my successes were as successful as that failure. Back then, if you had a code base in C, migrating to C++ was easier than migrating to Smalltalk or Eiffel.
Similarly, today, migrating a C code base to C++ or and using its functional 'extensions' or starting to use those features in a C++ code base is easier than migrating it to Haskell or Scheme.
C++ is far from perfect, but it beat other contenders because of that feature.
And yes, if, as I expect, C++ remains popular, we will have books describing the pitfalls of functional-style programming (Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses"). For example, we will see blog posts lamenting the heavy nesting of map/apply/select chains because the resulting code, in some cases, will run out of instruction cache space, degrading performance.