51–60 of 199 posts
Elm is fascinating since it shows that with the right architecture functional programming for GUI is possible without hatches like monads or hiding state in closures or green thread stacks. 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.
> 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?
[@bs.val] external pi : float = "Math.PI";
let tau = pi *. 2.0;
[@bs.val] external alert : string => unit = "alert";
alert("hello");
I don't understand why this is noteworthy. I think maybe this is when you decide 'maybe our language has failed'. Or at least admit it's a toy language that hasn't been properly engineered to be effectively used commercially. When it's a 'worth mentioning' when a single app has been written in it by some dying company. I mean, imagine if we had a headline on the frontpage of HN for every app written in C or C++ or Ja…
https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...
"Which Team's Next?
We believe in iterating on/alongside product teams in order to create the best infra. The product teams' and open source folks' feedback has changed our strategy a few times, for the better. As of today, Reason and BuckleScript are also deployed on a WhatsApp internal tool, Instagram Web (small scale), plus some critical Ads internal tools. We'll be working closely with these teams over the next year."
Elm is fascinating since it shows that with the right architecture functional programming for GUI is possible without hatches like monads or hiding state in closures or green thread stacks. 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.
// Stateful
state = {buttonClicked: false}
render() {
if(!state.buttonClicked) {
return button({text: "Click Me", onClick: {state.buttonClicked=true}})
} else {
return text("Thanks!")
}
}
// Implicit state
render() {
yield button({text: "Click Me", onClick})
yield text("Thanks!")
}This inspired me to look up the Elm docs, and came across this gem: view model = div [] [ button [ onClick Decrement ] [ text "-" ] , div [] [ text (String.fromInt model) ] , button [ onClick Increment ] [ text "+" ] ] The html elements themselves are Elm functions. Code looks like data. Nice. Now considering Elm to be potentially useful tool to know.
No square or other brackets, just indentation defines the structure and it's beautiful. The only oddity is that 'div' has to be written as 'tdiv'. Here is an example from the Nim forum's frontend code: https://github.com/nim-lang/nimforum/blob/master/src/fronten...
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.
I thought Elm was known for having vast quantities of boilerplate? I wouldn't put much stock into number of lines of code.
Earlier quoted context omitted.
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…
> 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 tha…
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.
> 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?
Have you seen ReasonML? [@bs.val] external pi : float = "Math.PI"; let tau = pi *. 2.0; [@bs.val] external alert : string => unit = "alert"; alert("hello"); Elm was trying to make it very hard to use JS in Elm which is always a bad idea when you are a transpiled language. Clojure is so popular because you have access to most of Java and the libraries written in Java. ReasonML makes super easy to use JS (or other lang…
That is why I use Elm, and not some other compile-to-JS language that allows me more freedom.
I don't want freedom. I want constraints.
Freedom is the rope with which I can hang myself.
Constraints keep my bug tracker silent.
Earlier quoted context omitted.
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.
Yeah, it's pretty restrictive for FP people, but I think that's fine. I think it's easier for FP people to deal with that amount of restriction, than it is for the average JS developer to quickly understand how to wield as much power as e.g. PureScript gives you. Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
I have heard this sentiment earlier, and I believe that there is a better middle ground. Use a less restrictive platform and simply don't use features you deem too complicated. That's a better approach because as the developer becomes more familiar with typed FP, they would be able to use better and better tools at their disposal. i.e. the toolset will grow with their skill.
> Also a little surprised you mentioned do notation; it's just syntax sugar after all :)
Oh it's less of an issue, but syntax does matter a lot. I find that Monads become intractable for new devs without do-notation.
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.
I thought Elm was known for having vast quantities of boilerplate? I wouldn't put much stock into number of lines of code.