Elm from a Business Perspective
gizra.com
Elm from a Business Perspective
1–10 of 79 posts
Re: Elm from a Business Perspective
#2Well.
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.
Re: Elm from a Business Perspective
#3The 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.
Re: Elm from a Business Perspective
#4The 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.
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.
Re: Elm from a Business Perspective
#5Well. 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 judg…
> 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.
Re: Elm from a Business Perspective
#6The 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.
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).
Re: Elm from a Business Perspective
#7I'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.
Re: Elm from a Business Perspective
#8Well. 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 judg…
> 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!
Re: Elm from a Business Perspective
#9Well. 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 judg…
> 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.
> 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?
Re: Elm from a Business Perspective
#10> 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...