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

51–60 of 118 posts

Re: Pedagogical Downsides of Haskell

#51

Post by paddw »

yamtaddle wrote: post #24

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…

I suspect you are right that there's a type of person Haskell feels very intuitive to. I think if your mind works that way you might have a hard time appreciating the degree of confusion "regular" programmers face when trying to decipher the mess of symbolic soup.

Re: Pedagogical Downsides of Haskell

#52

Post by AnimalMuppet »

kqr wrote: post #42
AnimalMuppet wrote: post #25

Earlier quoted context omitted.

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

Technically, within the language, yes. C itself simply delegates a lot of logic to the "physical machine"[1] by leaving it unspecified or implementation-defined. In contrast, Haskell actually tries to model these differences within the type system and standard libraries, with IORefs, STMs, and whathaveyou. (In fact, I just checked the IORef documentation and it actually references the x86/64 architecture manual to ex…

I see. The language spec explicitly talks about the machine. That's not nothing.

In practice, though, when I have some piece of memory-mapped hardware attached, and I want to talk to it, in C I can say:

  *(uint32_t*)0xF00BA4 = 0x0102ABCD;
or whatever I need to flip the bits. C lets me actually control the whole machine. Whereas Haskell... I don't know, but I suspect it lets me actually use the physical machine a lot less.

Re: Pedagogical Downsides of Haskell

#53

Post by yakshaving_jgt »

paddw wrote: post #51
yamtaddle wrote: post #24

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…

I suspect you are right that there's a type of person Haskell feels very intuitive to. I think if your mind works that way you might have a hard time appreciating the degree of confusion "regular" programmers face when trying to decipher the mess of symbolic soup.

There is no reason for Haskell to be a "mess of symbolic soup".

You can make Haskell about as human-readable as Ruby if you choose to.

Re: Pedagogical Downsides of Haskell

#54

Post by tome »

AnimalMuppet wrote: post #52
kqr wrote: post #42

Earlier quoted context omitted.

Technically, within the language, yes. C itself simply delegates a lot of logic to the "physical machine"[1] by leaving it unspecified or implementation-defined. In contrast, Haskell actually tries to model these differences within the type system and standard libraries, with IORefs, STMs, and whathaveyou. (In fact, I just checked the IORef documentation and it actually references the x86/64 architecture manual to ex…

I see. The language spec explicitly talks about the machine. That's not nothing. In practice, though, when I have some piece of memory-mapped hardware attached, and I want to talk to it, in C I can say: *(uint32_t*)0xF00BA4 = 0x0102ABCD; or whatever I need to flip the bits. C lets me actually control the whole machine. Whereas Haskell... I don't know, but I suspect it lets me actually use the physical machine a lot l…

> C lets me actually control the whole machine

Really? Can you run micro-ops?

Re: Pedagogical Downsides of Haskell

#55

Post by yakshaving_jgt »

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…

> Haskell's power users famously don't actually make anything with it

This is a lie that you're perpetuating.

Myself and many of my friends, colleagues, and associates make a living writing Haskell.

Re: Pedagogical Downsides of Haskell

#56

Post by yakshaving_jgt »

AnimalMuppet wrote: post #52
kqr wrote: post #42

Earlier quoted context omitted.

Technically, within the language, yes. C itself simply delegates a lot of logic to the "physical machine"[1] by leaving it unspecified or implementation-defined. In contrast, Haskell actually tries to model these differences within the type system and standard libraries, with IORefs, STMs, and whathaveyou. (In fact, I just checked the IORef documentation and it actually references the x86/64 architecture manual to ex…

I see. The language spec explicitly talks about the machine. That's not nothing. In practice, though, when I have some piece of memory-mapped hardware attached, and I want to talk to it, in C I can say: *(uint32_t*)0xF00BA4 = 0x0102ABCD; or whatever I need to flip the bits. C lets me actually control the whole machine. Whereas Haskell... I don't know, but I suspect it lets me actually use the physical machine a lot l…

You know you can write C inside Haskell, right?

Like, there's literally nothing stopping you. You can use FFI, and you can also write C inline.

You can have the best of both, if you want.

Re: Pedagogical Downsides of Haskell

#57

Post by jokoon »

yamtaddle wrote: post #24

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…

I use generators, list comprehension and a lot of lambda stuff with python.

It's a bit fun because it's very short to write, it's concise and it helps a lot working only with dict and tuples etc.

Not sure if it's faster, but it's always a bit longer to write and think about, and I'm not sure it's easier to read and understand.

Sometimes it feels a bit like code golfing, because you can do a lot of things with very few lines.

It's immensely better to remove 99% of side effects, the code is shorter and more compartmentalized, so it's just easier to deal with.

Although I'm doing this alone, and I'm not confident that I could enforce this sort of software design in a team.

Re: Pedagogical Downsides of Haskell

#58

Post by tome »

gpderetta wrote: post #27
tome wrote: post #10

I find the go pattern absurd. Which of these is easier to read: foldr k z = go where go [] = z go (y:ys) = y `k` go ys or foldr k z = foldr_k_z where foldr_k_z [] = z foldr_k_z (y:ys) = y `k` foldr_k_z ys

The first.

Do you have insight you can share into why you find it that way?

Re: Pedagogical Downsides of Haskell

#59

Post by tome »

ghusbands wrote: post #33
tome wrote: post #10

I find the go pattern absurd. Which of these is easier to read: foldr k z = go where go [] = z go (y:ys) = y `k` go ys or foldr k z = foldr_k_z where foldr_k_z [] = z foldr_k_z (y:ys) = y `k` foldr_k_z ys

I think I prefer this: foldr _ z [] = z foldr k z (x:xs) = k x $ foldr k z xs

I suspect we all prefer that, but the point of abstracting out a closure that captures k and z is for performance.

Re: Pedagogical Downsides of Haskell

#60

Post by markusde »

kqr wrote: post #44
a_wild_dandan wrote: post #32

Earlier quoted context omitted.

Also true. Their point is that Haskell's system ignorance goes much deeper than its peers.

I mean yes, it's a higher level language. Python's system ignorance goes deeper than, say, Ada's, which in turn goes deeper than C++'s, which goes deeper than C's, which goes deeper than many of its predecessors, which go higher than x86, which goes deeper than PDP-11, which goes deeper than logic gates, which go deeper than transistors. But what's the point? Which languages do we reject because they are sufficiently…

(jokingly) yes, in Haskell: https://clash-lang.org
Post reply on HN