Thursday, September 22, 2016

Elm Is The New Rails

About 10 or 11 years ago, a friend asked me if I'd heard of Rails. She had a developer building something for her, and he wanted to build it in Rails. She asked me to look into it; she figured anything that could get the job done was fine with her, but she didn't know if Rails could get the job done. So I looked into it, and I was like, "holy shit." Then I told her, "yeah, that can get the job done," and aside from some dabbling in Node and front-end work, and a whole bunch of bootstrapped entrepenurial whatnot around information products, Rails has pretty much been my career ever since.

That last part's been true for a lot of people. I don't know if Elm will see the same massive success, but when I compare what it felt like to discover Elm vs. what it felt like to discover Rails, I see a lot of similarities. First, both Elm and Rails represent very curated experiences with a very strong emphasis on being enjoyable to use. Second, that curation involved deep thinking, in each case, about the best way for the framework to do its job, which thinking came in each case to idiosyncratic and (in my opinion) superior conclusions.

Third, they both showed up in very similar environments. Rails had two main sources of competition: an over-ambitious, platform-y technology which was painfully boring and tedious to work with, and an overly simple alternative which encouraged you to write very hacky code once your project grew beyond a certain size. Angular 2 would be the equivalent to J2EE in this analogy, and obviously React, as a view-only technology which intermeshes presentation markup with application logic, would be the PHP.

OK, I apologize. I know Angular intermeshes markup and logic too, and I know both have insane ambitions of being platform-agnostic mega-/meta-frameworks, and indeed, Elm itself has you write your HTML as Elm functions, so it too blurs the line between logic and markup somewhat. But I needed a J2EE and a PHP, and Angular is definitely the over-engineered one.

Only time will tell if these two analogies hold, and indeed I'm a lot more confident in the Angular snark than the React snark. I could be wrong about both. I built a toy recently with React and enjoyed it a lot (but then again, PHP makes a ton of sense for really simple barely-dynamic pages). And certainly, Evan Czaplicki doesn't seem like a DHH to me at all, although I could totally see him as a Matz.

Still, one of the weirdest aspects of Rails's success has been a particular contrast: everybody steals ideas and vocabularies from Rails, but virtually no other project has said, "yes, Rails is right, programmer happiness should be a top priority." You can find migrations, REPLs, code generation, and "REST means CRUD" in every language now, but you won't find "programmer happiness is the top priority" in many other places.

I think this is partly because a lot of the old blog posts where DHH praised and imitated Kathy Sierra have vanished, so nobody remembers that making users happy is about making them awesome, and a framework which makes its users awesome is doing what a framework should do. It could be that the "look at me, I'm awesome!" vibe of early Rails devs was hard to take, so nobody did any serious thinking about it. It might even just be because it's hard for anybody to take DHH seriously in the first place when he has such an egregious straw man problem.

However, one way or another, DHH told everybody that programmer happiness is the secret to Rails's success, and everybody gathered around wondering "what's the secret to Rails's success?" and virtually nobody ever considered the possibility that when DHH said it was programmer happiness, he was telling the truth. And this confused me, and it continued to confuse me for a full decade, and then I found Elm.

I have absolutely no idea if Elm's focus on being fun to use comes from any awareness of Rails at all. But Elm's designed to be fun to use, and, as a consequence, it's fun to use. What a shock! And as it turns out, everything that makes Elm fun to use also makes it a good framework. It has a clean mental model. It doesn't throw mysterious, aggravating runtime errors. Its compiler errors are easy to understand, easy to correct, friendly, and so polite that its British users assume the language itself is British. It's fast as hell in development and production — pull up a Chrome timeline sometime and compare an Elm "hello world" with the festival of document.write that is an Om "hello world" — and it's basically awesome.

I think my new rule of thumb should be that all of my code should be fun to use. It worked for Rails, and it's working for Elm too.

Thursday, September 15, 2016

God What An Awful Directory Name

One aggravation I have with the asset pipeline, and it's not the worst by far, is that app/assets/javascripts is just a terrible directory name.

First, if you're building anything remotely modern, your JavaScript code isn't really an asset, it's an app.

Second, "JavaScripts" is not appropriate here. These are not scripts written in Java. The only meaning the term "JavaScripts" could ever actually have in the English language is if you are talking about varieties or dialects of JavaScript. For instance, ES6 is a much more usable JavaScript than the JavaScript of 1997, but both these JavaScripts have some really weird edge cases, especially around numbers and numeric comparison.

If the directory were called app/assets/javascript-scripts, that would still be stupid, but it would at least have a meaning.

Unless you are, for some insane reason, storing ES7, ES6, ES5, and/or several other entire dialects of JavaScript in app/assets/javascripts, that plural is just wrong.

