Comment by hardwaresofton | Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

Parent Full thread

I've always thought that Elm was like Purescript in the way that it was just another way to bring the good parts of Haskell (a good type system) into JS.

I didn't consider elm's architecture as the main value proposition -- if you squint it looks just like every other data management model for component-based approaches these days -- flux, redux, etc all work in a similar way, +/- immutability.

Hopefully people aren't out there thinking that Elm has done something to magically make it much harder to write runtime errors -- they added a powerful ergonomic-where-possible type system.

If developers out there are still thinking types are "bad for JS" or that using types in code is weird/unnecessary, they might be suffering from Blub[0], and need to go out and see what other languages are doing maybe widen their perspectives. Not every language with a good type system looks like Java/Dart/Typescript/etc (some people can even argue that Java doesn't have a good type system) and I often meet engineers who think adding/checking types basically means making javascript into java.

[0]: http://wiki.c2.com/?BlubParadox

Flux/Redux were inspired by The Elm Architecture. I don't know if there was something similar before Elm popularised this style of building user interfaces.

Concur was first written in Haskell, so it's got the Functional Programming part down :) The other interesting part was TEA, which is hard to simplify further, but I think Concur's model manages to do that while simultaneously being more powerful.

Edit: I don't know what gave you the impression that I don't like types. I love types! I wish JS had more of them. I write Haskell/Purescript (and Javascript) in my day job.

> Flux/Redux were inspired by The Elm Architecture. I don't know if there was something similar before Elm popularised this style of building user interfaces.

Didn't know that, weird how it's come full circle in a way, I don't think people would consider Elm as approachable as they do now if React, Flux and resultingly redux hadn't gotten so popular. There was also a bit of a hype train behind FRP for a while but that seems to have petered out a bit.

To be fair I'm not an Elm expert but try to keep up with it, I have yet to write something big in it, but I absolutely believe the hype because the hype isn't hype, those of us that are writing or at least peeked at the Haskell/ML world have been living in this world up until now.

> Edit: I don't know what gave you the impression that I don't like types. I love types! I wish JS had more of them. I write Haskell/Purescript (and Javascript) in my day job.

Sorry I didn't mean to imply that you don't, I will go back and edit my comment -- I meant I still run into that sentiment, most recently at a meetup last month. It's not like I don't understand it, you can move faster without type checking but a lot of times that just means letting code with silly bugs through that you're going to find @ runtime.

> You can move faster without type checking but a lot of times that just means letting code with silly bugs through that you're going to find @ runtime.

Oh yeah absolutely. And also, FP and immutability makes everything much easier to understand. Getting new devs making changes to 50k lines of JS is much much much worse than with a Haskell/Purescript/Elm project of similar complexity.

Elm isn't a general purpose programming language. You can only write web-apps with it you can only use TEA (the elm architecture). In that way, the TEA really is it's main value proposition.

there are some niche apps like games that use Elm without TEA afaik

You can do more than that using ports, but it doesn't sit very naturally.

Elm is quite different from purescript or Haskell... It shares syntax and the purity semantics but its type system is much less expressive (no type classes); no do notation; no monads...

Reply on news.ycombinator.com