Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pedagogical Downsides of Haskell

ciobaca.substack.com

Post reply on HN
Print view View original

21–30 of 118 posts

Re: Pedagogical Downsides of Haskell

#21

Post by Laaas »

javajosh wrote: post #11

The pedagogical downside of Haskell is that it ignores the physical reality of the machine. Physically, a computer is imperative, has mutating state, and is filled with all kinds of possible race conditions. Even after you apply the operating system, allowing processes to live together (and giving you space to define new ones), very few constraints are placed on your program and process space. Instead of building on…

You can apply your argument to almost _any_ language. Haskell's semantics not matching the underlying machine has little to do with any of the issues in the article.

To the contrary, the simplicity of Haskell allows you to understand through simply rewriting expressions according to the rules/definitions you define. You don't have to worry about memory/effects/so many other things that have nothing to do with the _logic_ of what you are trying to do.

Of course, programs in reality often need to be changed to improve performance, but this isn't relevant when teaching.

Re: Pedagogical Downsides of Haskell

#23

Post by ipnon »

javajosh wrote: post #11

The pedagogical downside of Haskell is that it ignores the physical reality of the machine. Physically, a computer is imperative, has mutating state, and is filled with all kinds of possible race conditions. Even after you apply the operating system, allowing processes to live together (and giving you space to define new ones), very few constraints are placed on your program and process space. Instead of building on…

One of the benefits of the Curry-Howard isomorphism is that people like myself who never make anything useful can use computers too.

Re: Pedagogical Downsides of Haskell

#24

Post by yamtaddle »

I find its syntax & idiomatic style incredibly difficult to follow, in a way nearly no other languages have been for me, including some functional languages (OCaml doesn't seem nearly as bad to me, for instance).

It's sometimes implied that those who trip over Haskell just aren't big-brained enough to understand various important concepts related to it, but I've found they're usually very easy to grasp, provided the explanation's not using Haskell examples. If all programming were Haskell, I probably never would have become a programmer in the first place. Would have taken me too long to figure any of it out, probably would have concluded I wasn't smart enough to be a programmer.

I do wonder if there are some shared experiences or common patterns to who tends to love Haskell, and those who don't. I also feel nigh-dyslexic trying to read math formulas. Human language and broadly C-family programming languages, on the other hand, seemed easy and natural to me, almost effortless to pick up. Wonder if there's a "mathy"-person versus "languagey"-person divide on finding Haskell legible.

I'm not sure it's the whole thing, but I think I've also figured out that I find algorithm-type reasoning far easier to follow and work with than equations or proofs. Like, the only way I can begin to get traction with an unfamiliar equation is to break down what each term and operation "does" to something "moving through" it—it's tedious as hell. Might be something there.

Re: Pedagogical Downsides of Haskell

#25

Post by AnimalMuppet »

kqr wrote: post #17
javajosh wrote: post #11

The pedagogical downside of Haskell is that it ignores the physical reality of the machine. Physically, a computer is imperative, has mutating state, and is filled with all kinds of possible race conditions. Even after you apply the operating system, allowing processes to live together (and giving you space to define new ones), very few constraints are placed on your program and process space. Instead of building on…

I find so many things about this line of reasoning wrong that I don't know where to start. So let's just pick one thing: Haskell does not ignore the physical reality of the machine. It's one of few languages that explicitly recognise it. There are more facilities in Haskell to deal with this reality than in almost any other language you can think of.

Do you think Haskell recognizes the physical reality of the machine more than C does? If so, how specifically does it do so?

Re: Pedagogical Downsides of Haskell

#26

Post by iamnotsure »

javajosh wrote: post #11

The pedagogical downside of Haskell is that it ignores the physical reality of the machine. Physically, a computer is imperative, has mutating state, and is filled with all kinds of possible race conditions. Even after you apply the operating system, allowing processes to live together (and giving you space to define new ones), very few constraints are placed on your program and process space. Instead of building on…

One of the more surprising aspects of GHC Haskell is that it is possible to write a very high level code with performance matching or exceeding code written in a low level language, thus honoring the machine. Stream fusion for an example. Not sure if there is any other language with higher abstraction/performance ratio.

Re: Pedagogical Downsides of Haskell

#28

Post by bluetomcat »

kachnuv_ocasek wrote: post #18
javajosh wrote: post #11

The pedagogical downside of Haskell is that it ignores the physical reality of the machine. Physically, a computer is imperative, has mutating state, and is filled with all kinds of possible race conditions. Even after you apply the operating system, allowing processes to live together (and giving you space to define new ones), very few constraints are placed on your program and process space. Instead of building on…

I'm sorry to break it to you but every single programming language in existence ignores the physical reality of the machine. That's the point of abstractions such as programming languages.

There are abstractions which build on the inherently stateful nature of computers with their instruction pointers, registers, memory and peripheral devices, and there are abstractions which coerce you into framing any computational problem like a mathematical formalism.

Re: Pedagogical Downsides of Haskell

#29

Post by [deleted] »

burnished wrote: post #19
iamnotsure wrote: post #12

Had good experience at https://exercism.org/tracks/haskell I don't think this article is helpful for beginners.

I think this article's audience is teachers of beginners, not beginners themselves. At least the author is writing about their experience as a teacher. Don't know why you thought it would be an article for beginners, but good on you for linking a resource regardless.

[deleted]

Re: Pedagogical Downsides of Haskell

#30

Post by danidiaz »

mrkeen wrote: post #2

Brilliant write up. > There is also a school of thought that you should start Haskell by teaching the IO monad first, but I am not convinced: in my experience, if someone gets exposed to IO early on, they will contaminate all their functions with IO. They will essentially end up writing Java in Haskell. I don't think this is such a bad starting place. Crawling before walking. Purifying an (unnecessarily-) IO function…

> Purifying an (unnecessarily-) IO function into an ordinary function is a good exercise.

Agree! And I would add that you can "purify" a monadic function without having to rewrite it in non-monadic style. You can make it polymorphic over all monads and relegate the "impurity" to monadic functions that you pass as arguments/dependencies. A trivial example:

  twice :: IO ()
  twice = do
      putStrLn "foo"
      putStrLn "foo"
  
  twice' :: forall m. m () -> m ()
  twice' action = do 
      action
      action
This is not that different to having a Spring bean that doesn't perform any effect directly—say, a direct invocation to "Instant.now()"—but instead receives a "Clock" object through dependency injection.

Haskell lets you express the idea of "program logic that only has effects through its dependencies" by being polymorphic over all monads.

Post reply on HN