Hacker News Reader

Comment by thecity2 | Hacker News Reader

Why not just use the "easy" parts of Haskell as a teaching language for functional programming?

No monads, applicatives, etc. No category theory. Just immutability, laziness, pattern matching, and type classes. I feel like that makes as much sense as developing an entirely new language that most likely will only be used by a complete novice. Conversely, one can grow with a language like Haskell for an entire lifetime. Just my two cents.

View on HN

Because we also use Pyret to teach program complexity, and big-O is a whole 'nother can of worms in Haskell (the cost model is totally non-traditional). Because we use Pyret to introduce students to state, and even basic equality is a whole 'nother can of worms in Haskell. Because we teach basic algorithms in Pyret, and even something like DFS in Haskell is complicated (because of the preceding issues).

> even basic equality is a whole 'nother can of worms in Haskell

How so?

I'm afraid I don't have time here to explain Haskell. Think about how graph reduction and reference equality would interact.

codygman and I both understand Haskell well, but neither of us (apparently) can work out what you mean. There's no "can of worms" around equality in Haskell as far as I can see.

See https://news.ycombinator.com/item?id=13198342

I know a fair amount of Haskell. For instance I know Haskell doesn't use reference equality.

And the lack of it makes it hard to test for things like node equality when doing graph algorithms. There's an extra layer of encoding you need to be able to simulate reference equality. And even if you addressed the equality issue, I brought up two other issues that you didn't address.

Reply on news.ycombinator.com