
Elm from a Business Perspective - amitaibu
http://www.gizra.com/content/elm-business-perspective/
======
the_duke
Well.

Summary: "I have no idea about the technical criticism or type classes, but we
use Elm and it works for us. It's easy, you are productive quickly (quicker
than with React/Angular), it prevents bugs, devs like it, and so it saves us
money."

It's nice to hear that a company is able to utilize Elm effectively.

It would be nice to know how big their 5 Elm projects "in various stages and
different scale" are to judge whether Elm in it's current form is a good fit
for larger apps. Especially since the Elm library ecosystem is still very
immature, so experience with building good, reusable libraries is not that
great.

Would also be nice to know how they deal with boilerplate, which is a big
annoyance with Elm in my opinion when you come from, eg, Haskell.

In terms of maintainability (refactoring, etc) you can't get much worse than
Javascript, so Elm will probably be a win there, regardless of a limited type
system.

As long as you don't have to build and maintain lot of required libraries
yourself, that is.

~~~
rtfeldman
> Would also be nice to know how they deal with boilerplate, which is a big
> annoyance with Elm in my opinion when you come from, eg, Haskell.

We have over 55,000 lines of Elm code in production at
[http://noredink.com](http://noredink.com) and it's now the majority of our
front-end. Students use our site to answer millions of questions per day, and
they've answered over 2 billion questions total. I think this qualifies us as
a "big project." ;)

Our Elm code is about as DRY as our JavaScript code, and adding language
features to squeeze even more DRYness out of it is way down my priority list.
When I think about ways I want Elm to improve, I'm thinking about better
support for server-side rendering and asset management (e.g. code splitting),
not wanting to add type system features.

I'm always a bit confused by "I tried Elm and disliked how it wasn't enough
like Haskell" posts. PureScript is a fine language that's already on board
with this design philosophy. Instead of lobbying for Elm to change, why not
use PureScript? There's plenty enough room in the programming world for both
languages to coexist!

~~~
renlo
The creator of Elm works for your company though [1]. Seems like your
experience is going to be a lot different from the average developer because
you can probably walk 20 steps to the designer of Elm to ask a question. I
haven't used Elm just raising the point.

[1] [https://twitter.com/czaplic](https://twitter.com/czaplic)

~~~
sotojuan
Not only does the creator of Elm work there but so do the people who know Elm
more than anyone else in the world. Literally. While it's proof Elm can work
it's not really a fair comparison for teams wanting to adopt it.

~~~
rtfeldman
That's true for me, yes, but the author of this article works at a totally
different company halfway around the world. :)

------
dkarapetyan
The academics always miss this part. They assume the most elegant and concise
form of expression for an idea or a concept is equivalent to pragmatism. When
in reality pragmatism in software engineering is mostly about making things
obvious enough at a cheap enough price point. This is why golang is so popular
even though all the academics on r/programming hate it.

~~~
sotojuan
This is interesting because Elm has been removing features that Evan considers
"too hard" and confusing for the average developer. I'd argue it's not
"academic" any more (though it might be interesting for an academic who wants
to do UI).

~~~
dkarapetyan
Yes, that is my point. I don't think Elm is "too academic". I think it strives
for pragmatism in real world engineering scenarios and that is why it gets
flak from a certain segment of the programming community. Similar to how
golang does.

------
petetnt
> But than again, Elm is not too easy. This means that almost every developer
> I see that is already involved in Elm is a seasoned developer. Getting
> experienced developers on board means that they are immediately productive,
> which means we gain more per hour.

Not really seeing this as a strong point. It feels like the same mindset that
drove me away from Scala (and many others [0]!). Sure, it might be good for
the company in short term, but what happens when you run out of experienced
Elm developers? At least Elm fairs fairly better with having usable samples on
their own (clean) site.

[0] [https://groups.google.com/forum/#!topic/scala-
internals/r2Gn...](https://groups.google.com/forum/#!topic/scala-
internals/r2GnzCFc3TY)

~~~
skybrian
I don't think he's saying that Elm is actually hard to learn (like Scala or
Haskell).

~~~
kod
Yup, Elm isn't actually hard to learn. Nor is Scala (I had a team of people
productive with it in under 2 weeks, with no significant prior FP experience).

------
amencarini
This typeclasses discussion reminds me a lot of complaints about Go's lack of
generics. Even without this "glaring shortcoming" Go became the de facto
winner in the ops space, by staying a simple language with a smaller learning
surface. Elm could be walking down the same route.

Personally I find composability under The Elm Architecture more of an issue
than pure language abstractions.

~~~
pitaj
> Go became the de facto winner in the ops space

Can you explain what you mean by this and possibly provide a source? I'd like
to know how the different languages / platforms compare.

------
mrkgnao
I don't get how having type classes makes the learning curve steeper. It's not
like the mere existence of type classes means you have to start writing your
own and doing functional dependencies and all that.

For a beginner, it just means being able to write filter instead of
List.filter or whatever.

------
_Codemonkeyism
There is no business perspective to programming languages. Stop kidding
yourself to explain your favorite tool of the week as good for business.

Successful companies have used plain st* languages like PHP and Java,
thousands of companies that use the tool of the week go bust. There is no
correlation (perhaps you should not use Assembler or COBOL for web
development)

If there is any then companies that use the tool of the week do too many
rewrites instead of focusing on delivering business value, the correlation is
negative if any.

~~~
yakshaving_jgt
As someone who worked at a large software company that suffered huge losses
because of 1) client data loss caused by using unsophisticated tools and
strategies and 2) accounting errors caused by a lack of type-safety: I
disagree.

------
bloomca
I always think that usage of such technologies can be only in some cases –
mostly for small companies, which are not sure that this product will be
maintained more than few years. Like, it is not that bad to use it in
startups, in some small projects, or if you have pretty strong and
enthusiastic team with a lot passion, which are ready to dive into new cool
technology. Moreover, in the short term it can be even more beneficial,
because you can attract even better developers, who like cutting edge stuff.

But the problem is what if this product will be maintained throughout years?
Then to support it, you have definitely hire much more skilled engineer than
for the same in stable JS framework. I completely understand about types,
strict rules how to write Elm code, etc, but there are literally no guarantees
that it will be the same after some time, that new developers will pick it up
quickly, and, if you decide to rewrite it much later, there is a big chance
that you'd have to rewrite it completely (this applies for JS too, but there
are quite a lot of success stories of gradual integration of new framework).

To summarize, I don't think it is bad, it just doesn't scale and creates big
technical debt, so you'd pay for it later; though it is a great chance to
attract very skillfull and passionate developers – so, it is all about risk.

------
sotojuan
I'm guessing pragmatism and practicality is why they went with Elm over
PureScript? If their backend is in Haskell then it seems like they have devs
who know it well enough to use PS.

~~~
bbcbasic
From my limited experience, I would say PureScript sounds more practical. You
can choose your own UI engine, and has additional language features that are
useful like typeclasses. It also compiles without needing a runtime baked in
to the output.

When you hit a wall you can probably work around it in Purescript whereas I
feel you are too sandboxed in with Elm and you'd have to start patching your
Elm source to get around it.

------
desireco42
I really love this Elm drama. We get to discuss Elm a lot, talk about it,
think about it, keep it in out minds. I don't like negativity, but it is good
to popularize language, to let people know about it.

------
chocolatebunny
I thought this was going to be about the email client:
[https://en.wikipedia.org/wiki/Elm_(email_client)](https://en.wikipedia.org/wiki/Elm_\(email_client\))

~~~
lgas
You were wrong.

