Pedagogical Downsides of Haskell • Hacker News Board

Re: Pedagogical Downsides of Haskell

#31

Post by agentultra » Thu, Apr 13, 2023, 5:10 PM UTC

I wonder if there could be a (or already is) a "teaching" Prelude designed for this purpose.

One of the reasons the standard Prelude includes partial functions and specialize versions of `map` and `filter` is to support the pedagogical use-case (as far as I understand the situation). Most production applications will use a custom Prelude of some kind in order to prevent programmers from using foot-guns like `head` or make things more general in the case of `map` and `filter`.

Turns out using linked-lists for everything isn't the best idea but a lot of Haskell applications will use them because it's in Prelude.

Bit of a balancing act supporting both use cases.

Re: Pedagogical Downsides of Haskell

#32

Post by a_wild_dandan » Thu, Apr 13, 2023, 5:12 PM UTC

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.

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

Re: Pedagogical Downsides of Haskell

#33

Post by ghusbands » Thu, Apr 13, 2023, 5:12 PM UTC

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

Re: Pedagogical Downsides of Haskell

#34

Post by tikhonj » Thu, Apr 13, 2023, 5:20 PM UTC

Code World[1] is a great project that addresses a number of the problems from the article, with an eye towards using Haskell to teach children basic math and programming simultaneously. Code World directly addresses a number of the obstacles outlined in this article:

1. Using an online editor with a rich built-in library removes any toolchain problems.

2. A custom standard library simplifies pedagogically unnecessary details like Foldable

3. The custom standard library also avoids currying (f(a, b) for functions rather than f a b)

4. Custom error messages improve the feedback students get from the compiler

I would highly recommend Code World to anybody looking to teach programming with Haskell. If you want to teach Haskell in a way that fits the existing ecosystem, it's also possible to run Code World without the custom standard library[2].

[1]: https://code.world/#

[2]: https://code.world/haskell#

Re: Pedagogical Downsides of Haskell

#35

Post by markusde » Thu, Apr 13, 2023, 5:21 PM UTC

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 don't think that this is right. A programming language is useful to programmers if it's oriented around the structure of the _problem_ and not just the structure of the _physical machine_. For some tasks these coincide (especially if you care about performance) but I frequently find myself in situations where functional code is simple and the machine is irrelevant.

Re: Pedagogical Downsides of Haskell

#36

Post by a_wild_dandan » Thu, Apr 13, 2023, 5:23 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.

JavaScript comes to mind. Its benchmarks are a wonderful testament to the immense engineering resources poured into V8.

Re: Pedagogical Downsides of Haskell

#37

Post by tikhonj » Thu, Apr 13, 2023, 5:25 PM UTC

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…

In a bunch of key ways Haskell is closer to the machine than modern languages like JavaScript: it doesn't depend on a complicated JIT system at runtime, it lets you explicitly control details like boxing and unboxing, it exposes various low-level C and machine types (fixed-size ints/etc), it has primops for SIMD...

You can write relatively low-level Haskell a lot more easily than you can write low-level JavaScript. You just don't have to.

Re: Pedagogical Downsides of Haskell

#38

Post by alpaca128 » Thu, Apr 13, 2023, 5:27 PM UTC

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'm in the exact same boat. Haskell code feels more like abstract maths and I feel more at home when I can just easily track the data flow. The language and community uses relatively abstract terminology due to its roots and it's just a bit too cryptic to me.

Though I'm glad newer languages are starting to adopt more features from the functional territory for the situations where it just makes more sense.

Re: Pedagogical Downsides of Haskell

#39

Post by jaggederest » Thu, Apr 13, 2023, 5:27 PM UTC

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.

These days even binary instructions ignore the reality of the physical hardware, as far as I know (I make a javascript lol). The output of e.g. assembler is an instruction set for a virtual machine that doesn't exist, that the CPU translates into actual execution. At least on the intel superscalar side, ARM may be a simpler setup.

Re: Pedagogical Downsides of Haskell

#40

Post by msla » Thu, Apr 13, 2023, 5:29 PM UTC

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…

Abstracting over the physical reality of the machine is part of the point. The physical reality of the machine isn't the focus in programming language design or theory, and it certainly isn't the focus of making maintainable code with properties like referential transparency, type correctness, and parallelizability. Abstractions, in short, allow us to make anything worth making.

The machine has no types. The machine has no variables. The machine has no functions, procedures, scoping, or information hiding. The machine has no assembly language. The machine has no machine code. The machine, ignoring the physical reality and focusing on an abstraction which could still potentially be in the realm of software and not physics, has a certain number of bits in flip-flops perturbed by other bits coming in on pins.

> Haskell's power users famously don't actually make anything with it (modulo pandoc and jekyll)

Self-contradiction is self-negation. You've destroyed your own argument, such as it was.