>> Warp seems to access the Internet only to tell me I've mis-spelt things. 
> 
>   It's "misspelt"! ;)

YOU ARE PEOPLE SEEING THIS?! >_<

>> OTOH, Warp is clearly a God-like programmer, and when He says something 
>> about programming, he's usually right. (Though not always.) Go ask him 
>> what the most efficient way to implement a Huffman tree in C++ is; I bet 
>> he knows.
> 
>   I'm not always right. Making yourself look smarter than you really are
> is an art.

You seem to be right far more often than me.

>   Of course when someone more knowledgeable about the subject calls your
> bluff, it can be really embarrassing. Admitting that you were wrong can
> be really difficult.

Yeah. And look at this: First you proved that my "efficient" program is 
actually 40x too slow, and I was forced to admit defeat. And then I 
asked about it on the Haskell list, but I made one stupid mistake: I 
retyped the code from memory, rather than copying it. And guess what? 
The example code I posted doesn't work properly. So now I've get a 
second bunch of people telling me how stupid I am.

I'm having such a great day. :-(

I really thought Haskell was the be-all and end-all of everything. Being 
forced to admit that it is not is really painful.

>   Haskell doesn't suck. The only problem I find with it is that it's not
> very approachable. It's hard to learn.

It works completely differently to normal languages. This has several 
consequences:

- It has a different set of strengths and weaknesses compared to normal 
languages. Some stuff that's usually hard becomes breathtakingly easy. 
And, yes, some stuff that's usually easy becomes somewhat harder too.

- You're not just learning a new syntax or a new set of scoping rules. 
It's a whole new game, which makes the learning curve kinda vertical. 
All the rules of the game are totally different, and while the rules are 
quite simple, this demands a totally new strategy. (Look at Go. The 
rules are pretty damned simple, eh? But the *game* is not!)

- The documentation... sucks. Truly. (Perhaps my saying this is why 
people think I'm a troll?)

>   It also seems that while Haskell can be used to create very efficient
> programs, it often happens that some properties of the language kick you
> in the groin when you try to do things in a simple way, resulting in a
> very inefficient program. You really need to know the inner workings of
> the language, the compiler and the libraries in order to be able to create
> the efficient implementation.

A few days ago, I'd have disagreed. I'd have said that you *can* write 
things simply and get good performance.

But today, we both know that's not actually true. Me, Mr Haskell Expert, 
wrote some code, and the performance was awful.

(I am reliably informed that "GHC does not currently fuse left folds". 
If that's true, that would explain one or two things... But all this 
really does is reinforce your point: you must memorise what the compiler 
does and does not optimise to get good code.)

>   (Of course the same is true for C++ and probably all languages. It's just
> that Haskell seems to be often advertised as "if it compiles, it works, and
> it's efficient", which doesn't seem true to me. You can often write clever
> one-liners which achieve things which would need dozens of lines in other
> languages, but that doesn't automatically mean the resulting program is
> efficient (or even correct).)

"If it compiles, it works correctly."

This is easily falsifiable. However, Haskell _does_ have the unusual 
property that, in the majority of real-world cases, if the type checker 
is happy, your program actually does what you wanted it to do. Few other 
languages have this property, and nobody is quite sure exactly why 
Haskell has it. (Though everybody has their theory.)

"If it works, it's efficient."

This is the ultimate goal, but we're not there yet.

A few days ago, I'd have said we're closing in fast. Now I'm really not 
so sure. Lots of people are very actively working on this; you don't 
often seem to hear about GCC getting some fancy new tool added to its 
box of tricks, but if you search around you can find all sorts of 
published papers about the sophisticated optimisation possibilities 
being added to GHC every year. After reading this stuff for a while, you 
end up with the impression that GHC is this super-powerful compiler that 
can make anything go fast.

The reality is rather more dissappointing.

I *still* believe that Haskell makes it possible to write programs that 
would just be too hard in any other language. (E.g., Parsec makes it 
really very easy to quickly throw a parser together. I've never managed 
to build a working nontrivial parser in any other language.) But maybe 
in a few days' time I'll have stopped believing that too...

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

Post a reply to this message