My question is, how will he feel about this three years from now? When he is trying to hire someone? Or when the folks behind Elm don't update it as often as they should?
The problem with unpopular languages is twofold:
* lack of talent that can step right in and be effective
* lack of resources to push the language forward
The first can be remediated by planning to bring new hires up to speed, and just making that investment in them. (It can also be a useful filter, making sure you are hiring someone who is really interested to the company and is willing to make the time investment to learn what is probaly not a very portable skill.)
The second is a bigger problem, if the main sponsor of the language moves on. If the main sponsor is committed, then you're probably fine. (I have no idea who pushes Elm forward, looks like there's a foundation from the wikipedia page.)
Haskell has enormous momentum now[1], and it's speed of development is accelerating. I came to it not because it was cool, but because my experience maintaining and refactoring a big Python program had become really painful. Haskell lets me keep the codebase smaller, it's easier to be pretty sure things are working, it's easier to refactor, and I'm sure the language will only keep getting better. Those are all understatements.
I don't get it. The author didn't address his original concerns, he just said "Elm is awesome", which may be true, but isn't a rebuttal of his previous points, which are condensed here:
>You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.
I suspect the missing connection is this: if you encounter a conceptual/technical bug with a popular language/framework, you can find a solution online quickly.
If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those.
This is common reaction to Elm and especially to Elm.
I also use Elixir and it has great community and everything, but somehow Elm is even more.
All the concerns about 'unpopular' languages, lack of tooling, I feel it is quite the opposite. Elm formatter changed how I work and now I started using it in other languages, Elixir and JS are using it more, or maybe I just started paying more attention.
There are other smaller things that I noticed.
I wish I can work more in Elm, not less.
Also one more thing. Elm made me wish to be way better programmer. You are surrounded by smart people and you just need to show more if you want to keep up.
When you say smarter programmer I understand what you mean. But the way I look at it, Elm allows me to relax and be a dumber programmer. I commit my smarts up front to the type design and interfaces between types and then I can relax as the project grows from there because the compiler will enforce the invariants I've encoded into the types. Pure Bliss.
Elm is awesome. I just wish much more people and companies would adopt it (and ClojureScript) so it would gain popularity close to that of TypeScript. This could make the web (and the frontend job market) a better place.
I agree. I think TypeScript is a decent language, but after working with the DOM in a functional way, verses object-oriented and imperative paradigms, I don't think I'll ever go back. To paraphrase and hijack what the author stated, HTML feels like it was created for Elm (and functional programming in general). I'd add HTTP to that as well. The combination just feels right.
I'm a Java dev with just some basic experience writing functional code, mostly in Java/Kotlin/Groovy/Ceylon (all of which are primarily imperative!).
Can confirm: Elm is awesome, easy to pick up as long as you understand basic things like union types and immutability, and I found myself productive in it within a single day!
I notice Scala missing from your list - if you need the JVM or find Elm to not quite have what you need, it's a great language. It's basically the opposite end of the spectrum, design-wise - Elm is "let's create this highly opinionated, carefully curated language and try to make it perfect" and Scala is "let's throw every feature we can derive into our type system and let people work it out".
It's got it's issues (mostly that it's incredibly easy to abuse powerful features), but it also has a ton of stuff I really miss in other languages.
I have a web-based party game (CaH clone) I wrote in Scala for the back-end, Elm for the front-end. It's a bit old (I'm planning a rework and update when the next version of Elm comes out), and it's definitely not the best code ever as it's a hobby project, but you might be interested.
There is so much to love about Elm. It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". Its compiler is great. The compiler catches almost everything and offers easy-to-read suggestions to fix your code when there is a problem. Elm's compiler virtually eliminates runtime errors; at least I've never had a runtime error with Elm.
I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.
There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm), if you're interested in learning it.
The recording of steps is called event sourcing and both vuex and redux implement the pattern, I'm sure elm is great but that benefit is not unique to elm
1 + "1" => "11" is not the sign of an "untyped" language. I would expect 1 + "1" => 50 (ascii asm), 1 + "1" => 242 (ebcdic asm) or 1 + 1 => 2 (length tagged string, eg, untyped pascal-ish variant), or 1 + "1" => some seemingly random value (C lang) in an "untyped" language.
1 + "1" => "11" is strongly typed, dynamically typed, with a particular type conversion that favours "strings".
But, on reflection, I am probably an pedantic iconoclast.
My first thought: The author would probably be equally satisfied if they had used JavaScript with flowtype and react. It sounds like they're comparing JQuery + Bootstrap (and similar "old" frontend frameworks) to Elm.
I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.
I can't speak for the author, but I made the transition from JS+React to TypeScript+React to Elm and it "changed my mind" too.
When I started with React/Redux, I didn't know much about functional programming, but I developed a certain interest... A couple years later my React stack was full of tools and libraries that allowed me to write my React apps in a more functional manner. I used TypeScript for the type system, ImmutbaleJS for immutable data structures, Ramda as a FP utility library and Recompose to call React itself in a functional manner. I also used pure stateless components exclusively... Then I switched to Elm and I realized, that the React stack I was working with was a crippled version of Elm. I'm currently writing my first app in Elm and it feels much smoother.
Perhaps, but with Elm you get a much better experience revolving about the tooling(Inspired from Golang I believe). This would be one of my top arguments for picking Elm over a giant mess of react+infinite choices of libraries and configurations.
Not the author, but I've used React + Redux and Flowtype and played a little bit with Elm. Elm felt so much cleaner, the typing was great and it was a breeze to learn. I'm certain I'll go with Elm on my next web project.
I built this in browser database app entirely in ELM. Since there is no existing rich component library available I had to write everything including a high performance grid implementation from scratch. The entire app took about a week and has zero runtime bugs since launch. I have to give credit to Elm for most of that.
One of the main problems with unpopular languages (which this article completely ignores) is growing the team, and hiring in general. In other words: the future of your project.
It's not just that it's hard to find people to join you, it's that even engineers who might be considering joining might decide it's not a good career move since they are going to spend years learning a language or a platform that sees no adoption and will not serve their future career.
This piqued my interest in Elm which lead me to start reading the Elm introduction[0] and it's great! I don't know if I'll ever use it in production but these well-written docs sparked the programming interest in me once again. Will definitely write some side project in Elm.
We use(d) Elm at the company I work at. (A start-up.) Elm is great. All of the positive rumors about it are true.
The issue we've had with Elm isn't typically discussed in these conversations: My CTO doesn't seem to see the value of it+. So we recently replaced our Elm code with JavaScript.
I wonder if anyone else finds themselves in a similar situation.
+It's a bit more nuanced. We're in a very "MVP" stage; the line of thinking is to use something everyone's more familiar with so we can move fast.
I wouldn't write off an entire company on this abbreviated description, but damn, I'd be worried about this. It does not speak highly of your CTO.
I'm not saying Elm is objectively better than JavaScript (I don't do either). But, can't these things sit side by side. And, if so, how is rewriting code aligned with moving faster? At worst, keep what you have in Elm, and write new code in JS? Also, there's plenty of "ugghh" with JavaScript that I'm skeptical of anyone throwing away existing code in order to rewrite it in javascript.
This is all doubly true for a early-stage MVP, where I'd expect a CTO to be technically minded and enthusiastic. Sounds more like "I know JS so we'll do JS."
If you're looking for a language for your own projects then, sure, Elm is a fine choice. When it comes to getting a job as a developer, however, it's a different story. The languages companies are willing to pay big bucks for tend to have been around for a long time. Tech, as a profession, is paradoxically very conservative. Even startups tend to go with Rails and that's been around for over a decade. Ecosystem maturity matters where money is at stake. Today I was offered a £460 per day contract to do Codeigniter for MBNA. Unfortunately it involved relocation. Not even Laravel, just plain old Codeigniter. Who's paying that to write Elm? Personally I love writing Clojure for my own projects but, again, Clojure jobs are thin on the ground even in London so I don't expect to make a career out of it.
> > First, Elm has the natural predictability of a pure functional language; when you write Elm, the compiler forces you to consider every case.
> I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX.
So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.
"Functional language" has come to tend to mean a language with an ML-style type system, possibly because almost all serious languages these days have first-class functions and map/reduce/filter. But ultimately the term means different things to different people.
Not at all. The term language determines what type systems are possible. The lambda calculus serves as an excellent base for languages that admit good type systems.
If one really wanted to... one could run a browser on the server to run a page powered by Elm, and then click on the page using Selenium style web driver. I'm guessing it wouldn't scale well :)
I wonder how to become a good functional programmer. I think I'm already decent at procedural/OO.
Do I need to have a strong maths background? I didn't learn it very well at university and this worries me. Many functional language fans seem to have degrees in maths.
FP is mostly a state of mind - of course picking the language really helps about incentives, but you can do it even in Java/C# (in fact if you do C# there is the great LINQ library that helps).
How to approximate FP in a mostly OOP language:
- use immutable data structures: there is no way around being able to fearlessly modify something. The naive way is to copy the object before touching it, the better way is to use efficient structures, e.g. Clojure data structures from Java.
- you either have data classes (no methods, no private fields), or execution classes (no data fields, only static methods), no mixing
- of you stick to the above, you will find that returning void from a method is very difficult.
Congrats, you're doing FP: the gist of it is that it's all about keeping state explicit; if you pass some A in a function, you will return a B at some point, and that's your result. No implicit state.
Of course, we're missing the whole part about side effects, so to add to the above: if you cannot write a unit test without mocking something in your method, you're doing side effects. They should be done only at the "border" of the application, to (maybe) get you the data you need, so you can bring it and process it in the pure core.
And this is where languages like Haskell help: to understand where the side effects are (because they are included in the types) and to prevent mixing them around (which only gets you an untestable mess in the end).
Math isn’t required. FP is about thinking of data structures and transformations from A to B. If you’ve ever used underscore.js, you’ve probably used FP patterns and functions. Map, filter, reduce are all part of that.
I don't think so. If anything I feel it's a bit easier as you don't need to reason about object state. It's also different, which is the main hurdle. If you use emacs you've already been exposed - Emacs Lisp is functional. If you're coming from a Web background both Elm and Elixir are great places to begin. You'll often hear stuff like "Javascript can be written in a functional style" - which is true, functional programming is a paradigm you can just go with - but seeing it really embraced by the language is really inspiring.
Pick a project. Pick a functional language. Code the project. That's it. It's not that different that, given enough willingness, you wouldn't be able to learn it yourself if you are decent at procedural / OO. You don't need any advanced math whatsoever.
> But when I joined Real Kinetic, I found out we were writing web client code in Elm. Elm? Really? The experimental language created for Haskell snobs who can’t handle stooping to the level of a regular blue-collar language like Javascript?
'bit of an odd thinking considering Evan's aversion to high-minded abstractions.
> "I don’t want to be the guy that finds a bug in the compiler."
When I'm wearing by "be productive" hat, I don't, either, but how realistic is that? Unless you've memorized the bug database for your compiler, running into a known bug is just as frustrating as discovering a new one, and I'm pretty sure I've run into at least a few bugs in every compiler I've ever used. According to my comments, my current flagship program has workarounds for 5 (known) compiler bugs.
I'd love to use only stable bug-free compilers (maybe Forth?), but I'm not sure that's practical. A more reasonable solution is to only use the popular parts of languages -- though apparently I'm not so great at discerning what those are, either!
[+] [-] mooreds|8 years ago|reply
The problem with unpopular languages is twofold:
* lack of talent that can step right in and be effective
* lack of resources to push the language forward
The first can be remediated by planning to bring new hires up to speed, and just making that investment in them. (It can also be a useful filter, making sure you are hiring someone who is really interested to the company and is willing to make the time investment to learn what is probaly not a very portable skill.)
The second is a bigger problem, if the main sponsor of the language moves on. If the main sponsor is committed, then you're probably fine. (I have no idea who pushes Elm forward, looks like there's a foundation from the wikipedia page.)
[+] [-] Jeff_Brown|8 years ago|reply
[1] https://www.haskell.org/communities/05-2017/html/report.html
[+] [-] TremendousJudge|8 years ago|reply
>You can go through the whole development lifecycle of the app and you’ll rarely encounter a situation where you can’t find a fix online in 5 seconds. Somebody else has already worked out the kinks. My strategy was flawless.
[+] [-] macintux|8 years ago|reply
If you write buggy code (especially bugs that don't reveal themselves until live in production) it involves much, much more pain to fix those.
Elm helps significantly with the latter.
[+] [-] rkangel|8 years ago|reply
[+] [-] desireco42|8 years ago|reply
I also use Elixir and it has great community and everything, but somehow Elm is even more.
All the concerns about 'unpopular' languages, lack of tooling, I feel it is quite the opposite. Elm formatter changed how I work and now I started using it in other languages, Elixir and JS are using it more, or maybe I just started paying more attention.
There are other smaller things that I noticed.
I wish I can work more in Elm, not less.
Also one more thing. Elm made me wish to be way better programmer. You are surrounded by smart people and you just need to show more if you want to keep up.
[+] [-] ghthor|8 years ago|reply
[+] [-] qwerty456127|8 years ago|reply
[+] [-] innocentoldguy|8 years ago|reply
[+] [-] brabel|8 years ago|reply
[+] [-] Latty|8 years ago|reply
It's got it's issues (mostly that it's incredibly easy to abuse powerful features), but it also has a ton of stuff I really miss in other languages.
I have a web-based party game (CaH clone) I wrote in Scala for the back-end, Elm for the front-end. It's a bit old (I'm planning a rework and update when the next version of Elm comes out), and it's definitely not the best code ever as it's a hobby project, but you might be interested.
https://github.com/lattyware/massivedecks
[+] [-] innocentoldguy|8 years ago|reply
I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.
There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm), if you're interested in learning it.
[+] [-] joshribakoff|8 years ago|reply
https://martinfowler.com/eaaDev/EventSourcing.html
[+] [-] ratboy666|8 years ago|reply
1 + "1" => "11" is strongly typed, dynamically typed, with a particular type conversion that favours "strings".
But, on reflection, I am probably an pedantic iconoclast.
[+] [-] thaumasiotes|8 years ago|reply
I mostly agree with your point here, but in this specific example I actually think Perl did the right thing, where
are all 2, and are all 11. Letting you specify the result you want by the function you call basically solves that whole problem.[+] [-] regularhackerer|8 years ago|reply
[+] [-] seveibar|8 years ago|reply
I think the point still stands that unpopular frameworks/languages can still be stable and more effective than popular frameworks.
[+] [-] Rotareti|8 years ago|reply
When I started with React/Redux, I didn't know much about functional programming, but I developed a certain interest... A couple years later my React stack was full of tools and libraries that allowed me to write my React apps in a more functional manner. I used TypeScript for the type system, ImmutbaleJS for immutable data structures, Ramda as a FP utility library and Recompose to call React itself in a functional manner. I also used pure stateless components exclusively... Then I switched to Elm and I realized, that the React stack I was working with was a crippled version of Elm. I'm currently writing my first app in Elm and it feels much smoother.
[+] [-] ghthor|8 years ago|reply
[+] [-] ajmurmann|8 years ago|reply
[+] [-] gsvclass|8 years ago|reply
https://bellpluscat.com/
[+] [-] boundlessdreamz|8 years ago|reply
[+] [-] cbenz|8 years ago|reply
As an Elm developer I would be interested to dive into your implementation and perhaps contribute.
[+] [-] hota_mazi|8 years ago|reply
It's not just that it's hard to find people to join you, it's that even engineers who might be considering joining might decide it's not a good career move since they are going to spend years learning a language or a platform that sees no adoption and will not serve their future career.
[+] [-] joevandyk|8 years ago|reply
[+] [-] antonkm|8 years ago|reply
0: https://guide.elm-lang.org
[+] [-] GenghisSean|8 years ago|reply
[+] [-] PaulStatezny|8 years ago|reply
The issue we've had with Elm isn't typically discussed in these conversations: My CTO doesn't seem to see the value of it+. So we recently replaced our Elm code with JavaScript.
I wonder if anyone else finds themselves in a similar situation.
+It's a bit more nuanced. We're in a very "MVP" stage; the line of thinking is to use something everyone's more familiar with so we can move fast.
[+] [-] latch|8 years ago|reply
I'm not saying Elm is objectively better than JavaScript (I don't do either). But, can't these things sit side by side. And, if so, how is rewriting code aligned with moving faster? At worst, keep what you have in Elm, and write new code in JS? Also, there's plenty of "ugghh" with JavaScript that I'm skeptical of anyone throwing away existing code in order to rewrite it in javascript.
This is all doubly true for a early-stage MVP, where I'd expect a CTO to be technically minded and enthusiastic. Sounds more like "I know JS so we'll do JS."
[+] [-] cutler|8 years ago|reply
[+] [-] klez|8 years ago|reply
I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
[+] [-] seveibar|8 years ago|reply
> I'm a beginner with functional languages, but isn't the type system completely orthogonal to the fact that Elm is a functional language?
Yes. The author probably would be equally satisfied with any robust typed solution (flowtype, typescript). They also say that Elm nicely interfaces with the DOM, which I believe is mitigated by JSX.
So in some sense the article is more about JQuery/Bootstrap/other legacy solutions being bad.
[+] [-] johnfn|8 years ago|reply
You're completely correct, though for whatever reason functional languages almost always have strong type systems.
[+] [-] lmm|8 years ago|reply
[+] [-] danharaj|8 years ago|reply
Better than, say, assembly language.
[+] [-] rishav_sharan|8 years ago|reply
[+] [-] Rotareti|8 years ago|reply
Some people mention this as a disadvantage. I think it would be cool to have a decent DSL dedicated to just frontends.
[+] [-] amorphid|8 years ago|reply
"What stack are you guys using for the backend?"
"SLEW: Selenium Webkit Elm LocalStoarge"
"Wat..."
[+] [-] b0rsuk|8 years ago|reply
Do I need to have a strong maths background? I didn't learn it very well at university and this worries me. Many functional language fans seem to have degrees in maths.
[+] [-] ff_|8 years ago|reply
How to approximate FP in a mostly OOP language:
- use immutable data structures: there is no way around being able to fearlessly modify something. The naive way is to copy the object before touching it, the better way is to use efficient structures, e.g. Clojure data structures from Java.
- you either have data classes (no methods, no private fields), or execution classes (no data fields, only static methods), no mixing
- of you stick to the above, you will find that returning void from a method is very difficult.
Congrats, you're doing FP: the gist of it is that it's all about keeping state explicit; if you pass some A in a function, you will return a B at some point, and that's your result. No implicit state.
Of course, we're missing the whole part about side effects, so to add to the above: if you cannot write a unit test without mocking something in your method, you're doing side effects. They should be done only at the "border" of the application, to (maybe) get you the data you need, so you can bring it and process it in the pure core.
And this is where languages like Haskell help: to understand where the side effects are (because they are included in the types) and to prevent mixing them around (which only gets you an untestable mess in the end).
HTH
[+] [-] _sdegutis|8 years ago|reply
[+] [-] lewisinc|8 years ago|reply
[+] [-] mnm1|8 years ago|reply
[+] [-] scns|8 years ago|reply
[+] [-] masklinn|8 years ago|reply
'bit of an odd thinking considering Evan's aversion to high-minded abstractions.
[+] [-] ken|8 years ago|reply
When I'm wearing by "be productive" hat, I don't, either, but how realistic is that? Unless you've memorized the bug database for your compiler, running into a known bug is just as frustrating as discovering a new one, and I'm pretty sure I've run into at least a few bugs in every compiler I've ever used. According to my comments, my current flagship program has workarounds for 5 (known) compiler bugs.
I'd love to use only stable bug-free compilers (maybe Forth?), but I'm not sure that's practical. A more reasonable solution is to only use the popular parts of languages -- though apparently I'm not so great at discerning what those are, either!
[+] [-] woolvalley|8 years ago|reply
[+] [-] ggm|8 years ago|reply