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!
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
