|
|
Warp wrote:
> Because it's exactly as (or even more) obfuscated as your hated C, and
> it seems to be equally easy to make something "crash" by mistake.
If you make a typo in a Haskell program, the program stops and says
"error: you tried to access the first element of an empty list". If you
make a typo in a C program, the program stops and says "error:
segmantation fault".
The former is easier to debug [although, admittedly, it gives you
absolutely no indication of *where* the program crashed], while the
latter is no fun at all. Also, the former is an *exception*. You can
catch exceptions and handle them if you want. As far as I'm aware, you
cannot catch segfaults.
> Also you should understand that the Haskell line might not be obfuscated
> to *you* because you know how to read it, but it's quite obfuscated to
> others who don't understand it. The same works for C as well. Thus you
> really don't prove anything by saying "that piece of C(++) is really
> obfuscated, I don't understand it, here's how I would write it in Haskell"
> and proceed to present a program which is at least as obfuscated.
Performing multiple steps all at once in a small blob of symbols? Sounds
fairly non-trivial to me. By contrast, the Haskell version doesn't use
any remotely advanced features of Haskell, just a few case expressions
with some basic pattern matching. No monads, no typeclasses, no
existential types, nothing. Just plain ordinary pattern matching.
For me, the question is not how obscure it looks, but how difficult it
is to explain it.
FWIW, I think this particular algorithm itself is pretty tricky, no
matter which language you use for it.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|