My Argument for "Why Elm" please review before I present to my company

[Gage Peterson]

I've been wanting to pitch (again) Elm as an alternative to Angular / React + Redux. These are my arguments, please leave some comments:

https://gist.github.com/justgage/7de5a2f9e639aec9436aad882fc90446 

[Charlie Koster]

Who is your target audience? Are you pitching to a CTO? A Scrum Master? A Project Manager? A handful of Developers?

Why did the last pitch get turned down.

Those are two important pieces of information to have if you want this one to be successful.

[Gage Peterson]

Good questions. The target audience would basically be some lead developers (although I would like to write one for product people too).

I think the last time they figured that adding a whole new language was too extreme and you could "get the same thing" or at least get close with React + Redux. 

[Ossi Hanhinen]

Nice write-up! As it happens, I recently wrote a collection of thoughts in the same vein, and just published it as a blog post:
http://ohanhi.github.io/why-and-when-of-choosing-elm.html

[Rupert Smith]

On Wednesday, January 11, 2017 at 5:56:16 PM UTC, Gage Peterson wrote:

I've been wanting to pitch (again) Elm as an alternative to Angular / React + Redux. These are my arguments, please leave some comments:

https://gist.github.com/justgage/7de5a2f9e639aec9436aad882fc90446 

 "a lot easier to understand in elm because ility is enforced for all data structures."

What does the work "ility" mean?

[Rupert Smith]

On Wednesday, January 11, 2017 at 8:28:01 PM UTC, Ossi Hanhinen wrote:

Nice write-up! As it happens, I recently wrote a collection of thoughts in the same vein, and just published it as a blog post:
http://ohanhi.github.io/why-and-when-of-choosing-elm.html

"What is Elm a poor fit for

Mostly static pages (e.g. news websites)

Sites that need server-side rendering"

Admittedly I am going out on a limb here but... now that I've started doing it I think Elm is great for rendering static content server-side. I recently walked away from handlebars templates and won't be looking back. One possibly major issue I am having with it is that running Elm under Nashorn on Java 8 is slow as - but I could add some caching or run it under Node, so its not a blocker for me.

Server-side rendering is not officially supported but elm-server-side-renderer does the job.

[Matthew Griffith]

Nice!

A few notes if you want them:)

Tests are VASTLY easier to write in elm because we have a guarantee of same-arguments-same-result, which means each piece can be tested independently.  And, like you said, you'll need fewer tests because of the type system.

You can have higher confidence in other people's code that's written in elm because of the basic guarantees that elm provides out of the box.   I.e. I have more confidence in the code of a beginner elm dev than in a mid level javascript dev because of the protections the language brings.  It's much harder for a beginner to shoot themselves in the foot in any meaningful way with Elm than with Javascript.  Similarly, having a standard code formatter and a standard architecture means that your beginners will likely start out writing code that is fast, well formatted, extensible, and easier to understand.

(small typo: Symantec -> semantic)

[Charlie Koster]

I'll recommend a different approach based on my personal experience with trying to sell Elm.

Rather than showing a laundry list of technical points, start off with something that really grabs their attention and gives them a "holy crap" moment.

Two examples: I gave a meetup talk early last year and demo'd the time travel debugger. You can literally hear someone say "woah" at 4:43. A few months ago I demo'd my own "replayable production bugs" feature to my company. It's harder to both hear and see the reaction in the crowd but you'll have to take my word that many devs and non-devs alike immediately understood at least some of Elm's potential.

So my advice, hook em' with a "wow" demonstration and know the talking technical talking points for diving in deeper in follow up conversations.

[Jeff Schomay]

I've successfully made this pitch.  Here were the key points for me:

- no run-time exceptions

- much quicker with much smaller file size

- demo debugger

- simple to add a little elm to existing code wo/ changing workflow/ci process

That got a trial run which sold all our developers, who in turn sold our manager.

[joseph ni]

Reading through your points, it seems that this is not a pitch but rather a list of highly emotional responses to their concerns the first time around.

Alot of your statements are unqualified and comes across to me as being weakly backed up or unnecessary personal beliefs:
"Elm adds far more value than redux such as a type system"

"Elm has been around for about 5 years which is far more stable than the JS libraries you would use to replace it"
"People want to work in Elm and would probably would attract more rather than less."

"breaking changes to the language they have been pretty minimal and have always been large improvements"

"It has basically no cruft."

"I feel the pros far outweigh the cons"

"you'll have less leaving because the front end makes them happy than sob into their pillow."   <--- is there something else going on here?

