Ask HN: Elm, PureScript, or ReasonML for a FP course? | Hacker News Reader

Ask HN: Elm, PureScript, or ReasonML for a FP course?

7 pointsEugeleo13 comments

Beginning this March, I'll lead a new high-school functional programming course, consisting mostly of writing simple 2D games. I can't decide which of these three languages would be best suited for it. Does anybody have experience with any of them? What did you like? What did you not? What should I use?

The students are a bunch of talented high-schoolers, however they only picked up programming this September. That means good tooling and a friendly compiler are paramount, because they'll often be leaning on both.

I don't have experience with any of the languages, but I write Haskell and Typescript for living, so I should be able pick these up rather quickly. Because I know Haskell so well, I lean towards PureScript, but I don't want to base my decision only on this.

View on HN

I have experience with elm, and since you are teaching students I would suggest you to go with it.

There is no beating it's compiler for error messages, tooling and extensive beginner friendliness.

Elm is how I learned functional programming and to build 2D games there are many libraries to choose from, you can use the simplest one of them created by the elm author himself

Elm playground https://package.elm-lang.org/packages/evancz/elm-playground/...

Speaking of typeclasses not being in elm, I think one can appreciate them better when the things they provide have to be manually written.

Thanks for the response! I edited the question a bit since you've answered (not to look like a typeclass fanboy), but I see what you mean — one can certainly better appreciate something when he doesn't have access to it.

Are there any more differences between Haskell and Elm that I should be wary of? I mean mostly the day-to-day stuff that I could get bitten by, rather that "linear types are not there yet in Elm" or "type families are unavaible".

I think the main difference apart from syntax and lack of higher order functionality is that with elm you have to embrace the language restrictions and not try to fight them.

The lack of advanced features can be frustrating for an experienced haskell dev but it forces the api's to be simpler and more approachable.

So the major thing to be wary of is the change in mindset one has to go through.

By "lack of higher order functionality" you mean the typeclasses, right?

I should have formulated the question in a better way; my students probably won't take another shot at FP for a looong time after this course, so I don't want them to lose too much on the more "fun" parts of FP, because they might just never see them if I don't show them.

So I was wondering what limitations would Elm impose, apart from the typeclasses, compared to Purescript (Haskell).

Limitations like Tuples in elm are restricted to just two elements, because the author feels tuples greater than length of two should be better modelled as a named record.

Nested record updates are also not supported, so u have to write functions to update each record field.

Elm is by design a very opinionated language, which is good for beginners usually since there is only one chosen way to do things but not so for experienced devs.

The fun parts of FP are still present in elm, it's completely pure side effect free, great type checker with awesome error messages, fast performance and great for building interactive web apps with it's TEA architecture.

I'm enjoying the discussion, thanks! Elm really does sound heavily opinionated, but that's often for the better, as you say. How's the tooling, besides the compiler+error messages? I've seen a web-based interactive editor, but I assume that's not _the_ way to write Elm.

The tooling is solid, the lsp server provides auto completions and edit by edit syntax checking in major editors like vim, Emacs and vscode, there is a good formatting tool in elm-format, a built in repl which is basic but works fast. A test runner is also there, with support for fuzzing. Not to mention a time travel debugger which is a highlight. Things that are missing or not good are proper logging, step by step line debugger, profiling and performance tracking.

Sounds great. How does the time travel debugger work if not by stepping through the lines? Jumping forward and backward between function calls?

It's actually time travelling through the various UI states ur web application will go through.

It's really awesome for debugging complex ui interactions but not for actual line by line code debugging

There were some similar questions on r/functionalprogramming subreddit. Maybe there's something useful there? Search for "teach" or "class" I think, e.g.

- "How would you teach a group of 9th graders functional programming?" https://old.reddit.com/r/functionalprogramming/comments/avcr...

- "I want to teach programming via functional paradigm to someone with no background" https://old.reddit.com/r/functionalprogramming/comments/egzz...

Thanks, I'll check them out!

Is the aim to teach functional programming as a paradigm or specifically "functional programming languages"? For High School, I would assume the first may be more important than the latter, and you may have good benefit from teaching FP as a paradigm in a language they are taught elsewhere or might have other reasons to use. You can spend less time teaching syntax and more time focused on patterns/practices.

Which is to say, maybe start out in Typescript itself? There are a lot of great more functional paradigm-focused libraries out there in "Fantasy Land" [1] and "Static Land" [2].

A benefit to starting in Typescript as well would be that you could move to Elm or PureScript if there is time/interest and reuse many of the same libraries and/or even some of the earlier TS code/projects.

It obviously seems like a trade-off that using a language that isn't "strict" or "native" to the functional paradigm, students might be tempted to avoid learning the functional paradigm and fall back to old habits. But on the other hand, that can still be a useful escape hatch to avoid frustration, especially with High School students who might have enough other stuff on their plates that some leniency might be handy/warranted (and for High Schoolers they shouldn't have that many "old" habits to fall back on anyway). It could be good teaching praxis to start with "Why did you fall back to doing this imperatively/OO/what-have-you? Did you try X? What if you explore Y that we discussed in class?" You and the students might learn a lot from dialogs like that.

Just some thoughts. There's probably no "perfect" language, but sometimes the best language is the one people already know because that gets a lot of the basics out of the way and out of the focus.

[1] https://github.com/fantasyland/fantasy-land

[2] https://github.com/fantasyland/static-land

I’m a big fan of ReasonML. It’s the best combination of practicality and conceptual ideology. Yes, it’s functional, and encourages you to write pure logic that operates on values. But it also allows you to mutate state when you want. The type inference is also incredible, though similar to Elm and PureScript.

Reply on news.ycombinator.com