3 ms·

Is that then a limitation of the language? I've only briefly toyed with Haskell (and most of the time I use PHP, so my opinion is almost moot). But from what yo

by blowski 10y ago

Is that then a limitation of the language? I've only briefly toyed with Haskell (and most of the time I use PHP, so my opinion is almost moot). But from what you've written, it sounds like it's hard to write Haskell that's expressive for novices and experts at the same time.

catnaroek 10y ago
> Is that then a limitation of the language? How exactly is it a limitation that the language has greater expressive power than most? Haskell does have serious limitations: laziness is a horrible default, modularity is a joke, reasoning about performance is very difficult, and the correctness of most basic abstractions is conditional on the user never ever using a partial function, not even accidentally - or else hilarity ensues. But functors, applicatives and monads are godsend.
nilkn 10y ago
Personally I don't think it's a limitation of the language so much as it is an artifact of Haskell's relative uniqueness. Most programmers have never encountered a type system stronger than that of, say, Java, so they have little to no precedent for this sort of language. Consequently, the very idea of a generic fmap (i.e., <$>) is foreign and new.
eof 10y ago
> it's hard to write Haskell that's expressive for novices and experts at the same time. That is definitely a fair analysis. Though I suppose that is a limitation it is not necessarily a severe one, or one that should matter to most people putting code in production. Haskell in general is extremely unfriendly to novices; but what you lose in accessibility you gain ten fold in maintainability. Haskell in general requires far, far more upfront problem solving than something like PHP or Javascript. It's easy to take for granted the implicit coercion, smart defaults, overlapping scopes when working in PHP to iteratively work on a problem. In haskell you are more likely to need a pretty good idea of what the final solution will look like before you even get the code compiling the first time, unlike php/js where you can write one or two lines, check the output, rinse and repeat.
sclv 10y ago
If you think reading X loc/min is the norm, and then hit a language where you read much slower, you might think "this is hard to read". But if you're reading the same density of _logic_ at the same speed, then that's not a drawback. If the haskell is say 3x as dense in logic, then reading at 1/3 the speed isn't a drawback at all...

by blowski 10y ago

catnaroek 10y ago

> Is that then a limitation of the language? How exactly is it a limitation that the language has greater expressive power than most? Haskell does have serious limitations: laziness is a horrible default, modularity is a joke, reasoning about performance is very difficult, and the correctness of most basic abstractions is conditional on the user never ever using a partial function, not even accidentally - or else hilarity ensues. But functors, applicatives and monads are godsend.

nilkn 10y ago

Personally I don't think it's a limitation of the language so much as it is an artifact of Haskell's relative uniqueness. Most programmers have never encountered a type system stronger than that of, say, Java, so they have little to no precedent for this sort of language. Consequently, the very idea of a generic fmap (i.e., <$>) is foreign and new.

eof 10y ago

> it's hard to write Haskell that's expressive for novices and experts at the same time. That is definitely a fair analysis. Though I suppose that is a limitation it is not necessarily a severe one, or one that should matter to most people putting code in production. Haskell in general is extremely unfriendly to novices; but what you lose in accessibility you gain ten fold in maintainability. Haskell in general requires far, far more upfront problem solving than something like PHP or Javascript. It's easy to take for granted the implicit coercion, smart defaults, overlapping scopes when working in PHP to iteratively work on a problem. In haskell you are more likely to need a pretty good idea of what the final solution will look like before you even get the code compiling the first time, unlike php/js where you can write one or two lines, check the output, rinse and repeat.

sclv 10y ago

If you think reading X loc/min is the norm, and then hit a language where you read much slower, you might think "this is hard to read". But if you're reading the same density of _logic_ at the same speed, then that's not a drawback. If the haskell is say 3x as dense in logic, then reading at 1/3 the speed isn't a drawback at all...