Elm from a Business Perspective

http://www.gizra.com/content/elm-business-perspective/

by amitaibu • 10 years ago

166 75 10 years ago

the_duke5• 10 years ago

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.

tomtheelder• 10 years ago

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.

Elm certainly has a lot of boilerplate compared to Haskell, but that might not be a fair comparison as they don't really have a shared use case. Elm ends up with considerably less, in my opinion, than something like React/Redux.

rtfeldman10• 10 years ago

Elm certainly has a lot of boilerplate compared to Haskell

This is not true based on my experiences with Elm and my knowledge of Haskell.

Could you elaborate on why you are certain of this?

rtfeldman10• 10 years ago

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 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• 10 years ago

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

wyager2• 10 years ago

Our Elm code is about as DRY as our JavaScript code

Not to be flippant, but that's not saying much.

leshow4• 10 years ago

Your response to all the criticisms about boilerplate is basically sticking your fingers in your ears and going "nananana".

Elm code is boilerplate heavy, it's a trade off you guys have made to make the language simple. That's okay, but don't pretend like you didn't make the trade off.

the_duke5• 10 years ago

My major question is: how do you write reusable code without type classes?

It's not really possible, as far as I can tell.

rymohr• 10 years ago

Is that 55,000 lines of elm in a single large project or across all projects?

b1234002• 10 years ago

You definitely have access to something we don't, and that might changes how you view Elm. For example a normal Elm user can only send/receive values to/from JS via ports, and that is not scalable, e.g. you are not suppose to use ports in library. But at NoRedInk I guess you have some sort of native module wrapper (https://github.com/NoRedInk/take-home/wiki/Writing-your-firs...) that we cannot access?

dkarapetyan6• 10 years ago

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.

vvanders2• 10 years ago

Yup, and that's been one of Evan's core principals in Elm, pull out the good stuff from academia but in a way that's accessible to the lay-developer.

sotojuan3• 10 years ago

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

dkarapetyan6• 10 years ago

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.

busterarm• 10 years ago

Is it truly because they are "too hard" or is it because their current implementation in the language falls short? I was pretty sure in at least one of the cases Evan mentioned the possibility of revisiting it later.

Other languages don't make these choices and end up with things like Python's async/await.

projektfu• 10 years ago

I agree, sometimes you just compound the cleverness too much. There's lots of software that could be written in J in about 150 characters that might take much more in other languages. But I can come back to a line of J and wonder, "what was I doing there?" for a long time. Similarly, I have to stay current in Haskell for it to continue making sense. If I put it down for a few months, I come back and have to re-learn a lot of concepts each time, especially to understand other people's libraries as they adopt the next cool thing.

rifung• 10 years ago

They assume the most elegant and concise form of expression for an idea or a concept is equivalent to pragmatism.

Alternatively, perhaps many academics don't care about pragmatism and appreciate elegance and conciseness for their beauty. Admittedly I might be projecting, but part of the reason I have considered getting a PhD is to stop having to concern myself with the interests of the industry and money.

dkarapetyan6• 10 years ago

That's not what I've observed. The discussions actually turn out to be quite inflammatory when these matters are involved. Even folks that claim to have PhDs in language design consistently confuse these concepts. That's the only way I can explain all the condescending remarks when it comes to things like type systems, monads, curry-howard correspondence, etc. In fact the above article is a response to one such inflammatory and condescending blog post by a programmer who clearly values theoretical beauty and specific patterns that typeclasses enable above software engineering pragmatism. Although I can see how typeclasses help in cutting down boilerplate in this case his tone does not help make that point.

I'm no stranger to abstract and theoretical beauty. My undergrad and grad training is in pure math but I also understand that theorems and proofs don't necessarily lead to good software engineering in the large. So valuing the abstractions is great and all but using it as the ultimate arbiter of good language design is not.

chrisdone• 10 years ago

There are many points to respond to here.

1. Evan (the Elm author) has pledged to support type-classes, it's on the issue tracker, and because he believes that they are useful.

2. "The academics" is a mischaracterization. I use Haskell and PureScript professionally and share the same problem of the "Elm is Wrong" author, which is that it's impossible to do any generic programming.

3. Generic programming is important for something as simple as inserting my own data types as keys into a dictionary. So is being able to write "show x" and just have the thing showed if it has the instance of a showable class. Or to parse a nested data structure of various types from JSON.

4. Being able to use my own types as keys in a dictionary is pretty pragmatic, I think. A typical pattern in ML-style languages is to wrap types like Int in a UserId type that just wraps it and protects it from being mistakenly used with other Ints. Now try to make a dictionary of users via the UserId type. Nope.

5. "They" in this case aren't concerned with elegance or concision for the sake of it, but because the features under discussion help them do their job better, avoid mistakes, reduce maintenance cost, and that's good for business.

6. Go has non-academic, purely pragmatic problems that are orthogonal to its popularity, as does PHP or nodejs.

None of the things under discussion are difficult to implement, novel or exotic. Given that other languages like PureScript exist under the same domain and from the same family of languages, we have the luxury of holding other languages up to the same standard. In this particular point, Elm is a -1.

dkarapetyan6• 10 years ago

And yet plenty of programmers somehow manage to ship perfectly good solutions to everyday problems without "generic programming" capabilities as you define them. The author of "Elm is Wrong" might have good intentions but the tone of that post is so condescending and inflammatory that all the points being made are lost. The title alone already starts everything on the wrong foot.

Instead of sitting on such a high horse the more constructive approach is to outline the shortcomings, implement the solution, and contribute it upstream. That's not what I see though. Most of these "critical" posts end up just being that. Comparing a language that programmers use every day to ship working solutions to another one that has considerably smaller mindshare and community and then calling the more popular solution a failure because it doesn't have the feature from the more "pure and elegant" language. There is clearly a disconnect in tone and intent across all such posts.

I don't have any horses in these races. Programming languages are just tools and the religious zealotry around them does not appeal to me.

sotojuan3• 10 years ago

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• 10 years ago

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.

gilmi• 10 years ago

It's more likely that they tried Elm first and liked it so they thought they might be able to use Haskell as well.

I actually find PureScript quite practical by design and goals (for example the ffi and readable generated code).

petetnt• 10 years ago

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

skybrian• 10 years ago

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

kod2• 10 years ago

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

jlarocco• 10 years ago

My interpretation of that sentence was that it's easy for developers familiar with other languages to pick up Elm, but less easy for people with little or no experience what-so-ever.

I think he was contrasting with languages like Haskell and Scala, where even people very experienced with other languages have a hard time picking them up.

swsieber• 10 years ago

You hire experienced developers. Then you teach them Elm.

bcheung• 10 years ago

I looked around at Elm a little bit recently. I use React/Redux daily at work and have been learning Haskell on the side. When I took another pass at Elm it was extremely easy to pick up. I was able to skim through the docs super fast and start writing real code in about 15 minutes.

I noticed myself typing Haskell code a bunch of the time and wondering why it didn't work though. For me, the hardest part in Elm, and Haskell as well, is figuring out how to structure data that is composition in nature or that involve Union types that are records. I can never quite seem to get the dereferencing right.

chocolatebunny• 10 years ago

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

lgas2• 10 years ago

You were wrong.

mrkgnao• 10 years ago

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.

desireco42• 10 years ago

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.

amencarini• 10 years ago

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• 10 years ago

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.

_Codemonkeyism• 10 years ago

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• 10 years ago

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• 10 years ago

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.

Elm from a Business Perspective

Related Stories