
Elm changed my mind about unpopular languages - lyddonb
https://blog.realkinetic.com/elm-changed-my-mind-about-unpopular-languages-190a23f4a834
======
mooreds
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.)

~~~
rtfeldman
Worth noting that in our experience, hiring has gotten _way_ easier for us
since we became an Elm shop. We really struggled to hire React engineers (who
have a zillion positions to choose among - why would they pick ours?), whereas
there seem to be a lot more great programmers who want to use Elm than there
are companies hiring for Elm positions.

Here's a verbatim quote from a cover letter (one I happened to be reading this
morning; we see a lot of similar stories):

> Despite my valiant evangelizing of Elm, my company has decided to embrace
> React over Elm, so I am looking for opportunities to develop Elm
> professionally.

Our Head of Talent said she'd never seen an inbound pipeline as strong as
ours, and the #1 reason people cite for wanting to apply is Elm. The "Python
Paradox"[0] is real!

[0]
[http://www.paulgraham.com/pypar.html](http://www.paulgraham.com/pypar.html)

~~~
onebot
Don't you want people that care about your product instead of the technology
behind it? I do. Because there may come a time when another technology is a
better fit for your product and ultimately your customer's experiences. Then
what? Now your not using elm and your team leaves or is disgruntled. I hire on
passion for what we are trying to accomplish, not the technology stack.

~~~
dozzie
> Don't you want people that care about your product instead of the technology
> behind it? I do.

I would rather have people who care about their craftsmanship and are
indifferent about the product than people who care about the product and are
indifferent about the craftsmanship. The former ones do a good job regardless
of what the product is about.

~~~
kjksf
"caring about craftsmanship" != "caring about elm"

I care about craftsmanship even when I'm writing JavaScript.

And when JavaScript is enough of a burden, I go to TypeScript, not Elm.

~~~
cies
But did you try Elm? Must say it's syntactically much sweeter than TS.

------
Jeff_Brown
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.

[1]
[https://www.haskell.org/communities/05-2017/html/report.html](https://www.haskell.org/communities/05-2017/html/report.html)

~~~
woolvalley
How much of it was haskell, and how much of it was just working with a
statically typed language?

~~~
Jeff_Brown
I used Java, C and C++ before coming to Python. Unlike theirs, Haskell's type
system is complete -- even a function of functions can specify exactly what
kinds of functions it uses for inputs and outputs. That makes higher order
programming much safer -- and higher-order programming might be the best way
to move fast.

Haskell is also astoundingly terse. In Java and C my data type declarations
were too long to fit on a page, full of redundancies and boilerplate. In
Haskell if you want to make, say, a data type that is either an X or an O
(suppose you're writing tic-tac-toe), you could do it in four words: 'data XO
= X | O'. (Notice that there's not even a natural way to do that in Java or C,
because they don't have sum types; you'd have to make a type that has a flag
to indicate whether it is an X or an O. That gets really complicated if
they're supposed to have different data associated with it -- but in Haskell,
if the X is supposed to carry a float and the O is supposed to carry a string,
you just add two more words.)

Pattern matching also helps with terseness. I don't have time even to write
the last paragraph so I'll skip this one.

Purity keeps you from tripping up on IO-related errors. It lets you be much
more certain that things are working. It also forces you to keep the IO in a
thin top-level layer of your program, which might sound like a pain but once
it feels natural you'll find yourself moving faster than you could before.

To be sure, Haskell has features that I don't use. But purity, sum types,
pattern matching, and the unusually rigorous (it's complete!) type system are
all critical to its value to me.

~~~
woolvalley
That complicated type system w/ type inference does come with it's own costs,
usually bad compile speed issues. It's what I've noticed when looking at
languages like swift, rust, scala & haskell.

I'm currently dealing with it in a large swift project, and I would much
rather go back to the extra verbosity of objective-c than have type inference
at this point.

But that was insightful, thank you!

~~~
Jeff_Brown
Have you noticed slow compiling with Haskell specifically?

~~~
woolvalley
I've only used swift at that size, but I've heard stories with all of those
languages once you have a large code base.

I remember vaguely reading about how at a haskell conference people were
basically cornering compiler maintainers about compile speed, but that was
several years ago.

~~~
Jeff_Brown
When I have to recompile, it's usually because I've only modified a few files,
and it's usually really fast. I particularly enjoy that if I refactor things
without actually making any changes in the way it works, GHC won't blink; it
knows there's nothing to do.

My codebase is only a few thousand lines, though.

~~~
woolvalley
Yeah the codebases I'm talking about are something around 1 million lines over
several apps, libraries, all of the tests and codegened models, mocks and
network services.

------
TremendousJudge
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.

~~~
macintux
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.

Elm helps significantly with the latter.

~~~
TremendousJudge
That's one of the points he raised, and I see the value now. However, the
author also talks about the dangers that come from using lesser-known, using
unstable languages (he mentions finding bugs in the compiler, segfaults, and
so on), and he doesn't say how Elm solves them

~~~
callumlocke
The author does emphasise how complete and well-built the official Elm tools
are, which kind of mitigates this concern. But I agree, the article doesn’t
really spell out its reasoning.

~~~
anonytrary
> does emphasise how complete and well-built the official Elm tools are

It's not a good point. It's just unrealistic to rely on standard libraries,
even if you're writing Scala or Python. Community size _must_ be an important
factor, even for Elm. It is highly unlikely that Elm is so perfect, that
community size simply becomes irrelevant.

I think we can all agree that this article isn't finished at all.

------
desireco42
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.

~~~
ghthor
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.

~~~
fjsolwmv
Big Design Up Front is back in style now? Agile is dead?

~~~
yawaramin
The beauty of strong static typing–you don't need to get the types right
immediately. Just get an initial design out the door and iterate towards
better designs as you go. The compiler helps you tremendously for refactoring,
and managed deprecations let you change types gradually over time.

------
qwerty456127
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.

~~~
innocentoldguy
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.

~~~
qwerty456127
Indeed!

------
brabel
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!

~~~
Latty
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.

[https://github.com/lattyware/massivedecks](https://github.com/lattyware/massivedecks)

~~~
anthonybullard
Scala's flaw - and Elm's strength - is it is a massive language that allows
for a large amount of magic to happen. Elm is by comparison tiny and extremely
explicit, and error messages thrown by the compiler are almost always super
helpful. But Elm can't (really) be used on the server, so it doesn't hurt to
look at Scala there, though be prepared to have a hard time finding
experienced engineers to hire.

~~~
leshow
Id argue that while Scala has more powerful features, it has less "magic". Elm
can't be used on the server because it has a magical create app function that
you must feed the exact right functions into in order to make anything. AFAIK
it's not a general purpose language.

~~~
anthonybullard
Definitely not general purpose, but it has nothing asking the line of
implicits and implicit type conversion and the such that makes reading Scala
code impossible to read, if not write, without a tool like IntelliJ.

~~~
lmm
I find it best to use Scala's implicit stuff for things that would be
completely invisible in another language (e.g. "this line might fail with an
error" or "this line accesses the database"). That way if you're reading in a
plain text editor you're no worse off than you were in, say, Python, but if
you use a tool like IntelliJ (and you should!) then the GUI is enhancing your
experience, telling you more about your code and reducing the need to click
around library code to understand what the code you're reading is doing.

------
innocentoldguy
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](https://pragmaticstudio.com/courses/elm)),
if you're interested in learning it.

~~~
thaumasiotes
> It is a typed language, so it eliminates typing issues, like 1 + "1" = "11".

I mostly agree with your point here, but in this specific example I actually
think Perl did the right thing, where

    
    
        1 + "1"
        "1" + 1
        1 + 1
        "1" + "1"
    

are all 2, and

    
    
        1 . "1"
        "1" . 1
        "1" . "1"
        1 . 1
    

are all 11. Letting you specify the _result_ you want by the function you call
basically solves that whole problem.

~~~
shaki-dora
That's just a "type system by obscurity". Extending it to provide the same
sort safety, you'd need specific function for all combinations of types:
sum_two_integers(), sum_integer_and_float() etc... Which would be both
extremely ugly and a terrible waste of memory.

~~~
thaumasiotes
You seem to have missed the whole point of my comment. sum_integer_and_float()
is the opposite of what I'm talking about. If you wanted to extend this system
within numeric operations, you'd have e.g. divide_and_return_integer() vs
divide_and_return_float() (funnily enough, this is also a very popular
distinction for languages to draw); sum_and_return_integer() vs
sum_and_return_float(); etc.

This usually isn't done because integers and decimals are fundamentally very
similar, so for addition there is a platonic correct result when you add an
integer and a float (the floating point result), and the operation returns
that. Then, if you wanted an int, you can cast your result.

That doesn't work if you want to consider string concatenation to be a form of
numeric addition. It isn't. There is no ideal result when adding a string to a
number, and if you do one when you meant to do the other, there is no way of
producing the data you wanted ("11") from the data you have (2).

Perl doesn't have much of a type system. But it solves the common problem of
manipulating strings when you meant to manipulate numbers, or vice versa, by
not assigning the same operators to these radically different operations, and
I think that was the correct choice, even for languages with stricter type
systems.

~~~
thaumasiotes
> This usually isn't done because integers and decimals are fundamentally very
> similar, so for addition there is a platonic correct result when you add an
> integer and a float (the floating point result)

After further consideration, I believe this is incorrect. This usually isn't
done because integers are closed under addition, subtraction, and
multiplication, so the "promote according to argument type" C behavior doesn't
lose accuracy in those cases. There obviously _is_ a platonic correct result
when you divide two integers, but it is not in general an integer, so the C
behavior introduces bugs (explaining the popularity of
divide_and_return_float() -- I don't care what types the arguments were, as
long as I get the result I'm looking for).

------
seveibar
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.

~~~
Rotareti
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.

------
gsvclass
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.

[https://bellpluscat.com/](https://bellpluscat.com/)

~~~
boundlessdreamz
This looks great. Btw why save to google drive instead of google sheets?

------
hota_mazi
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.

~~~
joevandyk
It would be a hiring point for me for someone that became quickly comfortable
and productive in a language that was unfamiliar.

------
antonkm
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.

0: [https://guide.elm-lang.org](https://guide.elm-lang.org)

------
GenghisSean
I agree with what the author is saying, but Clojure and Clojurescript are the
unpopular languages I find valuable.

------
PaulStatezny
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.

~~~
latch
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."

~~~
PaulStatezny
Perhaps my description of our CTO/situation left out too much detail. (I was
trying to be succinct.)

> It does not speak highly of your CTO

Our CTO is the kind to speak highly about. Strong technical/software
engineering skills. Willing to experiment with new/different tech. Business
minded. He agreed whole-heartedly to move forward with Elm in the first place.
This is actually our 2nd project with Elm now.

> Can’t these things sit side by side? How is re-writing code aligned with
> moving faster?

Yes; in fact, we’d always had a mix of Elm+JS.

Our product is not a Single Page App. (Very deliberate decision.) We’re only
using JS/Elm to make small parts interactive. So there was only a relatively
small amount of Elm code that was replaced.

It allows us to move faster because our designer and a couple of junior devs
on the team don’t have to struggle through learning Elm.

~~~
cpursley
> It allows us to move faster because our designer and a couple of junior devs
> on the team don’t have to struggle through learning Elm.

Elm-html is my biggest criticism of Elm. Why make the contemplating so
difficult for the non-programmers to work with? It's holding back Elm adoption
for sure.

------
cutler
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.

------
klez
> 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?

~~~
seveibar
> > 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.

~~~
masklinn
> Yes. The author probably would be equally satisfied with any robust typed
> solution (flowtype, typescript).

Neither is even remotely as robust — let alone friendly — as Elm's type
system.

~~~
boubiyeah
It's not so black and white :)

Robustness, you're absolutely right, Elm cannot be beat. But it comes at a
price: It's pretty limiting/underpowered. Typescript is very expressive these
days and you can write some very neat libs that _feel_ dynamic but are
actually fully typed, if you bother (to be fair, most people don't bother). On
the other hand, Elm usually doesn't provide many ways to do something, and you
may even have to cheat and offload some work to dirty-old-JS-land via a port
to unblock yourself or simply deliver a functionality on time.

I'm still unsure whether the freedom is worth it or whether the robustness
wins at the end of the day; it may depends on what kind of app you're writing
and how strong the team is (e.g scala has the same "issue")

------
Rotareti
_> You probably can’t use it (Elm) on the server side_

Some people mention this as a disadvantage. I think it would be cool to have a
decent DSL dedicated to just frontends.

~~~
amorphid
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 :)

"What stack are you guys using for the backend?"

"SLEW: Selenium Webkit Elm LocalStoarge"

"Wat..."

------
b0rsuk
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.

~~~
ff_
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).

HTH

~~~
tome
What a great explanation of the "state of mind" of FP!

------
masklinn
> 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.

------
ken
> "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!

~~~
woolvalley
At least you save a few hours when you look up the known bug

------
ggm
Elm is not unpopular: its just not yet common. its popular with people heading
to strongly typed FP. GHC-JS

------
_xgw
> Elm requires that you think through all the edge cases. You must consider
> and specify what will happen in every case.

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)?

~~~
masklinn
Not to the same extent, Elm:

* sum types and exhaustive pattern matching (incidentally, still not the default in GHC in 2018 because reasons[0])

* 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.

[0]
[https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck](https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck)

~~~
danharaj
GHC will coverage check any case equivalent to one you can write in Elm. You
can just write more powerful types where GHC can't tell that your case is
exhaustive so it warns about missing branches that won't ever actually be
taken. I seem to remember that perfect exhaustive checking for some
combination of Haskell extensions is undecidable.

~~~
dbpatterson
Pattern matching on GADTs will get you there, I believe.

~~~
wz1000
Its been improved a lot-
[https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp...](https://lirias.kuleuven.be/bitstream/123456789/512439/1/icfp2015.pdf)

------
anonytrary
> Even though Elm is a small language with a small community, that doesn’t
> affect the Elm experience in a noticeable way.

This conclusion was pulled out of thin air, with no justification from the
rest of the article. The title is misleading, the article is really about why
the author enjoys Elm over JavaScript...

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.

~~~
quickthrower2
> 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.

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.

~~~
anonytrary
> 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.

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?

Modern JavaScript undoubtedly towers over Elm in terms of go-to-market time
for arbitrary apps.

> you spend less time fixing bugs in feature A caused by adding feature B
> silently changing some assumptions you made in code.

This is a big problem with 2007 JavaScript and jQuery. React/Vue and other
declarative VDOM frameworks bring the Elm philosophy to the masses.

~~~
dragonwriter
> 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

That seems more of a metric for an ecosystem than a community.

~~~
anonytrary
It's presumptuous to assume "community A is smarter than community B". It's
just not even the right question to ask. Better questions to ask are "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.

"People who use Elm are smarter" is simply not actionable information. What
does it even mean? It's meaningless.

~~~
dragonwriter
> It's presumptuous to assume "community A is smarter than community B".

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.

~~~
anonytrary
You're saying the "simpler" route will attract newer devs and dilute the skill
pool.

------
leke
I tried and failed to pick up Elm. I've tried and failed to pick up a few FP
programming languages. They tend to become more and more cryptic as I progress
with them. I feel dumb, but I'm happy to stick with C like languages, like PHP
for web development.

~~~
justinhj
You can adopt some practices from fp when writing PHP. For example often
instead of iterating over an array and doing some imperative sequence of
modifications you can do a sequence of maps, filters and reduce... you replace
error prone mutable code with more a declarative approach that says what you
are doing clearly.

------
msangi
I've played with Elm a while ago and it's been a very nice experience.

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

------
karmakaze
> choose the one more people were using

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.

------
j45
Programmers who believe just one stack is the right way to do things aren't
probably the best hires long term.

While Tech evolves, being able to work with what exists and the future remains
incredibly valuable.

------
brudgers
I see that the current version is 0.18. Curious if the language has become
more stable with fewer breaking changes than when I looked at it two years
ago.

~~~
steinuil
It actually has... due to not having any major release in 2 years.

~~~
fjsolwmv
So it's abandoned?

~~~
gregdunn
No. It is still being actively developed: [https://github.com/elm-
lang/core/commits/master](https://github.com/elm-lang/core/commits/master) /
[https://github.com/elm-lang/elm-
compiler/commits/master](https://github.com/elm-lang/elm-
compiler/commits/master)

But it's been 14 months since the latest full release.

------
nivertech
Can rewrite the example from the post:

    
    
      uniqueAuthors =
                  books
                      |> List.map .authors
                      |> List.concat
                      |> Set.fromList
                      |> Set.size
    

as

    
    
      uniqueAuthors =
                  books
                      |> List.concatMap .authors
                      |> Set.fromList
                      |> Set.size

------
yawaramin
Is it true that Elm is going to remove custom operators in the next release?

------
pixelpp
Yep, we are on ELM

------
matte_black
I feel unpopular languages are best relegated for niche use cases the language
is well suited for. If you are going to build something mundane like a CRUD
App or a game, or an ERP, why wouldn't you just use some mundane blue-collar
language like Javascript or its equivalent?

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.

~~~
nogridbag
I find this line of reasoning a bit strange. I've only dabbled a bit with some
unpopular languages, but I don't think their limited popularity implies
they're only suitable for niche use cases. In fact after using some languages
(most recently Clojure) I find programming in other mundane languages like JS
a huge step backwards.

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.

~~~
matte_black
It’s not just about the language itself.

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.

~~~
annywhey
I have thought about this problem some and currently see it as an issue of
scaling thresholds.

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.

------
alphaalpha101
>I made it a hard and fast rule: if I found two technologies that could solve
a problem, I would choose the one more people were using. I didn’t want to
include an obscure graphics API and then discover that no one had ever called
set_color() followed by resize_window() (resizing is hard) and somehow those
two functions in sequence cause a segfault. I don’t want to be the guy that
finds a bug in the compiler. I just need to ship the product.

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.

------
kmicklas
Nowadays it's really easy enough to use real Haskell in the browser with
GHCJS, and FRP libraries like Reflex provide a much more complete experience
than Elm's restricted form.

------
isostatic
I used to use Elm, then I moved to Pine, then Mutt (which is still going
strong)

I guess there's only so many names in the world, and they're bound to be
reused.

~~~
Retra
This is why I'll never be a web developer. "Let's drop names! I made bridges
out of Wood.io, then I used Steel (TM), now I use Stone.js. What's fun, now
there's data in the kiddie pool!"

It feels like watching a cult of optimization function in a culture where
_measurement_ is taboo. It's absurd beyond belief.

~~~
always_good
That's fine. I don't think the ecosystem needs any more people that get their
blood pumping over some inconsequential name reuse.

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.

~~~
Retra
I'm talking about the _uselessness_ of saying "I used X, now I use Y." WHY
does one change what one uses? For reasons supposedly. But of course nobody
ever provides _reasons_. It is enough to simply drop names. Print out your
resume. Because heaven forbid anybody provide some real data that shows why
one platform is better than another.

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.

