The human brain has evolved to engineer things in a lego-like way. Elm and the human brain were meant to be together since the beginning of time.
2 Likes
Got me thinking.
Total functions mean that programs don’t just fail on you. In Python or Javascript or Java or most OO languages, software can throw runtime exceptions which usually have the effect of shutting down the runtime and printing an error.
Since Elm has (nearly) no runtime errors, the equivalent in Elm becomes a total function:
computeStuff : Input -> Result Error Answer
Of course the Error might just be a String, in which case its maybe no better than the above. But I usually define an Error type:
type Error
= CouldNotFindTheFile String
| FailedToCompile CompileErrors
| OrWhateverItWas String
Total functions means software does not fail, it reports errors. That shift in thinking encourages developers to invest in better error reporting.
Weak typing is also what makes using javascript hard. The model is never explicitly defined and the compiler won’t help you get it right. Forever reading the online docs making sure you got all the field names exactly right.
Hard to get the input model right, and hard to understand all those error stack traces. Thats a whole cognitive load you don’t have to deal with in Elm.
BTW, I think there is one thing Elm could do to make error reporting even better - to be able to add source code location to an error message (Basics.sourcePos). Otherwise you need to find a way of making every error unique, if you need to grep your way back to finding where an error came from.
5 Likes
Simplicity, easy refactoring and clear composition. Little hidden magic. Great tooling. Clear best practices for module-level exports and imports.
So I ranted a little about my experience with Yesod elsewhere this morning, and I’m going to repeat myself a little here because I think it highlights how the supposed simplicity and limitations of Elm allow you to do more.
Whenever I need to write some Haskell (which is admittedly not that often anymore), I think I should be able re-create the elm experience by keeping functions simple and small and elm-like.
And maybe you can do so for a few small modules. But It just takes so much discipline and maybe a bit of library luck to keep the complexity of the language from snowballing in your application. As soon as you start using any non-trivial libraries you’re done, each compounding a different set of type-level trickery and layering hidden effects.
Magic starts seeping in. Now the same line of code in one context does completely different things in another context based on the compiler deducing some underlying type hidden deep in the complexity.
In order to refactor, you need to discover and import several buried subtypes to satisfy some type constraints for the compiler. Now two pieces of code that used to magically compose within the larger function, don’t compose anymore because of the explicit types you had written.
So now you’re combining types into a new transformer to try to make things more readable, and you’re lifting this and mapping that and next thing you know you’re writing a new Lens helper library for your monster.
So yes, I admit I’m probably doing it wrong. And sometimes I really love the power of Haskell. But with Elm it’s just so easy to do it right, and that little bit of extra boilerplate means that I can read (and test) exactly what my encoder is going to do.
7 Likes
Reasons I love Elm:
-
Elm is the JavaScript fatigue antidote.
Instead of spending much of my time integrating libraries or learning new language/framework/library features, I write software that adds business value and doesn’t break. -
Elm is ergonomic.
Libraries are well-thought-out, consistent (AKA boring), and fit together nicely. -
Elm teaches me how to write better software, in Elm of course, but also in other languages.
Some of the lessons: separating data and logic, being explicit, doing things one way, annotating types, and doing things right instead of right now. There are so many more! -
Elm is authentic.
It remains true to its values, despite external pressures.
14 Likes
-
Refactoring. I haven’t been afraid to break things in big ways while refactoring since I know that after I fix the compiler errors, it will just work. Haven’t had that experience with any other programming environment. More systems should have this experience as a goal.
-
No runtime errors. Coming from a mostly Python/C/whatever background, there are just too many things to remember because those languages have features that are constantly plotting to stab you at runtime. Not so in Elm.
-
Package management. Watching how installing a javascript dependency from npm manages to pull in a few hundred more is concerning. Elm doesn’t do this, and it is a relief to not have to worry about actually using 3rd party libraries.
-
Language idioms. Diving into an unknown codebase doesn’t scare me at all. In many cases, it’s easy to recognize a new pattern here and there that is immediately useful in design of my own code.
-
Community. Great job everyone
Thanks to the Slack channels - very friendly and helpful. -
My own slight feeling of smugness when I see popular Javascript frameworks claiming design inspiration from TEA and other ideas from Elm. We’re using the real deal over here. Ha! Take that Javascript.
9 Likes
Elm is literally the best work of art I have ever seen. The minimalism is insane. Everything fits together perfectly. I will make an OnlyFans if I discover something better than Elm.
4 Likes
Re minimalism, yes!!! Elm is indeed a work of art.
Related content: this talk by Robert Virding, one of the architects of Erlang, on programming language design. He makes a very big deal of the importance of simplicity, which, as he states, is not easy to achieve.
4 Likes
@jxxcarlson, I assume this is the video you mentioned: Robert Virding - On Language Design (Lambda Days 2016) - YouTube
It seems fitting very well with the “Elm philosophy”
5 Likes
I like that it is pure, typed, and functional. There’s also something that I heard/read before and remembered I was nodding to it (but couldn’t find it).
With Elm, I could take a sure-footed approach to problems that I might have previously felt is too hard for me. My Elm solution to each small part cumulates to the final solution without requiring me to keep revisiting at every step (because it’s “proven”). And the best part is, after I’ve crossed the finishing line & gotten everything working, tidying up my entire solution is a safe and mechanical process. Confidence++
5 Likes
Yes, that’s the video. I really liked Virding’s view of software development.
1 Like
perfectly explained!
2 Likes
I’m not as experienced with Elm as most people here, but for me:
- Simplicity: very small language that allows you to do anything
- Tooling: amazing tools
- Type system
- No configurations
- Stability: every JS programmer start to have fatigue after some years of experience. I love that Elm is very stable, so your knowledge last longer than in the JS ecosystem.
For me learning Elm makes you a better programmer overall, since the language is so simple it has very interesting concepts that can be applied to other ecosystems.
6 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.