Live data from Hacker News

What I Wish I Knew When Learning Haskell

dev.stephendiehl.com

81–90 of 149 posts

Re: What I Wish I Knew When Learning Haskell

#81
post #66

In the section on "Boolean Blindness", I find the example a bit confusing. I would expect `isNotJust (Just foo)` to equal `False`, not `True`, and vice versa `isNotJust Nothing` to equal `True`. The point has some validity (that you should try to encode data into the types if you can), but the example makes no sense in my opinion. http://dev.stephendiehl.com/hask/#boolean-blindness

I thought that was the point of the section- that you may be able to tell something is wrong with the example, but the compiler can't. Thus by programming in that fashion you're not taking advantage of the power of the compiler.

The improved way below where the Just a is unwrapped with a case allows the compiler to see whether or not x is valid.

Re: What I Wish I Knew When Learning Haskell

#82
post #46

Really just learn it. It's a pity I don't use Haskell at work and yet learning Haskell was the single most bang for buck exercise I have ever done. "Parallel and Concurrent Programming in Haskell" is the best resource I have ever read on parallel and concurrent programming concepts. Every programmer should learn this language even if they never plan/get to use it.

I learned Haskell and used it (and heavily functional Scala) professionally for about 6 years.

I feel learning Haskell was worthless. It did not teach me anything about decomposing problems into function units, compositional sequences, pure functions / immutable data structures, lazy evaluation or asynchronous programming that I have found useful in modeling solutions to software problems.

Guarantees from the compiler and use of the type system itself for type designs like phantom types and type class patterns did not help reduce behavioral bugs and the slower development cycle of waiting for compilation (instead of just using occasional unit test runs to check simple safety conditions in lighter weight dynamically typed languages) was a very significant cost.

It was no easier, and often much harder, to enable extensibility into systems designed in Haskell because the constraints of the extensible needs of the system were only ever learned from changing business circumstances after the fact and could not be reflected in anticipated up-front design, which is perhaps the number one need of business software yet is an area where functional languages are uniquely poorly suited even with veteran, highly experienced engineers on the team like we had.

In the end, following simple patterns of composition and function purity while avoiding cookie-cutter design patterns and avoiding use of object / class constructs is all you need. This is easy to achieve in many imperative languages while leaving much greater flexibility to choose mutation, treat safety as a resource to be traded off instead of enforced in all cases, etc.

“Module oriented programming” in Python or C, letting lightweight unit tests replace heavy reliance on type system patterns, just using simple structs / namedtuples / dataclasses that posses zero function logic, and creating imperative APIs around functional-inspired core implementations is strictly better.

Really, strong adherence to statically typed functional languages with lazy evaluation is a religious trap. Learning that it’s not all it’s cracked up to be early in your career is critical for success.

Re: What I Wish I Knew When Learning Haskell

#83
post #81
post #66

In the section on "Boolean Blindness", I find the example a bit confusing. I would expect `isNotJust (Just foo)` to equal `False`, not `True`, and vice versa `isNotJust Nothing` to equal `True`. The point has some validity (that you should try to encode data into the types if you can), but the example makes no sense in my opinion. http://dev.stephendiehl.com/hask/#boolean-blindness

I thought that was the point of the section- that you may be able to tell something is wrong with the example, but the compiler can't. Thus by programming in that fashion you're not taking advantage of the power of the compiler. The improved way below where the Just a is unwrapped with a case allows the compiler to see whether or not x is valid.

Ah ok, that wasn't really clear to me, but that makes way more sense. Clearly I hadn't had any coffee when I read it earlier.

Re: What I Wish I Knew When Learning Haskell

#84
post #62

Earlier quoted context omitted.

What's wrong with it?

Performance. Internal representation. You are not actually modifying things in place. Those are the equivalent of linked lists not arrays. That quicksort is not quick at all because the append operation in Haskell is linear. You can't use those lists to implement quicksort.

Haskell is lazy. a ++ b === (head a) : ((tail a) ++ b) (plus the base case)

