Faithful Elm and the Amazing Router
gizra.com
gizra.com
I didn't think I needed types, until I tried Elm, now I am seriously having an identity crisis..
All my backend Python code is also riddled with type hints to help out with the cognitive load.
Elm - Simple, friendly, helpful
Just wish Elm was more mature, but loving it anyway!
Everyone talks about higher order functions and generic types but lots of languages have that.... the really good ones have ADTs.
Oh what I would give to have ADTs in Java. I would stop using Exceptions for errors (not all exceptions are bad just most of them). I would stop using the annoying visitor pattern... That reminds me that I need to rexamine Derive4J
No typeclasses, no monads, more primitive pattern matching, no guards, use of massive nested elseif considered idiomatic ...
Simple tasks wind up feeling tedious because so many of the standard tools and patterns of any other ML language are simple missing completely. The result feels like trying to work with one of those random toy Lisps people make in a weekend and throw up on Github.
It frustrates me, because in theory I do like the concept of the Elm architecture, I love ML-style type systems, and I work with reactive programming every day in ClojureScript. But the language it's attached to is so incomplete that it quickly just becomes a pain.
Javascript dev sees Elm and might think "Wow,a type-system and it is awesome, didn't expect that"
Haskell dev sees Elm and might think "I am missing so many features with these types" and consider something else, probably pure-script, that has similar toolbelt.
Not sure about the rest though.
I'm currently using it in production with purescript-thermite, a thin wrapper over React, and it's worked out great.
Elm is great for people coming from JS, but not so much for people coming from Haskell.
On the other hand, OCaml also targets JavaScript coding in the browser, via js_of_ocaml or the newer bucklescript.
I would be very interested in a comparison of client-side development with OCaml+js_of_ocaml (or OCaml+bucklescript) versus Elm.
You'd think Beam would be a very different compile target than JS, and it seems weird to make such a huge change without very good reason.
The Elm folks have been fairly buddy-buddy with the Elixir/Phoenix folks, so this doesn't surprise me
It makes my heart sing that a different VM than JVM or .Net is gaining more traction, and as a static types fan it makes me happy that a statically typed language may be getting on Beam.
http://i.imgur.com/pqk9oMl.png
It will definitely be a very different compile target. But Elm really doesn't take any inspiration from Javascript, so I don't think it will change much about the fundamentals of the language. Of course they'll need to add capabilities for concurrency, OTP, etc.
I'd just looove to try and put Elm on the JVM, but I just can't at the moment.
http://learnyousomeerlang.com/dialyzer
But is still optional to compile. The more precise and better the type annotations, the more helpful it is. If it can deduce that some inconsistency or type error occurring it will let user know. If it is not sure, it won't say anything.
Another point is because of isolated process heaps and extra fault tolerance, it is possible to get a high degree of assurance from a system built in Erlang or Elixir even with dynamic typing. And there are certainly many examples of that.
Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit. So I stand by my point that Elixir is a very different language in practice from Elm.
This is not true. While Elixir may not make things as explicit as Elm (I don't know Elm well enough to assert or refute such a statement), the author of Elixir has stated in various occasions that Elixir prefers explicit to implicit.
For instance, in Elixir, unless one explicitly defines a String.Chars protocol for a data structure, string interpolation of that data structure will not compile. In contrast, pretty much everything can be implicitly interpolated in Ruby.
Another example is function calls. In Elixir, if f is not a named function but a variable bound to an anonymous function, you cannot call it by writing something like f(x). Instead, you must put a dot after f and write f.(x) to state clearly that you are calling an anonymous function.
I kind of like to think of it as the Java to late 90s' C++, where "less is more" made it popular.
<personal understanding> Scala seems to want to please everyone, having all the tools at hand - Immutable and Mutable collections, Objects and enforced Pure Functions etc.
That to me seems like a call for trouble in the community, a split between approaches to problem solving at a fundamental level. </personal understanding>
And well one of the things that I love about Elm is the lack of needing to make too many choices because the language doesn't have too many complicated features and prioritises "One good lib over 5 decent libs" (though at this young stage what other option does it have).
Clojurescript, Javascript and I'm betting Scala.js offer a lot of solutions to the same problem and/or have fancy language features that I am looking for an escape from. Just personally want to try going back to "less is more", to see what it is like. :)
Currently, Scala-Native is working on off-JVM Scala, Scala.js is already plenty capable of compiling to efficient JS, and when wasm lands, it'll probably manage that rather easily.
Elm is a neat language, but I think it sort of presents too wide a divide. I have the same problem with Elm as I do with Typescript, Dart, and all of the other languages that recognize JS is a shit language, but just compile to it anyways.
Scala is a VERY well-designed language, and FP/OOP isn't nearly as polarizing as it might seem. I'd recommend LearnXinY Scala, read a little bit and you might see how natural it actually is (excluding the obnoxious syntax for certain things)
But yeah, JS has always been the crucial problem that needs to be solved. *.js is never going to solve it.
What I'm getting at is that OOP+FP is, ultimately, simply OOP, providing none of the guarantees and encouraging none of the best practices that purely FP langs do. It's like the worst of both worlds lol
</opinion>
"OOP" implies none of things you are worried about and Scala is a great example of that.
I wished people tried the language before making assumptions based on emotions that are not supported by reality.
I think the important part is to think about how to properly modularize your codebase and not overdoing it. That gets you an "internal" library ecosystem and not only ensures that incremental builds are fast (not really a concern anymore on nowadays) but also fast parallel compiles and deploys.
Code reviews are of course important so that developers are on the same page, but Scala is really great about isolating parts that have to be complicated from the rest (not like Java's " oh, you used a wildcard over there, let's infect the whole codebase with it").
So life is pretty good and I don't think there are huge issues you have to keep in mind compared to other languages, despite the goodness Scala provides you with.
I think most outside concerns are largely overblown: E. g. some people coming from Java might be excited in the first week bring able to define some operators, but it doesn't really matter. Most of the symbols you see in practice are pretty standard (+, -, ... for arithmetic, a few collection things like + (add one thing), ++ (add multiple things) etc.). Going overboard with it is considered bad style, so most libraries out there just don't do it anymore.
Tooling is pretty great overall, although IDEs could always be a bit better.
Compatibility is great and releases are rock-solid, even things like Scala.js which hasn't even reached 1.0 yet.
1. https://github.com/japgolly/scalajs-react
Basically, two things may happen in the future:
- all the libs existing in JS are recoded by dedicated fanatics in the advanced language. Then you have a versatile all-purpose development ecosystem with this language.
or
- you rely upon the existing JS ecosystem and libs, and eventually spend your time struggling with the impedance mismatch between JS and your advanced langage.
Did you feel something like that with Purescript, Elm, etc?
It might seem like horror to have to interface to external dependencies, but if the libraries you want to access aren't extremely complex then interfacing with them probably isn't going to be such a huge problem.
In some cases you might want to use the advanced language for some things but keep the outer layer of the app in JavaScript. At a previous workplace we had a particularly tricky parsing module written in Fay (Haskell subset compiling to JS).
A word of warning: with Clojurescript, at least, there is a big cost to converting between JS and CLJS types. This has been a big painpoint as our need for frequent calculations increases. Still, we wouldn't have it any other way.
Once you dont need jquery and you actually have a standard library, 2 of the largest requirements to the existing ecosystem (JQuery and Underscore.js) are no longer needed.
Elm looks to handle much of he DOM and events so I doubt you would need React.js or Angular, which just leaves your datastore.
(to better put it, much of the packages in Javascript are there because the language itself is insufficient to describe DOM interactions. Elm was created explicitly for the web thus removes the need for many packages)
- continuous evolution of the JS ecosystem towards a cleaner language, with solutions like Flow or TypeScript.