4 ms·

I think this (short) article had a lot of good points, though I do take minor issue with one bit: > Some people learn Haskell with the expectation that they wi

I think this (short) article had a lot of good points, though I do take minor issue with one bit: > Some people learn Haskell with the expectation that they will achieve some sort of programming enlightenment or nirvana. You will be disappointed if you bring these unrealistic expectations to the language. While I have not achieved any sort of nirvana, I do believe that learning Haskell has "enlightened" me insofar as I now look at programming in a fundamentally different way. I put a much greater emphasis on writing many small functions, I use types wherever possible (and type hints too, since Python is my primary language), and I avoid side-effects when I can. All of these things I do because Haskell taught me just how powerful simplicity can be. I also learned about different ways to conceptualize the relationships between data, and I learned about laziness (something I'd never heard of before then). Haskell has a lot to offer for people who come from an imperative background. > Haskell is not an achievement to unlock or a trophy to be won because learning is a never-ending process and not a finish line. While you can never "finish" learning, you can set milestones to mark your achievement. Comprehending some of Haskell's features (both the basics and the advanced ones) are perfectly acceptable milestones by which to track progress. I don't think that's a bad thing. --- That said, overall the article is very good. I agree that newcomers should write small programs, get their hands dirty, and learn to really use the basic features of the language firsthand before moving on to more advanced things. (And especially I agree that new users should avoid typeclasses at first, or even at second.)

orblivion 8y ago
Came here to say the same re: nirvana. Maybe keep moderate expectations, but yeah it did open something up for me. I think the truth is somewhere between "programming nirvana" and "no more null pointers and undefined functions".
nitrix 8y ago
Here, you're basically re-iterating the same point the author made. Some of it was written implicitly while the rest is laid out in a way that induces the mentality you're after, yet, without making any promises based on perceived benefits.
deleted 8y ago
[deleted]
ramanathanrv 8y ago
Regarding `avoid side-effects`, the amount of side-effects that are required for a typical real problem solving code base is quite reasonably measurable. For example, the number of network calls, DB calls, FileSystem read/writes are are measurable. Have you been able to reduce the `side-effects` significantly or have just become more aware of it? When we started using ExpressJS (coming away from Java), there was a tremendous change. As soon as you begin to code in Javascript (say from Java/Ruby/Python world), async hits you. There is no escaping it. And the programmer faces a tax (every time when implementing async/await or generators), his/her awareness about side-effects (deliberately generalizing IO as side-effects) and they tend to be more careful with it.
- nightski 8y ago
  Avoiding side effects sounds like something someone new to Haskell would say. Haskell in no way avoids side effects. Actually I'd say it embraces them by introducing special semantics just for them! What it does do is encourage you to move side effects to the "edge" of your code base and produce a more clean separation between pure & non-pure code. This is incredibly valuable for testing and overall correctness.
  - DonaldPShimoda 8y ago
    Right, and this is what I actually meant. It's not that side-effects disappear, but rather that I try not to litter my code with them. I avoid them in the sense that I don't embrace a side-effect-heavy style of coding, as I did with my imperative code prior to learning Haskell. Perhaps I could have worded that better. Sorry for the confusion.
- DonaldPShimoda 8y ago
  > Have you been able to reduce the `side-effects` significantly or have just become more aware of it? Yes, sorry, I think I didn't explain myself very well. Prior to learning Haskell and embracing The Way, my code was fairly covered in side-effects. I was a relatively junior programmer at this point (many years of experience because I started young, but few years of real education). Side-effects were just, you know, a thing that happened because they were "the easy way". After learning Haskell, I became much more conscious of side-effects. I realized that a lot of things I used to do could be done without side-effects, mostly by writing better functions and thinking more deliberately about how to eschew the side-effects. That said, it's not like they're gone. It's just that I'm much more careful about them. I "avoid" them in that I do my best not to include them, but if there's a genuine use for them then that's fine. However, I have taken to naming my functions better to reflect their side-effecting nature, and I try to move the side-effecting functions to places that make more logical sense (instead of just wherever).
Woberto 8y ago
> While I have not achieved any sort of nirvana, I do believe that learning Haskell has "enlightened" me insofar as I now look at programming in a fundamentally different way Can I ask whether Haskell in particular led to this enlightenment, or if functional programming is the underlying concept responsible? I've been considering learning Julia for fun and am wondering if it would impart some of the same benefits.
- DonaldPShimoda 8y ago
  I think functional programming in general is part of it, for sure. That said, my first success with functional programming was actually with Racket. Racket is great for learning (in my opinion), but the "lessons" Racket had to offer weren't really solidified for me until I moved to Haskell. At that point, things really started to click. That could be due to any number of things, though. However, certain concepts (e.g., laziness, typeclasses) are more Haskell-specific (or at least are not common among all functional languages).

orblivion 8y ago

Came here to say the same re: nirvana. Maybe keep moderate expectations, but yeah it did open something up for me. I think the truth is somewhere between "programming nirvana" and "no more null pointers and undefined functions".

nitrix 8y ago

Here, you're basically re-iterating the same point the author made. Some of it was written implicitly while the rest is laid out in a way that induces the mentality you're after, yet, without making any promises based on perceived benefits.

deleted 8y ago

[deleted]

ramanathanrv 8y ago

Regarding `avoid side-effects`, the amount of side-effects that are required for a typical real problem solving code base is quite reasonably measurable. For example, the number of network calls, DB calls, FileSystem read/writes are are measurable. Have you been able to reduce the `side-effects` significantly or have just become more aware of it? When we started using ExpressJS (coming away from Java), there was a tremendous change. As soon as you begin to code in Javascript (say from Java/Ruby/Python world), async hits you. There is no escaping it. And the programmer faces a tax (every time when implementing async/await or generators), his/her awareness about side-effects (deliberately generalizing IO as side-effects) and they tend to be more careful with it.

nightski 8y ago
Avoiding side effects sounds like something someone new to Haskell would say. Haskell in no way avoids side effects. Actually I'd say it embraces them by introducing special semantics just for them! What it does do is encourage you to move side effects to the "edge" of your code base and produce a more clean separation between pure & non-pure code. This is incredibly valuable for testing and overall correctness.
- DonaldPShimoda 8y ago
  Right, and this is what I actually meant. It's not that side-effects disappear, but rather that I try not to litter my code with them. I avoid them in the sense that I don't embrace a side-effect-heavy style of coding, as I did with my imperative code prior to learning Haskell. Perhaps I could have worded that better. Sorry for the confusion.
DonaldPShimoda 8y ago
> Have you been able to reduce the `side-effects` significantly or have just become more aware of it? Yes, sorry, I think I didn't explain myself very well. Prior to learning Haskell and embracing The Way, my code was fairly covered in side-effects. I was a relatively junior programmer at this point (many years of experience because I started young, but few years of real education). Side-effects were just, you know, a thing that happened because they were "the easy way". After learning Haskell, I became much more conscious of side-effects. I realized that a lot of things I used to do could be done without side-effects, mostly by writing better functions and thinking more deliberately about how to eschew the side-effects. That said, it's not like they're gone. It's just that I'm much more careful about them. I "avoid" them in that I do my best not to include them, but if there's a genuine use for them then that's fine. However, I have taken to naming my functions better to reflect their side-effecting nature, and I try to move the side-effecting functions to places that make more logical sense (instead of just wherever).

Woberto 8y ago

> While I have not achieved any sort of nirvana, I do believe that learning Haskell has "enlightened" me insofar as I now look at programming in a fundamentally different way Can I ask whether Haskell in particular led to this enlightenment, or if functional programming is the underlying concept responsible? I've been considering learning Julia for fun and am wondering if it would impart some of the same benefits.

DonaldPShimoda 8y ago
I think functional programming in general is part of it, for sure. That said, my first success with functional programming was actually with Racket. Racket is great for learning (in my opinion), but the "lessons" Racket had to offer weren't really solidified for me until I moved to Haskell. At that point, things really started to click. That could be due to any number of things, though. However, certain concepts (e.g., laziness, typeclasses) are more Haskell-specific (or at least are not common among all functional languages).