Pedagogical Downsides of Haskell

Post by sacado2 » Fri, Apr 14, 2023, 1:47 PM UTC

yakshaving_jgt wrote: post #55

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.

Post by hgsgm » Fri, Apr 14, 2023, 4:08 PM UTC

consilient wrote: post #90

Hirrolot wrote: post #43

Earlier quoted context omitted.

I find the terminology that Haskell uses quite misleading for software engineering. It borrows concepts from category theory with quaint names such as a "monad", "endofunctor", "catamorphism", etc. The problem is that, instead of a "monad", we can say "brrrdogcogfog" and nothing will change -- the name is absolutely irrelevant to the problem being solved. Given that a monad is an interface for sequential computation,…

> Given that a monad is an interface for sequential computation, a much better name would be something like "Seq", "SeqComp", or something like that. Just because you can look at something as describing a computation doesn't mean you always should. For example: data BinaryTree x = | Leaf x | Node (BinaryTree x) (BinaryTree x) instance Monad BinaryTree where return :: a -> BinaryTree a return x = Leaf x bind :: (a ->…

Post by hgsgm » Fri, Apr 14, 2023, 4:14 PM UTC

keithalewis wrote: post #93

Hirrolot wrote: post #43

Earlier quoted context omitted.

I find the terminology that Haskell uses quite misleading for software engineering. It borrows concepts from category theory with quaint names such as a "monad", "endofunctor", "catamorphism", etc. The problem is that, instead of a "monad", we can say "brrrdogcogfog" and nothing will change -- the name is absolutely irrelevant to the problem being solved. Given that a monad is an interface for sequential computation,…

Composition/SeqComp comes for free. A monad is how to wrap something up,apply a function to the wrapped up thing, and how to unwrap it.

Post by hgsgm » Fri, Apr 14, 2023, 4:21 PM UTC

iamnotsure wrote: post #26

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.

Post by nequo » Fri, Apr 14, 2023, 8:41 PM UTC

pharmakom wrote: post #95

nequo wrote: post #82

Earlier quoted context omitted.

That sounds almost as vague to me as “object” does in OOP. Don’t non-monadic functions also consist of expressions that describe computations?

Everything is vague. Hell, Haskell functions are not really functions in the mathematical sense.