6 ms·

Haskell is very clean and readable. The problem, however, is that its such a departure from imperative languages that you can't bring much of anything you alre

Haskell is very clean and readable. The problem, however, is that its such a departure from imperative languages that you can't bring much of anything you already know over to it. You really do have to forget everything you're learned about programming and start from scratch. Until then, its all alien. That being said, I think that Haskell is the most clean looking of all the FP languages, but that's purely my opinion.

dragonwriter 12y ago
> The problem, however, is that its such a departure from imperative languages that you can't bring much of anything you already know over to it. I don't find that really true; if you've used any structured language with static typing, there's a lot of carryover, especially if you've ever done any formal study of CS, since even when imperative languages are used functional patterns are pretty common. The biggest problem I see is that there isn't a lot of pragmatic guidance on the bits that are unique to Haskell -- a lot of the documentation is very abstract, without a lot of guidance on solving specific real world problems. The power of Haskell is that you can make very general solutions in it quite easily; the weakness of the documentation of Haskell is that virtually all of it focusses on that highly general facilities and not enough on the kind of specifics that would help people get familiar with it while solving real problems.
tormeh 12y ago
Haskell suffers from people who want to make things look clean and achieve it by using symbols and very short names. These things have to be memorized before you can understand anything. Basically, people are trying to make Haskell code look like math and the truth is that math's symbolic notation is optimized for hand writing speed, /not/ reading comprehension. Take a look at Ada code. Maybe they're taking it a bit far, but it's very readable. Spelling words out and being very very sparing with symbols is a very good thing, I think.
- the_af 12y ago
  I don't think this is true. I think Haskell's notation is the way it is because it emphasizes the "look" of certain abstract patterns that would be obscured by the notation used in other languages (I believe this is the case for math as well... I doubt it's that way for hand writing speed, since I doubt that's the bottleneck in maths). This is not what many of us who come from other programming languages are used to, and therefore we identify it as "more difficult", but it actually is lack of familiarity. Not only with Haskell itself, but with the abstractions and the way of looking at programs. I doubt the majority of Haskell programmers would prefer a more verbose notation. I think that, like the parent post, they consider Haskell very clean and readable. A friend of mine who is a proficient Haskeller told me he often struggles to understand new Haskell libraries. Then the library "clicks" for him and he can begin to use it. I -- who program in Java for my day job -- have trouble understanding this, because this is seldom the case for Java: you may not understand what problem a Java library is intended to solve, but using it is usually trivial (and mis-using it is trivial as well, of course!). I think it's unfair to compare both languages this way, because in Java there is a fairly low use of general abstractions, and Java's syntax (and coding practices) have evolved to reflect this. The verbose syntax that works (1) for Java is not suitable for other kinds of programming. (1) for some values of "works".
  - klibertp 12y ago
    > since I doubt that's the bottleneck in maths I'm not a mathematician, but I heard that math is most frequently written on a whiteboard. If that's true, then optimizing for speed and space efficiency of hand-writing suddenly makes sense. > I doubt the majority of Haskell programmers would prefer a more verbose notation The exact same thing can be said about PERL programmers. But why stop there, take a look at APL, J, K languages. J, for example, ships with all standard verbs aliased to words, like "under", "behead", "curtail" etc. Of course, nobody uses those, they write "&.", "}.", "{." instead. The difference is that in J you have small, consistent core vocabulary (http://www.jsoftware.com/help/dictionary/vocabul.htm http://www.jsoftware.com/help/dictionary/vocabul.htm), and once you learn it and it "clicks", you very much are ready to do anything with the language. Haskell way makes you go through the same process again and again with almost every library. The sad thing is that you could write Haskell in a way which wouldn't require you to internalize large numbers of new symbols, but you generally don't. Is it really because of how much better the abbreviated, symbol-based notation is so much better, I have to wonder.