It is only linear when you force it to evaluate, which ideally happens only once (amortized) in your program when the result is consumed. As long as you are careful, you don't get the bad quadratic performance that you'd get from something like eagerly appending a character to a string in a loop in Java. There are either gotchas, though, including relying on the compiler to do things in constant space that naively look linear, and also knowing when the compiler won't help you and you have to structure your computation manually.

Re: What I Wish I Knew When Learning Haskell

#85
post #67

Earlier quoted context omitted.

If I am not mistaken, Dijkstra advocated for Haskell to be used as a language of instruction at universities. There is an essay somewhere online about it. What I could find is this: [1]. Edit: Indeed, the PDF that is linked to in [1] looks like a scan of the original. [2] [1] https://chrisdone.com/posts/dijkstra-haskell-java/ [2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...

Note that Dijkstra recommendes Haskell over Java because Haskell is arcane and mathematical, which is good for learning computer science, not because it's good for writing software.

Your paraphrasing of "novel" as "arcane" is in bad faith. It is also self evident that djikstra believes that learning computer science is good for writing software.

Re: What I Wish I Knew When Learning Haskell

#86
post #83
post #81

Earlier quoted context omitted.

I thought that was the point of the section- that you may be able to tell something is wrong with the example, but the compiler can't. Thus by programming in that fashion you're not taking advantage of the power of the compiler. The improved way below where the Just a is unwrapped with a case allows the compiler to see whether or not x is valid.

Ah ok, that wasn't really clear to me, but that makes way more sense. Clearly I hadn't had any coffee when I read it earlier.

That's what these parts were going for:

> Is there anything wrong with the definitions and below

> and why is this not caught in the type system?

And

> ???

on the line you flagged as a bug.

Re: What I Wish I Knew When Learning Haskell

#87
post #67
post #46

Really just learn it. It's a pity I don't use Haskell at work and yet learning Haskell was the single most bang for buck exercise I have ever done. "Parallel and Concurrent Programming in Haskell" is the best resource I have ever read on parallel and concurrent programming concepts. Every programmer should learn this language even if they never plan/get to use it.

If I am not mistaken, Dijkstra advocated for Haskell to be used as a language of instruction at universities. There is an essay somewhere online about it. What I could find is this: [1]. Edit: Indeed, the PDF that is linked to in [1] looks like a scan of the original. [2] [1] https://chrisdone.com/posts/dijkstra-haskell-java/ [2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...

> Colleagues from outside the state (still!) often wonder how I can survive in a place like Austin, Texas, automatically assuming that Texas’s solid conservatism guarantees equally solid mediocrity. My usual answer is something like “Don’t worry. The CS Department is quite an enlightened place...

Very Dijkstra to start by insulting the intended audience. Wonder if it had the intended effect?

Re: What I Wish I Knew When Learning Haskell

#89
post #46

Really just learn it. It's a pity I don't use Haskell at work and yet learning Haskell was the single most bang for buck exercise I have ever done. "Parallel and Concurrent Programming in Haskell" is the best resource I have ever read on parallel and concurrent programming concepts. Every programmer should learn this language even if they never plan/get to use it.

I agree with this, learning Haskell was transformative for me. It changed the way I approached problems in every other language. I treat learning it as one of the 2 or 3 things that has most influenced my development skills. But the truth is that I still don't feel comfortable writing anything more than toy apps in Haskell. I'm not really sure how to unit test things when I'm passing complex monad transformers around…

> I treat learning it as one of the 2 or 3 things that has most influenced my development skills.

If you don't mind, what were the other 1 or 2 things?

Re: What I Wish I Knew When Learning Haskell

#90
post #67

Earlier quoted context omitted.

If I am not mistaken, Dijkstra advocated for Haskell to be used as a language of instruction at universities. There is an essay somewhere online about it. What I could find is this: [1]. Edit: Indeed, the PDF that is linked to in [1] looks like a scan of the original. [2] [1] https://chrisdone.com/posts/dijkstra-haskell-java/ [2] http://www.cs.utexas.edu/users/EWD/OtherDocs/To%20the%20Budg...

Note that Dijkstra recommendes Haskell over Java because Haskell is arcane and mathematical, which is good for learning computer science, not because it's good for writing software.

No one would recommend a language “because it’s arcane.”
Post reply on HN