Update: and I forgot the most obvious reason!

Wednesday, July 13, 2016

Online Trolling Is A Mainstream Thing

This is a music video about misogynistic online trolls. The album this video comes from hit number 1 on the "alternative" Billboard chart. (Both the song and the album appear to have made it into the top 40, for those of you old enough to remember what that was.)

This is a late-night talk show where the last Republican nominee for President reads "mean tweets" (aka online trolling) including one written by the next Republican nominee.

What a time to be alive.

Tuesday, July 12, 2016

How Robotics Will Transform Hollywood

Before CGI, aka 3D animation and modeling, special effects meant practical effects: building little spaceships out of plywood, putting the camera really close to them to make them seem huge, and then setting them on fire. Or a giant, malfunctioning, mechanical shark. Filmmakers like Christopher Nolan still favor practical effects over CGI, because they give the actors something real to react to.

But 3D and CGI are in every movie, because they give filmmakers the ability to depict just about anything, and they've advanced to a degree where they look incredible. So they're not going anywhere.

But I think practical effects are going to come back in a huge way. Today, you don't have to build the little spaceship out of plywood. You can fill it full of tiny servos and sensors. You can make little walking tanks. You can do almost anything.

Animatronic effects and simple machines have been a part of filmmaking for a long time, but that whole process is probably about to become a lot more effective. So there's probably going to be a little practical effects renaissance in about 5 to 10 years, which will make movies feel more real again. It's probably starting already.

Thursday, June 30, 2016

Noise Engineering Loquelic Iteritas: Rough Exploration Video

I made another Eurorack video. Caveat: I mostly made it in my pajamas, and you have to be logged in to YouTube to see it, because there's swearing. It's a rough tour of a new oscillator I got, namely the Loquelic Iteritas from Noise Engineering.

TL;DR: aggro bass dream machine.

Thursday, June 23, 2016

Two Videos Explaining Eurorack Patches Built Around The Mutable Instruments Elements

I made a couple beginner-friendly videos to explain my own Eurorack patches, partly as a vlogger thing, partly so I would be able to re-create them later myself, and partly to improve my general skill at making Eurorack patches. Kind of like detailed note-taking, and kind of like the idea that teaching is the best way to learn.

The first one is a housey, proggy sound:

The second is a sound I think of as "Typhoon Kitten."

Both videos are mostly built around the Mutable Instruments Elements, a powerful little synthesizer which only sometimes does what I want it to.

Tuesday, June 21, 2016

How I Understand Donald Trump

The best way to understand Donald Trump, in my opinion, is to think about Ron Paul's problems in 2011.

Why did the media smirk whenever Ron Paul tried to take the stage, even though the crowd went wild?

Ever since the Southern Strategy was established, Republicans have been promising their constituencies Trumps and delivering something else instead. There was no way on earth this three-card monte trick was going to last forever.

Yet in 2011, Ron Paul won huge crowds, and when the media spoke of him, they smirked. They didn't see the impending doom of the Southern Strategy. They saw a joke. Why?

Because the media class controlled what could be discussed, and they ruled Paul out. He campaigned without their approval, and they thought that was hilarious. Television had controlled politics since the Nixon-Kennedy debates, and the idea that you could win without media support was ridiculous to the people who ran the media.

Those debates were a pivotal moment in American politics; for the first time, if you wanted to be President, you had to look good on television. But in 2008, Obama built a campaign machine which centered around social media. And today, Trump's success has more to do with social media, especially Twitter, than it has to do with television.

Trump's not a fluke; he's the second Ron Paul in a row. Both these candidates did better with social media than with traditional media, but one came before a major shift in the relative importance of these two categories of media, and the other one came after it. So, while TV and print could smirk about social media in 2011, it's Trump doing the smirking today, because social media now matters more than TV and print.

Or at least, it was Trump doing the smirking a few weeks ago. His campaign's not doing as well against Clinton as it did against other Republicans. I won't go any deeper into that, because I don't want to claim to predict the future.

But if you want to understand Trump, he's a lot less mysterious if you look at him as continuining what Ron Paul began, within his party, and continuining what Obama began, in terms of campaign tactics.

(Whether he knows he's continuining either of those things is another question. I doubt Trump's ego could handle acknowledging the reality that he's picked up on the tactics a black man pioneered, and that he's only able to pick them up today because they've become a lot simpler to use, and more readily available to less educated and intelligent people like himself. Hell, even putting aside his racism, his ego's probably so fragile that he couldn't even deal with the idea that he's doing something that Ron Paul did first.)

Update: I also like this theory.

Friday, June 10, 2016