I personally wouldn't go ahead with your second pitch and would strongly suggest thinking along the lines of what Charlie said about creating a demo/prototype to show these strong points rather than repeating them in words.
In fact, that's what I'm doing right now with a work project and with a hobby project ( https://github.com/mordrax/cotwelm ). It's to both showcase Elm and my skills as a hireable Elm developer. :)

[Rupert Smith]

On Thursday, January 12, 2017 at 10:54:12 PM UTC, joseph ni wrote:

Reading through your points, it seems that this is not a pitch but rather a list of highly emotional responses to their concerns the first time around.

Yeah, just shove anyone out of the way who disagrees that statically typed functional languages are the Zeitgeist. This isn't about pussyfooting around with a feature-by-feature analysis. Its about shoving the message that a new and better way of doing things has arrived into the face of anyone who will listen. This revolution needs your emations as much as your cleverness. :-P 

Very happy to hear that your proposal has been accepted.

[Rupert Smith]

On Friday, January 13, 2017 at 12:49:57 PM UTC, Rupert Smith wrote:

On Thursday, January 12, 2017 at 10:54:12 PM UTC, joseph ni wrote:

arrived into the face of anyone who will listen. This revolution needs your emations as much as your cleverness. :-P 

s/emations/emotions/ - if we moved this discussion list to Discourse I'd be able to correct all my typos.

[Gage Peterson]

Looking back I can totally see that this is the wrong approach. I'll be thinking about what project or presentation I can use in lieu of this write up.

--
You received this message because you are subscribed to a topic in the Google Groups "Elm Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elm-discuss/iWgOsuYapSA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josh Adams]

On Wednesday, January 11, 2017 at 11:56:16 AM UTC-6, Gage Peterson wrote:

I've been wanting to pitch (again) Elm as an alternative to Angular / React + Redux. These are my arguments, please leave some comments:

I think a smaller, more-focused pitch might go over better, but I think you got there at the end. I'll share my laundry list and then some anec-data if that helps. (NOTE: I haven't had to convince anyone else on tech choices in 10 years so I might be less-helpful than I might think - but I've had other people have to pitch me, and I know what would have worked).

Laundry List

• Immutability removes a huge class of bugs.
• (like one that almost cost me $300k...more on that later)
• The type system removes another. (I find it useful to point out that people that think "Java" when they think about strong typing need to abandon that and look at Elm's type system fresh)
• Are you sure you have no code paths that pass invalid arguments to a function? Really?
• A ton of 'tests' that you write are probably a crappy substitute for types, presently.
• Ever had "undefined is not a function" or "no such method #foo on NilObject"? Never again.
• React+Redux gets you pretty close. But...
• "JavaScript fatigue" basically started here.
• Flux? Alt? Redux? Reflux? MobX?
• Oh sometimes redux-devtools have issues rendering Immutable.js structures? (this is fixed...but it's broken twice after being fixed the first time too)
• More goes here but...
• Are you going to use Flow? (you should, if you go that route)
• The stuff above each takes time to learn properly. Many on the order of a week or more, and I tend to learn quickly. Takes longer if you review five alternatives and now you have all of their APIs in your head convincing you that they're what you should type instead of the thing you ended up picking.
• Elm takes less than a month to learn extremely well.
• You aren't likely to actually build good abstractions on top of something that makes it hard. Dynamically typed things make it hard.
• I loved Dynamic typing. My email address has "rubyist" in it. I was die-hard that it wasn't a big deal. I was very wrong and wasted a lot of time being bull-headed.

Anecdata

The ~$300K bug

We had a mutable object that represented an important one-off report that could either perform a no-op reporting of the action it was going to take or actually take the action (this was for a pre-paid debit card platform with 400K users). The action in question was "give a bunch of people money on debit cards in a way that we can't perform a takesies-backsies."

It was extremely well tested and survived code review with myself and another senior dev that was no slouch. The ops dev for the night ran it in an entirely reasonable way. But he re-used the object that he'd run the dry-run on to actually execute the action. This was an unanticipated use case.

It added all the disbursements into an array once, to print the report. It proceeded to add them all to the array again, to distribute the money. When used fresh each time, of course, this didn't happen. It never occurred to us that someone would use it that way because its intended use was well-documented. We distributed over $300k more than we were supposed to. People immediately pulled the cash off the cards.

This is the closest I ever came to using my Errors and Omissions insurance. The client was able to recover the money over the following 2 months, but it severely impacted cash flow.

This was ultimately my fault. I was the CTO of the consultancy and should have anticipated this error in my review. Life is better when you don't have to constantly be worried about that class of errors.

The idiot junior dev

(NOTE: I don't think junior devs are idiots in general, by any stretch. But trust me. This guy was stupid. However, the error wasn't his fault.)

We had a service object that accepted a hash (Ruby) and made an API call. Pretty straightforward mapping thing. It had been in production with no issues for a year or so. A new junior dev was hired by the client and pushed, directly to master (we had rules but not systems to avoid this), a fairly innocuous change to it. Unfortunately, he used the passed-in hash (which wasn't frozen because I'm an idiot - this is where it was my fault, but I didn't anticipate the client hiring this kid) as a kind of 'scratch paper' and overrode an attribute that I needed later, introducing an extremely subtle, rarely-induced bug that cost us a ton of money and time (but not $300k+).

Immutability means you don't have to stress about him either!