41–50 of 199 posts
In a comment below the main post they say that the app they wrote is approximately 45,000 lines of code over 170 Elm files. That's one of the largest (and apparently most useful) Elm apps in the wild that I've heard of, and the fact that it exists and they had an overall good experience with it inspires me even more to try to learn and use Elm.
Shameless plug - I'm trying to improve upon Elm and React's programming model with my Concur UI framework. Its programming model is a bit unusual, it uses Monads to sequence widgets in time, but it is designed to be extremely simple to use, and you don't need to actually understand Monads to use it. An advantage is that it's not artificially restricted like Elm, and allows you to use advanced Functional Programming t…
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.
Shameless plug - I'm trying to improve upon Elm and React's programming model with my Concur UI framework. Its programming model is a bit unusual, it uses Monads to sequence widgets in time, but it is designed to be extremely simple to use, and you don't need to actually understand Monads to use it. An advantage is that it's not artificially restricted like Elm, and allows you to use advanced Functional Programming t…
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'…
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.
What I find most interesting about Elm as a designer who also "codes", is that because of its bottom up frontend philosophy (types first instead of components first) it somehow assumes that the UI designer and coder is the same person, that there is no clear designer to developer handoff where you hand over a thought out design to implement. It's more the other way round, where you'd hand over what you've come up wit…
> Ports == lots of boilerplate and “loose” typing This is a common criticism of Elm, and I've never understood it. The criticism seems to be that "Elm is bad because I still need some JavaScript, and JavaScript is dangerous." Like, what's the alternative? More JavaScript?
Completely OT but I'm curious about his use of space before exclamation and question marks. Is it a cultural thing?
Earlier quoted context omitted.
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'…
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 k…
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.
Completely OT but I'm curious about his use of space before exclamation and question marks. Is it a cultural thing?
> Ports == lots of boilerplate and “loose” typing This is a common criticism of Elm, and I've never understood it. The criticism seems to be that "Elm is bad because I still need some JavaScript, and JavaScript is dangerous." Like, what's the alternative? More JavaScript?
Coming in from the other (Functional Programming) side, Elm can be restrictive (no typeclasses, do notation etc.). But it does walk a fine balance, and I love that there's a popular-ish language that is exploring the ease-of-use design space.
Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
Another things is that in Elm the state of the whole application is very visible. Typically just by looking at data structures and message types one gets how things work. The code just fills details.