- klibertp 12y ago
  Well written - for some particular definition of "good" - Haskell is quite pleasant to read and work with. But, frequently, the code I see looks like mix of bash and PERL, only with a bit more consistent indentation. OCaml code, on average, has less symbol-based infix functions and tends to be more readable (for me). But I'm not a Haskell programmer, so maybe that's a matter of getting used to, like parens in Lisps...

dragonwriter 12y ago

> The problem, however, is that its such a departure from imperative languages that you can't bring much of anything you already know over to it. I don't find that really true; if you've used any structured language with static typing, there's a lot of carryover, especially if you've ever done any formal study of CS, since even when imperative languages are used functional patterns are pretty common. The biggest problem I see is that there isn't a lot of pragmatic guidance on the bits that are unique to Haskell -- a lot of the documentation is very abstract, without a lot of guidance on solving specific real world problems. The power of Haskell is that you can make very general solutions in it quite easily; the weakness of the documentation of Haskell is that virtually all of it focusses on that highly general facilities and not enough on the kind of specifics that would help people get familiar with it while solving real problems.

tormeh 12y ago

Haskell suffers from people who want to make things look clean and achieve it by using symbols and very short names. These things have to be memorized before you can understand anything. Basically, people are trying to make Haskell code look like math and the truth is that math's symbolic notation is optimized for hand writing speed, /not/ reading comprehension. Take a look at Ada code. Maybe they're taking it a bit far, but it's very readable. Spelling words out and being very very sparing with symbols is a very good thing, I think.

the_af 12y ago
I don't think this is true. I think Haskell's notation is the way it is because it emphasizes the "look" of certain abstract patterns that would be obscured by the notation used in other languages (I believe this is the case for math as well... I doubt it's that way for hand writing speed, since I doubt that's the bottleneck in maths). This is not what many of us who come from other programming languages are used to, and therefore we identify it as "more difficult", but it actually is lack of familiarity. Not only with Haskell itself, but with the abstractions and the way of looking at programs. I doubt the majority of Haskell programmers would prefer a more verbose notation. I think that, like the parent post, they consider Haskell very clean and readable. A friend of mine who is a proficient Haskeller told me he often struggles to understand new Haskell libraries. Then the library "clicks" for him and he can begin to use it. I -- who program in Java for my day job -- have trouble understanding this, because this is seldom the case for Java: you may not understand what problem a Java library is intended to solve, but using it is usually trivial (and mis-using it is trivial as well, of course!). I think it's unfair to compare both languages this way, because in Java there is a fairly low use of general abstractions, and Java's syntax (and coding practices) have evolved to reflect this. The verbose syntax that works (1) for Java is not suitable for other kinds of programming. (1) for some values of "works".
- klibertp 12y ago
  > since I doubt that's the bottleneck in maths I'm not a mathematician, but I heard that math is most frequently written on a whiteboard. If that's true, then optimizing for speed and space efficiency of hand-writing suddenly makes sense. > I doubt the majority of Haskell programmers would prefer a more verbose notation The exact same thing can be said about PERL programmers. But why stop there, take a look at APL, J, K languages. J, for example, ships with all standard verbs aliased to words, like "under", "behead", "curtail" etc. Of course, nobody uses those, they write "&.", "}.", "{." instead. The difference is that in J you have small, consistent core vocabulary (http://www.jsoftware.com/help/dictionary/vocabul.htm http://www.jsoftware.com/help/dictionary/vocabul.htm), and once you learn it and it "clicks", you very much are ready to do anything with the language. Haskell way makes you go through the same process again and again with almost every library. The sad thing is that you could write Haskell in a way which wouldn't require you to internalize large numbers of new symbols, but you generally don't. Is it really because of how much better the abbreviated, symbol-based notation is so much better, I have to wonder.
klibertp 12y ago
Well written - for some particular definition of "good" - Haskell is quite pleasant to read and work with. But, frequently, the code I see looks like mix of bash and PERL, only with a bit more consistent indentation. OCaml code, on average, has less symbol-based infix functions and tends to be more readable (for me). But I'm not a Haskell programmer, so maybe that's a matter of getting used to, like parens in Lisps...