FW: [Haskell-cafe] Tutorial on Haskell

[Sebastian Sylvan]

On 4/18/07, Taillefer, Troy (EXP) <troy.taillefer at lmco.com> wrote:
>
>
> Sorry for the long rant but I get tired of people with their juvenile and
> unconstructive statements like "C++ sucks"
> 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 cares.
>
>

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 :-)).

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.

End of message.

Beginning of counter-rant:

I write C/C++ every day, and a recent example of what I'm talking about is
this:
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.

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.

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).

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070418/7be97547/attachment.htm