Darren New wrote:

> It's about as complex as a case statement.

In particular, it *is* [part of] a case expression. ;-)

Post a reply to this message

Invisible wrote:
> Darren New wrote:
>> It's about as complex as a case statement.
> In particular, it *is* [part of] a case expression. ;-)

Yes, *I* know that. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >>>>     ([] , _  ) -> Nothing
> >>> Yeh, it's really clear what this line does to a non-Haskeller :-)
> > 
> >> I'll tell you what it does: It makes the function crash. o_O
> > 
> >   After this you should really stop picking on C variants (or at the very
> > least, not immediately compare them to Haskell). ;)

> Why? Because I wrote some code with a small typo?

  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.

  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.

-- 
                                                          - Warp

Post a reply to this message

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

Orchid XP v8 <voi### [at] devnull> wrote:
> 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".

  And?

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

  Actually you can catch exceptions in most systems, and you can resolve
the exact location of the crash using a debugger.

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

  Haskell is fairly (in)famous for its one-liners which do tons of things.

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

  Because you wrote it so. The C++ version could also have been written to
be as verbose and straightforward as possible. It's not like you *have* to
write dense code.

> For me, the question is not how obscure it looks, but how difficult it 
> is to explain it.

  Many Haskell one-liners would probably take entire books to explain.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> make a typo in a C program, the program stops and says "error: 
> segmantation fault".

*If* you're lucky.  What's worse is when it *doesn't*. :-)

> As far as I'm aware, you cannot catch segfaults.

You can, but not in a portable way, a language-defined way, or in a way 
that's useful for debugging or continuing on.  You cannot, for example, 
catch a segfault and use it to extend the size of the array you just ran off 
the end of.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Warp wrote:
>   Haskell is fairly (in)famous for its one-liners which do tons of things.

I think APL (and now J) is the canonical example for that.

>   Because you wrote it so. 

Well, the particular bit you complained about is no more complex than
    case 23: return 0;
in C. It's just that Haskell has literals that aren't in C, so "case 23" 
looks funky.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> make a typo in a C program, the program stops and says "error: 
>> segmantation fault".
> 
> *If* you're lucky.  What's worse is when it *doesn't*. :-)

Worse Than Failure.

>> As far as I'm aware, you cannot catch segfaults.
> 
> You can, but not in a portable way.

I had a feeling the OS might provide a way to do this. (Presumably 
that's how the shell tells you your program segfaulted.) And that would 
make it OS-dependent...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> 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".
> 
>   And?

And if your program stops with an exception, you can catch and handle 
it. If it segaults, AFAIK you can't do anything about it.

>   Actually you can catch exceptions in most systems, and you can resolve
> the exact location of the crash using a debugger.

C and C++ have debuggers which are actually useable. I'll give you that one.

>> 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.
> 
>   Because you wrote it so. The C++ version could also have been written to
> be as verbose and straightforward as possible. It's not like you *have* to
> write dense code.

No, BUT EVERYBODY DOES.

Nobody told this C++ programmer "hey, please write this in the most 
complicated way possible". He just did, out of habit.

Personally, I don't have a problem with being able to incriment or 
decriment a variable just by saying "x++" or whatever. It's a nice 
shortcut. But when you reach the point of performing an assignment and 
incriment at the same time... well, *I* certainly wouldn't write code 
like that. I'd be forever having to double-check whether the incriment 
happens before or after the assignment, and so on.

>> For me, the question is not how obscure it looks, but how difficult it 
>> is to explain it.
> 
>   Many Haskell one-liners would probably take entire books to explain.

Haskell allows you to do clever and rather opaque things such as compute 
a list of all the prime numbers in the universe in a one-liner, or 
Pascal's triangle, or the Fibonacci numbers, or whatever. And, yes, it 
takes some explaining to unravel.

*This* program, however, involves no such cleverness. Merely a few case 
expressions. Aside from the unfamiliar syntax, there's really little 
about it that's complex. No fancy tricks, no clever math, just a few 
conditional tests and a couple of function calls.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Orchid XP v8 wrote:
> > make a typo in a C program, the program stops and says "error: 
> > segmantation fault".

> *If* you're lucky.  What's worse is when it *doesn't*. :-)

  You seriously claiming that if you make a typo in Haskell, it always
magically knows that and gives you an error message?

-- 
                                                          - Warp

Post a reply to this message