Dudes Must Band Together To Prevent Human Cloning

A few times, when I lived in San Francisco, gay dudes checked me out and hit on me when I was walking down the street minding my own damn business.

Recently on Twitter, a rando explained my own joke to me.

Based on these two experiences, I am absolutely certain that the moment science locks down human cloning and makes it a viable, dependable technique, women are going to massacre every dude on earth and kill us all.

If you're a dude, please understand that our only hope of survival is to prevent human cloning.

Tuesday, May 3, 2016

Amazon: The Next (Next Microsoft)?

Tech has this weird, generational semi-imperialism, where a particular company seizes control of the platform everybody else needs and becomes "king" for a while, before fading into relative irrelevance when a new platform emerges. IBM and Microsoft both fit this pattern perfectly. Google and Facebook have arguably been contenders in more recent decades, except neither was really ever essential to developers.

Google search rankings have been crucial to businesses, and Facebook's got a somewhat frightening control over social interactions — and the business implications of that were enough to terrify Google executives into acts of pitiful desperation — but neither Google nor Facebook was ever actually essential to developers. They have both been arguably essential to businesses, but attempts to paint Google or Facebook as hegemonic tyrants in the 1980s/1990s Microsoft style don't really work, in my opinion, because while businesses do have an equivalent level of dependence on these platforms, developers don't.

So look at Amazon in that light. How many startups run on AWS? In 2015, AWS made Amazon almost as much as Amazon's retail operation did, and in 2016, Jeff Bezos expects it to hit $10B (about three times as much as Amazon retail).

Right now, being able to run all your infrastructure on Amazon is kind of awesome, although not without challenges. But if the last decade or two have disproved (or at least provided a counterexample to) this idea that tech's history consists mostly of cycles of platform domination, the 2020s might be a strong example in favor of the theory, with Amazon in control.

Tuesday, April 19, 2016

Rails, RSpec, Poems, And Synthesizers

I've been re-watching Gary Bernhardt's classic series of screencasts Destroy All Software, in part because I'm eagerly anticipating the new edition, Destroy All Software: Civil War. In this edition, David Heinemeier Hansson will face down Bruce Wayne, and everybody will have to pick a side. I'm really looking forward to it. I think, also, that Luke turns out to be his own cousin, or something, but a) I think that's just a rumor, and b) if you know, don't tell me, because spoilers.

Anyway, there's a screencast which covers conflicts between the existing "rules" of object-oriented programming, specifically, inherent conflict between Tell Don't Ask and the Single Responsibility Principle. I'm into this topic, because my book Rails As She Is Spoke is mostly about similar conflicts.

One interesting thing that comes up in this screencast, mostly in passing, is that Rails enthusiastically embraces and encourages Law of Demeter violations. In fact, if you build Rails apps, you've probably seen a line of code like this now and then:

@user.friends.logged_in.where(:last_login < 4.days.ago)

This code subordinates the Law of Demeter to the Rule Of Thumb That Rails Code Should Look Like Cool Sentences. Lots of other things in Rails reveal this same prioritization, if you look at them closely. In fact, when Mr. Hansson wrote a blog post about concerns, he explicitly stated it:
It’s true that [avoiding additional query objects in complex model interactions] will lead to a proliferation of methods on some objects, but that has never bothered me. I care about how I interact with my code base through the source.
It's extremely tempting to laugh this off. "Wow, this guy prefers pretty sentences to considering the Law of Demeter, what a n00b." And I am definitely not going to endorse that blog post, or the idea of concerns, across the board. But I also think laughing off DHH's priorities here would be a mistake.

Consider RSpec, for the sake of comparison. RSpec prioritizes a sentence-y style of code, which tries hard to look like English, over just about any other consideration, as far as I can tell. And RSpec has an Uncanny Valley problem. This code has both an Uncanny Valley problem, and a Law of Demeter problem:


By contrast, it's very interesting that Rails only has Law of Demeter problems, when it does the same kind of thing. The Rails valley is not uncanny at all. When it tries to make Ruby look like English, it stops a little earlier than RSpec does, acknowledging the fakeness and the Ruby-ness of the "English," and in so doing, you end up with code which is English-like enough to be incredibly convenient and easy to read, but not so overly-trying-to-be-English that you can't reason about its API and are forced to memorize everything instead.

Rails encourages specific Demeter violations as a set of special, privileged pathways through unrelated objects and/or objects which exist only to serve as those pathways in the first place. And it works. I'm not saying Rails is perfect — if you've read my book, or indeed ever read anything I've written about Rails since about 2011, then you know I don't think that — but I don't think its cavalier attitude towards the Law of Demeter would even make it onto a top ten list of things I want to change about Rails.

