Hacker News Reader

Comment by aszen | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com