<br><br><div><span class="gmail_quote">On 4/18/07, <b class="gmail_sendername">Taillefer, Troy (EXP)</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><span class="q" id="q_112063b1cdd991ca_0">
<div><br><div><span><font color="#0000ff" face="Arial" size="2">
<div><span><font color="#0000ff" face="Arial" size="2">Sorry
for the long rant but I get tired of people with their juvenile and
unconstructive statements like "C++ sucks"</font></span></div>
<div><span>Or Language X is better then Language Y even
if it could ever be objectively true (which I am sorry it can't be) who
</font></span><br></div></div></span></div></blockquote></div><br><br clear="all">That's not really what I said, I simply said that Haskell is easier to reason about, and I find it is. And C++ is very difficult to reason about, so it's a good comparison (and an easy target :-)).
<br><br>This is getting a bit OT, the thread was about promoting the benefits of Haskell, not a language flame-war. The use of C++ was just a tongue-in-cheek example of a language where you have to spend more effort making sure your programs are correct because it's not as easy to reason about.
<br><br>End of message.<br><br>Beginning of counter-rant:<br><br>I write C/C++ every day, and a recent example of what I'm talking about is this:<br>We have a tool which does some very complex and full-of-special-cases processing. I'll abstract it a bit. It essentially does the tasks A, B, and C. Now, I need information in B, which is only available after C is computed. First off, in Haskell that wouldn't be a problem 'cause you'd just set up the relationships between your data and go home early. In C++ not only is this more or less impossible to sort out nicely (while keeping separate concerns separate), but even the work-around (which in my case means moving parts of C down below B) is way too fragile to be practical when you risk disrupting production. I mean in my case I can see no obvious reason for why I shouldn't just move that code around by looking at it, it LOOKS like it should work, but because it's C++ such an operation is like remodelling a house of cards. There's not telling how many cases that will break in subtle ways because of all the side effects and invisible dependencies. The end result? We just avoid the problem by not doing the Right Thing in certain circumstances. It sucks, but it beats the alternative of trying to "reason" about a complex C++ program and ending up with some obscure error or crash six months later.
<br><br>There's a bit of a turing tarpit like danger here. Where you fall into the habit of being the good guy, "defending" languages and insisting that they aren't that bad, the end result is that progress is slowed down. Languages are just tools. Would you "defend" a Black&Decker power drill? Comparing and criticizing them in order to end up with better tools (and a better knowledge about which tool is better when) is useful and should be done more often by more people.
<br><br>C++ really is quite bad when it comes to being able to reason about your program. Really. In Haskell, if you change a few function calls you know exactly what will happen because it's localized, in C++ it's not so simple because you have to worry about the side effects (not to mention all the caveats in the language itself -- see the "Effective C++" books for the short list of why C++ will stab you in the back at the first chance if you're not careful). There are reasons for using C++, but there is no denying that there are many good reasons for why you should choose something else instead if you can, and since this thread was about promoting the good stuff about Haskell, the ease-of-reasoning argument is certainly relevant (and I don't think it's all that controversial to use C++ as an example of a language which is difficult to reason about).
<br><br>-- <br>Sebastian Sylvan<br>+44(0)7857-300802<br>UIN: 44640862