Of course, the whole point of that screencast I mentioned, which points out that the "rules" of OOP conflict with each other from time to time, is that these rules are not rules at all, but merely guidelines. So it's no surprise that they involve tradeoffs. What is surprising is that I don't think there's any real name for what Rails chooses to prioritize over Demeter, except perhaps "readability."

Frankly, it's moments like this when I feel privileged to have studied the liberal arts in college, and where I feel sorry for programmers who studied computer science instead, because there's no terminology for this in the world of computer science at all. Any vocabulary we could bring to bear on this topic would be from the worlds of literature, poetry, and/or language. I know there's a widespread prejudice against the liberal arts in many corners of the tech industry, where things like literature and poetry are viewed as imprecisely defined, arbitrary, or "made up," but every one of those criticisms applies to the Law of Demeter. It's not really a law. It's just some shit that somebody made up. Give credit to the poets for this much: nobody ever pretended that the formal constraints for haikus or sonnets are anything but arbitrary.

Let's look again at our two lines of example code:

@user.should_receive(:foo).with(:bar).and_return(:baz).once # no
@user.friends.logged_in.where(:last_login < 4.days.ago) # ok

If you were to write one of these lines of code, it would feel like you were writing in English. The other line could function as an English sentence if you changed the punctuation. But what's interesting is that these two statements don't apply to the same line.

This one feels harder to write, yet it functions almost perfectly as English:

# "user should receive foo, with bar, and return baz, once"

Writing this one feels as natural as writing in English, but falls apart when treated as English:

@user.friends.logged_in.where(:last_login < 4.days.ago)
# "user friends logged in where last login less than four days ago"

These are extremely subjective judgements, and you might not agree with them. Maybe the RSpec code isn't such a good example. What I find difficult about RSpec is remembering fiddly differences like should_receive vs. should have_selector. I'm never sure when RSpec's should wants a space and when it wants an underscore. Why is it should have_selector, and not should_have_selector? Why is it should_receive, and not should receive? RSpec has two ways to connect should to a verb, and there doesn't seem to be any consistent reason for choosing one or the other.

In actual English grammar, there are consistent connections between words, whereas with RSpec, you kind of just have to remember which of several possible linkage principles the API chose to use at any given moment. To be fair, English is a notoriously idiosyncratic language full of inconsistencies and corner cases, so writing RSpec might actually feel like writing English if English isn't your first language. But English is my first language, so for me, writing RSpec brings forth a disoriented sensation that writing English does not.

(Tangent: because I'm a first-generation American, and England is "the old country" for me, English is not only my first language, but my second language as well.)

Anyway, the question of why Rails feels more natural to me than RSpec — and I really think it's not just me, but quite a few people — remains unanswered.

There is another way to approach this. This is an analog synthesizer:

These machines have a type of thing called envelopes.

Briefly, an envelope is way to control an aspect of the synthesizer. This synth has one envelope for controlling its filter, and another for controlling its amp (or volume). It doesn't matter right now what filters and amps are, just that there are two dedicated banks of sliders for controlling them. Likewise, it doesn't matter how envelopes work, but you should understand that there are four controls: Attack, Decay, Sustain, and Release.

Now look at this synthesizer:

The envelope controls are much more compact:

This synthesizer again has one envelope for its filter, and another for its amp. But this synthesizer wants you to use the same single knob not only for each envelope, but even for each of the four parameters on each envelope. Where the other machine had eight sliders, this machine has one knob. You press the Attack button in the Filter row to make the knob control the filter attack. You press the Release button in the Volume row (as pictured) to make the knob control the amp release. (And so on.)

Do hardware engineers have a word for this? If they do, my bad, because I don't know what it would be. User experience designers have a related word — affordances, which is what all these controls are — but I don't know if they have a word for when you dedicate affordances on a per-function basis, vs. when you decide to double up (or octuple up). It is, again, a tradeoff, and as far as I can tell, it's a tradeoff without a name.

But it's the same basic tradeoff that Rails and RSpec make when they pretend to be the English language, and somehow, Rails gets this tradeoff right, while RSpec gets it wrong. When I need to recall a Rails API which mimics English, it's easy; when I need to recall an RSpec API which mimics English, there's a greater risk of stumbling. With should_receive vs. should have_selector, the relationship between the API's affordances and its actions is out of balance. RSpec here has the opposite problem from the synthesizer with one knob for every envelope parameter. Here, RSpec's got an extra affordance — using an underscore vs. using a space — which has no semantic significance, but still takes up developer attention. It's a control that does nothing, but which you have to set correctly in order for the other controls to not suddenly break. Rails, by contrast, has a nice balance between affordances and actions in its APIs.