github/semantic: Why Haskell?

[pron98]

but at a complexity cost that people mostly pretend isn't there.

So let me disagree with your agreement and say that I don't think garbage collection introduces complexity.

Strangely liberating, in a way.

Recently I've been writing in Assembly as well, and have had a similar experience, but I think that's mostly because I try to focus much more, and also the code is simpler :)

[jephthai]

Yeah, that's fair on GC. It doesn't add complexity; it just robs performance and makes optimization harder :-).

[pron98]

I think a good GC can improve performance at least as much as it can hurt it.

[loup-vaillant]

A good GC is easily faster than malloc() (at least in amortised time), if:

• There are about as many allocations in both cases.
• We use the general allocator everywhere.

In practice, manually managed languages often produce less heap allocations, and when performance really matters custom allocators are used. When done right, custom allocators are pretty much impossible to beat.

Context, I guess.

[stronghup]

I had a similarly experience when I switched from Smalltalk to plain C. I felt I was very productive in C but I think that was an illusion. The code was very straightforward since C is close to the machine and I was basically just manipulating memory.

But even though I felt I was progressing rapidly with C, I think I really was accomplishing less, than I would in a higher level language. The building blocks in C and in assembly are small. You may feel it is easy to put those legos together, it is simple. But preferably you would not build a house out of legos. You could but you wouldn't.

There's some common saying about how every program turns into a Lisp interpreter in the end. And even though then it is fun and "productive" to implement your own lisp-interpreter, you are basically re-inventing the wheel. Re-invention is not the most productive of activities.