6 ms·

> 1. There is a learning curve. Time and experience can cover up anything. So this does not say much about Haskell other than it is all negative without time a

> 1. There is a learning curve. Time and experience can cover up anything. So this does not say much about Haskell other than it is all negative without time and experience. > 2. Haskell has some very nice libraries So does NodeJS and (on an abstract level) Microsoft Word. Libraries are infrastructures and investments that (like time and experience) can cover up any shortcomings. > 3. Haskell libraries are sometimes hard to figure out That is simply negative, right? > 4. Haskell sometimes feels like C++ That is also negative, right? > 5. Performance is hard to figure out That is also negative, right? > 6. The easy is hard, the hard is easy That is a general description of specialty -- unless he means all hard are easy. > 7. Stack changed the game Another infrastructure investment. > 8. Summary: Haskell is a great programming language. ... I am a bit lost ... But if I read it as an attitude, it explains a lot about the existence of infrastructure and investment. Will overcomes anything.

codewithcheese 9y ago
I feel the same way. I think the Author was trying to give an honest opinion on the pitfalls. Would have been nice to hear about the honest benefits too.
scardine 9y ago
I don't think being like C++ is a negative and it is far easier to learn compared to Haskell.
hvs 9y ago
Every time I've tried to dedicate time to really learning Haskell, I've come away with the feeling, "If I was a lot smarter or had a lot more time to dedicate to it, this would be a fantastic language to develop in after about 2-3 years." The way that functions can compose in the hands of a gifted developer is truly elegant. That said, I'm not sure it's a skill that translates well to the general development community (and maybe that's fine?).
- BoiledCabbage 9y ago
  Out of curiosity, what method/resource did you use to try to learn it?
  - hvs 9y ago
    I've tried "Learn You A Haskell for Great Good" and "Real World Haskell".
    - BoiledCabbage 9y ago
      That was my guess, but I didn't want to be presumptuous. I tried with them and as well it didn't really stick. In my opinion "Learn You A Haskell" is a great supplememental reference, but a terrible teaching tool. And I think It's done more disservice to enforcing the reputation of Haskell being difficult to learn. I highly recommend the lecture notes online from the "Upenn Spring 2013 Haskell" class. Search that phrase and it should be the first hit (am on mobile). Go through the lecture notes, and do all the exercises in the homework. (Link in purple at the top). It's a night and day difference from LYAH. And you get to build some nifty real world style projects along the way. Good luck!
      - deleted 9y ago
        [deleted]
tetrep 9y ago
> The line that if it compiles, it’s probably correct is often true. That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide. And while that's still not a great fleshed out explanation, it's a great oversimplification of the symptoms of a programming language with a great type system. And that type system is more or less the only reason to use Haskell. As other people in this thread have commented, Haskell has fantastic abstract libraries, which let you do abstract things, the most useful of which that I'm aware of/understand is parsing. Parser combinators are a very natural fit for Haskell, and making DSLs with them becomes practically trivial to do. Edit: I think the author takes for granted the general praise that Haskell gets, and was attempting to temper it with his practical experiences using the language.
- maxxxxx 9y ago
  "That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide." That's interesting. I am pretty aggressive with C++ refactoring because the compiler will tell me what's wrong. Especially compared to JavaScript for example. In what way does the Haskell compiler provide better error checking?
  - zzalpha 9y ago
    The semantics of the program can be more thoroughly encoded in Haskell's far more powerful type system. So if the program type checks you're far more likely to have a correct program than in a language like C++ or Java.
- Merad 9y ago
  > I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide. That's precisely what I was doing at work today in a C# project. I was going particularly crazy today, doing some refactoring with project wide regex replaces rather than leaning on VS/Resharper for everything. I think it depends a lot on how your project is structured. If you're passing around object everywhere and casting... you're gonna have a bad time, sure. But at that point you're practically using Python or something. If you're using generics and so on properly, then you can lean on the compiler and type system quite a lot.
luispedrocoelho 9y ago
OP here. The point about a learning curve is that Haskell is different from most mainstream programming languages. > > 2. Haskell has some very nice libraries > So does NodeJS and (on an abstract level) Microsoft Word. > Libraries are infrastructures and investments that (like > time and experience) can cover up any shortcomings. Javascript is one of the most widely used languages in the world and MS Word leverages the Microsoft ecosystem, which is another of the most widely used development environments. It's when you use less widely used environments (and Haskell may be borderline here) that you need to start worrying about libraries being available. I would not go as far as claiming that Haskell is as good as Javascript in that respect, but it is pretty good. > > 4. Haskell sometimes feels like C++ > That is also negative, right? I actually like C++ a lot. It's also one of the most successful programming languages in the history of programming languages, so it has something going for it. > > 5. Performance is hard to figure out > That is also negative, right? Yes, it's a pitfall. > > 7. Stack changed the game > Another infrastructure investment. Yes, tooling matters.
- hzhou321 9y ago
  So you understand I was commenting that your post didn't really say much about Haskell (learning curve, libraries, tooling ). What you commented or implied is a bit of current Haskell culture. > I actually like C++ a lot. Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends). I simply find your comparisons odd. Given their deliberate design choice difference and it ended up feeling alike, how can that be positive?
  - luispedrocoelho 9y ago
    > Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends). Haskell is also a continuous patchwork, just look at the number of deprecated GHC extensions.
    - hzhou321 9y ago
