Some people mention this as a disadvantage. I think it would be cool to have a decent DSL dedicated to just frontends.
"What stack are you guys using for the backend?"
"SLEW: Selenium Webkit Elm LocalStoarge"
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.
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).
'bit of an odd thinking considering Evan's aversion to high-minded abstractions.
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!
Wouldn't that be the case with _every_ typed and compiled programming languages (or at least, every typed and compiled programming languages that support pattern matching)?
* sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons)
* has only one escape hatch of "Debug.crash", which it strongly recommends not using and which it seems many Elm devs aren't even aware exists (in my avowedly shallow experience)
* and which you use as bottom by hand-rolling pattern matches
* at which point you might as well do it correctly
To the extent that you can require proper handling of everything, I would say that Elm is much stricter than Haskell or OCaml or Rust.
You can be very strict in them, but they don't enforce it to the extent Elm does. At least in my experience.
The general rule of thumb that a larger active community leads to faster software development is more or less still true. There is no reason to suspect this is not the case with Elm.
It's all fun and games until you get hired to build a production-grade web stack in a dinky game-scripting language with no community, that you have written 0 lines of code in. Some people live and breath to reinvent wheels in 19 different languages. Not my cup of tea.
Yes, and not only because the volume of copy-paste source code on StackOverflow. I suspect Elm is slower to get a feature out, but once it is out you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code. And so later on in the same project ... you are faster.
> It's all fun and games until you get hired to build a production-grade web stack in a dinky game-scripting language with no community, that you have written 0 lines of code in. Some people live and breath to reinvent wheels in 19 different languages. Not my cup of tea.
From what I have seen Elm is absolutely fit for production grade work. There is a community. The community tends to have smarter on average people in it. Simply because all the less smart people are put off. Sounds elitist? Maybe.
A community shouldn't be judged based on how smart everyone is (quite a difficult measure), a more useful metric would be how many useful community libraries there are. For example, if I can choose between 50 carousels implemented in React vs. 2 in Elm, and I'm an average developer -- what will I choose?
> you spend less time fixing bugs in feature A caused by adding feature B silently changing some assumptions you made in code.
IMO this is an advantage of the smaller/smarter/niche (whatever you want to call them) programming communities. When they congregate around a couple libraries for common problems, those libraries tend to be very good. Speaking from experience in the Elm and Clojure ecosystems.
It’s much better in terms of developer time to evaluate 2 good libraries than 50 libraries where the quality ranges from abysmal to good.
But ... in addition to npm/babel etc. you need a wetware constraint checker. React says "human: make sure your data is immutable - please don't forget or something might break later in production". Elm says "I guarantee immutability"
That seems more of a metric for an ecosystem than a community.
"People who use Elm are smarter" is simply not actionable information. What does it even mean? It's meaningless.
You can e.g. Rocket scientists VS. Janitors.
Note what I am not saying (which people might take offense to) is "you use Vue not Elm, so you are dumb". Nope of course that isn't true!. I am saying in aggregate, due to selection biases etc, Elm attracts smart people. A lot of really smart people will stick to popular frameworks and not use Elm. Some bad programmers might use Elm for some reason. Aggregates are what I am talking about.
> "what are third party libs like?", "how active are people in this community?", "how active is the SO and other forums?". These are actionable questions.
These are good questions.
Another question though is: how much do I trust another library to not have bugs? Given Elm's design vs. vanilla JS, I'd go for Elm. That confidence extends to "How much do I trust a Library I knocked up over the weekend to solve an previously unsolved problem in Elm".
To assume with no basis, sure; to conclude it may or may not be.
> It's just not even the right question to ask.
It's not inherently operationalized, sure, though (as seen elsewhere in this thread), “advertising jobs for platform A results in us needing to filter out fewer candidates with no real programming ability than when we advertise jobs for platform B” I'd pretty much an operationalization of it, and quite (to address your later point) actionable.
Have you thought about the possibility that it's actually a community of people who first and foremost _consider_ themselves as being smarter than the rest? Maybe this is what's really off-putting to equally smart, but more humble developers?
I wouldn't use it for any frontend work just because I believe that it's possible to avoid single page apps if possible, but if I had to write a SPA I'd reach for Elm.
The only thing that makes me worried is that Elm 0.18 has been out for quite a while now and most of the development has been carried on behind the scenes by Evan.
This is good because it gives the time to the language to evolve in a coherent way instead of being a collection of bolted on features, but it also means that for outsiders is a bit hard to track progress in the language
After reading this article and reflecting on my own experiences and habits, my rule of thumb would be "choose the best of those with second-tier popularity." It's common that the most popular isn't the best, has advantages in numbers, but also disadvantages like low S/N ratio.
Many of the pitfalls of a scarcity are avoided, and can sometimes find a well-organized, curated, cultured pocket of enlightenment.
While Tech evolves, being able to work with what exists and the future remains incredibly valuable.
But it's been 14 months since the latest full release.
|> List.map .authors
|> List.concatMap .authors
What you are doing isn't new or groundbreaking, so why bother bringing in extra drama and ceremony by using a language very few people use to achieve the same result? Just seems like added complexity for no reason, even if the code looks simple with the first pass.
Because for something so mundane then it really doesn't matter what you use and you know the domain so well that you can recover from any hangups.
I certainly don't consider it self-evident that you always just use mundane solutions to mundane problems. Depends on your appetite for risk and how biz-critical the problem is.
People are probably the biggest determining factor in achieving a quality result. But I don't think that means we should forget about trying to improve our tools.
You might think Japanese is an awesome language and decide to learn it, but then what use is speaking Japanese outside of Japan? Around the world people still just use boring ol’ English, even though English is actually a pretty shitty language and full of hacks to make up for weird edge cases (read and read, goose and geese, mice and meese?, Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo)
Likewise, if you write something in Clojure, you have far less people and libraries and platforms that can help you accomplish whatever you are doing. If what you are doing is not something new or groundbreaking that could only be done well with Clojure, then the extra effort you have to spend to get up and running is not worth it.
If it's literally just you, there's a lot of benefit to leveraging existing work so that you can focus on the differentiating part of the project(which is probably not a language innovation). It's not just the libraries but the whole ecosystem - example code, troubleshooting help, IDE support.
If you have an engineering team of even modest size, the picture can change very swiftly towards ensuring your result is built on a solid foundation, even if it means a lot of pioneering infrastructure has to be built and a lot of late nights spent debugging core toolchain issues. Team efforts have the necessary momentum to break free and do that ground work as the overhead gets swiftly absorbed in "person-year" budgetary terms. Individuals can only really justify the same as their core direction of research, sole hobby, or speculative investment - e.g. being the "first to implement" some hot new standard could be a well incentivized career move.
Then he links to issues for Qt and Go. They're certainly not obscure. What kind of weird argument is this? If anything, the argument there is that it doesn't matter how popular something is, as even extremely popular things like Qt and Go will still have bugs.
I guess there's only so many names in the world, and they're bound to be reused.
It feels like watching a cult of optimization function in a culture where measurement is taboo. It's absurd beyond belief.
To get Elm confused with the email client with this title, you'd have to not know the Elm language existed. So it seems like it's a moment to go "oh I see, that exists" than cursing the world because you thought "Elm changed my mind about unpopular languages" somehow referred to an email client.
But I get it. It's cathartic to be angry on the internet. The angry shadow boxing just gets pretty old for the rest of us no matter what kind of developer you are.
I'm certainly not confused about what Elm is. That'd be easy enough to find out. But "why you stopped using it" sure as shit isn't something I can google.