marcosdumay 9y ago
> (#1) Time and experience can cover up anything. This is simply not true. Time and experience can never cover up for lack of expressiveness, and expressiveness is one of the biggest selling points of Haskell. In fact, experience can only cover for complexity, and lack of discoverability or intuitiveness. Haskell has all those three flaws, so you see, experience is really needed. > (#2) So does NodeJS and (on an abstract level) Microsoft Word. No, they don't. Javascript and macro Basic do not even have enough expressiveness for supporting the kind of library you'll find in Haskell. > (#3) That is simply negative, right? That's the inevitable downside of #2. > (#6) That is a general description of specialty -- unless he means all hard are easy. Well, not all obviously. You still can't declare "f = solution to SAT in polynomial time" and be done with that. But the sheer amount of hard stuff that becomes easy is unsettling. About #8, I'll let it open. Experience and investment can certainly not overcome anything as you claim, but I'm still not decided wether to classify Haskell as "the best available for nearly anything (maybe except if you have a killing library in another language)" or "hell, why can't somebody just come and rewrite it as something _simple_", or both.
- hzhou321 9y ago
  > Time and experience can never cover up for lack of expressiveness Expressiveness is subjective. Experience can alter one's perception. In fact, time and experience alter the basis of comparisons, from objective comparisons to subjective comparisons. > No, they don't. Javascript and macro Basic do not even have enough expressiveness for supporting the kind of library you'll find in Haskell. You mean you can express the idea of taking browser screenshot (for example) or producing a publisher acceptable document with the same kind of ease(expressiveness in my dictionary) in Haskell? Again, without specifics, the comparisons does not mean much -- which was all I was commenting. > But the sheer amount of hard stuff that becomes easy is unsettling. Another meaningless subjective word (sheer). I wasn't debasing Haskell. I was commenting on the meaningless of original post.
  - zzzzzzzza 9y ago
    haskell is objectively expressive. (where expressive means amount of logic per character) there are multiple reasons for this, kind've tied together. Whitespace is function application (no parenthesis to keep track of like lisp, or even e.g. c, java, or javascript, when programming in a functional style). Immutability forces you to compartmentalize and compose everything. when everything is a function, function and variable names serve as VERY powerful documentation, especially when combined with haskell's also VERY powerful type system (which e.g. has sum types where most languages do not, which allows for example, defining most error states of program as a data type (which can then derive from any typeclass)). one of the primary benefits of laziness is to make function composition possible under a wider variety of situations (which also increases expressiveness, at the cost of occasional though not difficult to avoid space leaks) one joke I've heard is that the ideal haskell program is 20 lines of imports and one line of perl.
throwaway110034 9y ago
> ... I am a bit lost Google "cognitive dissonance" and the "sunk cost fallacy."
- nv-vn 9y ago
  The point of the article was focusing on things to fix. Having used Haskell, there's a great many things that were worth the cost of learning it. For one thing, it's made me a vastly better programmer in other languages. It lets me appreciate better styles of writing code and think outside the box when solving things. Using Haskell also gives me the tools for many projects to write code almost thoughtlessly -- you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system. Libraries exist for abstractions you wouldn't even think of in other languages that can cut down the code to 1/100th the length it would be and maintain expressiveness and type safety. At the same time, I don't find myself using Haskell all that often because I do think it's missing a lot of things I desire, but depending on what you're working on it can be very far from a sunk cost.
  - throwaway110034 9y ago
    > you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system That is dangerously close to the infamous "if it compiles, then it works" boast, which Haskellers make all the time (while denying that they make it), demonstrating in the process that they don't write real software, where the defects one encounters are very often of a nature such that the program behaves exactly as intended by its authors, but the intended behavior is itself wrong. How does the type system help here? My comment wasn't glib. I actually think those phenomena quite well explain much Haskell advocacy. Considering how massive an undertaking it is to learn the language and its Byzantinely-complex, PhD-theses-in-disguise libraries (each of which sports a zoo of custom operators) and how small the payoff is, it's unsurprising that those who take the plunge begin zealously encouraging others to do the same, lest their own investment have been for nothing. In a way it's like a conspiracy.
    - 9y ago

codewithcheese 9y ago

I feel the same way. I think the Author was trying to give an honest opinion on the pitfalls. Would have been nice to hear about the honest benefits too.

scardine 9y ago

I don't think being like C++ is a negative and it is far easier to learn compared to Haskell.

hvs 9y ago

Every time I've tried to dedicate time to really learning Haskell, I've come away with the feeling, "If I was a lot smarter or had a lot more time to dedicate to it, this would be a fantastic language to develop in after about 2-3 years." The way that functions can compose in the hands of a gifted developer is truly elegant. That said, I'm not sure it's a skill that translates well to the general development community (and maybe that's fine?).

BoiledCabbage 9y ago
Out of curiosity, what method/resource did you use to try to learn it?
- hvs 9y ago
  I've tried "Learn You A Haskell for Great Good" and "Real World Haskell".
  - BoiledCabbage 9y ago
    That was my guess, but I didn't want to be presumptuous. I tried with them and as well it didn't really stick. In my opinion "Learn You A Haskell" is a great supplememental reference, but a terrible teaching tool. And I think It's done more disservice to enforcing the reputation of Haskell being difficult to learn. I highly recommend the lecture notes online from the "Upenn Spring 2013 Haskell" class. Search that phrase and it should be the first hit (am on mobile). Go through the lecture notes, and do all the exercises in the homework. (Link in purple at the top). It's a night and day difference from LYAH. And you get to build some nifty real world style projects along the way. Good luck!
    - deleted 9y ago
      [deleted]

tetrep 9y ago

> The line that if it compiles, it’s probably correct is often true. That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide. And while that's still not a great fleshed out explanation, it's a great oversimplification of the symptoms of a programming language with a great type system. And that type system is more or less the only reason to use Haskell. As other people in this thread have commented, Haskell has fantastic abstract libraries, which let you do abstract things, the most useful of which that I'm aware of/understand is parsing. Parser combinators are a very natural fit for Haskell, and making DSLs with them becomes practically trivial to do. Edit: I think the author takes for granted the general praise that Haskell gets, and was attempting to temper it with his practical experiences using the language.

maxxxxx 9y ago
"That is the meat of why Haskell is so great. I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide." That's interesting. I am pretty aggressive with C++ refactoring because the compiler will tell me what's wrong. Especially compared to JavaScript for example. In what way does the Haskell compiler provide better error checking?
- zzalpha 9y ago
  The semantics of the program can be more thoroughly encoded in Haskell's far more powerful type system. So if the program type checks you're far more likely to have a correct program than in a language like C++ or Java.
Merad 9y ago
> I've never so reckless refactored code as much as I do in Haskell, I just wait for the compiler to tell me what I missed and go back and fix it up. I'd never do that in C, C++, Java, etc; it'd be suicide. That's precisely what I was doing at work today in a C# project. I was going particularly crazy today, doing some refactoring with project wide regex replaces rather than leaning on VS/Resharper for everything. I think it depends a lot on how your project is structured. If you're passing around object everywhere and casting... you're gonna have a bad time, sure. But at that point you're practically using Python or something. If you're using generics and so on properly, then you can lean on the compiler and type system quite a lot.

luispedrocoelho 9y ago

OP here. The point about a learning curve is that Haskell is different from most mainstream programming languages. > > 2. Haskell has some very nice libraries > So does NodeJS and (on an abstract level) Microsoft Word. > Libraries are infrastructures and investments that (like > time and experience) can cover up any shortcomings. Javascript is one of the most widely used languages in the world and MS Word leverages the Microsoft ecosystem, which is another of the most widely used development environments. It's when you use less widely used environments (and Haskell may be borderline here) that you need to start worrying about libraries being available. I would not go as far as claiming that Haskell is as good as Javascript in that respect, but it is pretty good. > > 4. Haskell sometimes feels like C++ > That is also negative, right? I actually like C++ a lot. It's also one of the most successful programming languages in the history of programming languages, so it has something going for it. > > 5. Performance is hard to figure out > That is also negative, right? Yes, it's a pitfall. > > 7. Stack changed the game > Another infrastructure investment. Yes, tooling matters.

hzhou321 9y ago
So you understand I was commenting that your post didn't really say much about Haskell (learning curve, libraries, tooling ). What you commented or implied is a bit of current Haskell culture. > I actually like C++ a lot. Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends). I simply find your comparisons odd. Given their deliberate design choice difference and it ended up feeling alike, how can that be positive?
- luispedrocoelho 9y ago
  > Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends). Haskell is also a continuous patchwork, just look at the number of deprecated GHC extensions.
  - hzhou321 9y ago

marcosdumay 9y ago

> (#1) Time and experience can cover up anything. This is simply not true. Time and experience can never cover up for lack of expressiveness, and expressiveness is one of the biggest selling points of Haskell. In fact, experience can only cover for complexity, and lack of discoverability or intuitiveness. Haskell has all those three flaws, so you see, experience is really needed. > (#2) So does NodeJS and (on an abstract level) Microsoft Word. No, they don't. Javascript and macro Basic do not even have enough expressiveness for supporting the kind of library you'll find in Haskell. > (#3) That is simply negative, right? That's the inevitable downside of #2. > (#6) That is a general description of specialty -- unless he means all hard are easy. Well, not all obviously. You still can't declare "f = solution to SAT in polynomial time" and be done with that. But the sheer amount of hard stuff that becomes easy is unsettling. About #8, I'll let it open. Experience and investment can certainly not overcome anything as you claim, but I'm still not decided wether to classify Haskell as "the best available for nearly anything (maybe except if you have a killing library in another language)" or "hell, why can't somebody just come and rewrite it as something _simple_", or both.

hzhou321 9y ago
> Time and experience can never cover up for lack of expressiveness Expressiveness is subjective. Experience can alter one's perception. In fact, time and experience alter the basis of comparisons, from objective comparisons to subjective comparisons. > No, they don't. Javascript and macro Basic do not even have enough expressiveness for supporting the kind of library you'll find in Haskell. You mean you can express the idea of taking browser screenshot (for example) or producing a publisher acceptable document with the same kind of ease(expressiveness in my dictionary) in Haskell? Again, without specifics, the comparisons does not mean much -- which was all I was commenting. > But the sheer amount of hard stuff that becomes easy is unsettling. Another meaningless subjective word (sheer). I wasn't debasing Haskell. I was commenting on the meaningless of original post.
- zzzzzzzza 9y ago
  haskell is objectively expressive. (where expressive means amount of logic per character) there are multiple reasons for this, kind've tied together. Whitespace is function application (no parenthesis to keep track of like lisp, or even e.g. c, java, or javascript, when programming in a functional style). Immutability forces you to compartmentalize and compose everything. when everything is a function, function and variable names serve as VERY powerful documentation, especially when combined with haskell's also VERY powerful type system (which e.g. has sum types where most languages do not, which allows for example, defining most error states of program as a data type (which can then derive from any typeclass)). one of the primary benefits of laziness is to make function composition possible under a wider variety of situations (which also increases expressiveness, at the cost of occasional though not difficult to avoid space leaks) one joke I've heard is that the ideal haskell program is 20 lines of imports and one line of perl.

throwaway110034 9y ago

> ... I am a bit lost Google "cognitive dissonance" and the "sunk cost fallacy."

nv-vn 9y ago
The point of the article was focusing on things to fix. Having used Haskell, there's a great many things that were worth the cost of learning it. For one thing, it's made me a vastly better programmer in other languages. It lets me appreciate better styles of writing code and think outside the box when solving things. Using Haskell also gives me the tools for many projects to write code almost thoughtlessly -- you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system. Libraries exist for abstractions you wouldn't even think of in other languages that can cut down the code to 1/100th the length it would be and maintain expressiveness and type safety. At the same time, I don't find myself using Haskell all that often because I do think it's missing a lot of things I desire, but depending on what you're working on it can be very far from a sunk cost.
- throwaway110034 9y ago
  > you can just start writing in a declarative style and not worry about debugging, because everything is checked by the type system That is dangerously close to the infamous "if it compiles, then it works" boast, which Haskellers make all the time (while denying that they make it), demonstrating in the process that they don't write real software, where the defects one encounters are very often of a nature such that the program behaves exactly as intended by its authors, but the intended behavior is itself wrong. How does the type system help here? My comment wasn't glib. I actually think those phenomena quite well explain much Haskell advocacy. Considering how massive an undertaking it is to learn the language and its Byzantinely-complex, PhD-theses-in-disguise libraries (each of which sports a zoo of custom operators) and how small the payoff is, it's unsurprising that those who take the plunge begin zealously encouraging others to do the same, lest their own investment have been for nothing. In a way it's like a conspiracy.
  - 9y ago