Sean Werkema's Blog

Thick accent. “Hello, my name is Ree-chard Lee and I am calling from Department of Computer Support.”

Me: “Er, I didn’t really hear that, who are you again?”

“I’m sorry. My name is Ree-chard Lee, and I am calling from Department of Computer Support about your computer. Are you seeing white dialog box on your computer?”

Pause.

Me: “Er, for the record, you do know you just called a computer scientist with thirty years’ experience, right?”

Click.

I probably should’ve kept him on the phone longer just to waste his time, but dang, it’s been a long day, and I’m too tired even for that kind of fun.

But maybe if he calls back…

I swear there is no part of the Node ecosystem that isn’t a flaming tire fire. Does anyone ever design anything before implementing it anymore?

Try this example:

• NPM is a package manager. But you can’t install packages from local source (i.e., on this computer) in older versions because NPM was only really designed to work with a single remote repository. (New versions at least let you add multiple remote repositories, as a somewhat hacky extension.)
• There’s a workaround hack feature called npm link that lets you set up a symbolic link — a pointer — to a local package. It doesn’t work like a standard link command, so you’ll have some relearning to do if you want to use it.
• But nevermind that learning, because npm link has no shortage of problems and bugs and failings and workarounds and workarounds to the workarounds. Also, it has disastrous data-destroying bugs on Windows.
• But nevermind the bugs, because it’s not compatible with the normal npm install commands anyway, so the one use case you’ll have for it — installing packages from a local directory to make sure your design works — isn’t really usable with it anyway.

None of that would have been an issue with a little more advance thinking and a little less advance typing. Two small design changes early on — (1) allow multiple repositories to be listed in .npmrc and check them in order, and (2) allow the file:// protocol to point to a local directory of .zip files or tarballs as a repository — would have been enough to obviate all of this. NPM scopes, link, yalc, lerna, and a dozen other things built on top of the initial bad design would have been completely unnecessary.

But, no, can’t spend time on that! — you gotta move fast, be first, break things, change the paradigm, own the market, declare your IPO, and retire like a king. Never, ever design or plan anything, because that takes too long! Just shove something barely-passable out the door, and if enough people use it, make a slightly better layer on top to hide the roughest parts, and then if that gets used, another on top of that, and after enough layers, you might not even notice the sand you built on. After all, when you’re changing the world, who cares if anything actually works?

The construction foreman stood and stared at the plans. “Are you sure this is what you want?”

“Of course it is!” said Mary. “Why, what’s wrong with it?”

“Well — I’m not sure we can build this exactly as described,” he said.

“How do you mean?”

“Well, describe it again.”

Mary cleared her throat. “Look, so these are the plans for the house. They’re simple and as plain as day. Two floors, three or four bedrooms, two bathrooms, and maybe a third, and a living room, and a kitchen. The kitchen definitely needs all stainless-steel appliances, and it should be painted blue.”

The construction foreman wrinkled his brow. “What about the roof?”

“What do you mean?”

“You want a roof, right? There’s no roof in any of the plans.”

“Well, of course we want a roof,” said Mary. “I don’t want it to rain in the living room.”

“But the living room is only one storey tall.”

“What?” said Mary irritably.

“Nevermind. What kind of style and slope do you want the roof to have?”

“We don’t need to bother with those details now,” said Mary. “Just get to building. We need the house built soon.”

The construction foreman grimaced again and looked over at the architect, who had been quiet up until now. “Have you got a slope for the roof?”

“Well, they’d like it to have dormers,” he said sheepishly.

“Oh, yes, dormers!” said Mary brightly. “I forgot about those. Definitely dormers. And a chimney. The roof should have a nice line when viewed from a distance.”

“All right,” said the foreman. “I suppose we’re getting somewhere. There seem to be some erased lines here at, oh, about — I’d call that thirty degrees. Is thirty degrees what you want?”

“What does that mean?” said Mary.

“The angle of the roof.”

“I don’t care, you’re the construction expert. Don’t bother me with little details. Just build whatever you need to build, but make sure the kitchen is gray.”

“Gray? I thought you said blue.”

“Oh, well, we focus-grouped it among the family, and I forgot that gray was more popular. I rather liked the blue myself. But definitely gray. Also we need space for three refrigerators.”

The foreman blinked and looked up from the plans. “You need three refrigerators?”

“I sometimes throw parties,” said Mary, “and I need enough room to store a tray of vegetables and ranch dip.”

The foreman swallowed hard and turned back to the plans, letting the subject drop.

“What’s this?” he said, pointing at a box in the middle of the paper.

“Oh, that’s the guest house,” said Mary.

“A guest house? Inside your regular house?”

“Well, you don’t want the guests to have to go outside to visit us, now, do you?”

The foreman shook his head.

He took a deep breath. “So you want this house, as drawn, with a thirty-degree roof, three bedrooms — “

” — or four,” chimed in Mary.

” — or four,” repeated the foreman, “three bathrooms — “

” — unless they’re expensive, and then we only want two,” said Mary.

” — and a gray kitchen with three stainless steel refrigerators in it,” he finished.

“Exactly,” said Mary. “How long do you think it will take?”

“Well, it usually takes my team three to six months to build a house, depending on size and configuration and how long it takes to get the permits — “

“Oh, that won’t do!” said Mary. “We need it in six weeks for the start of spring! We’ve already invited everyone over!”

“Uh, I suppose I could hire more people, but — “

“And I need you to do it for half the cost you quoted,” said Mary. “We just had our budget cut yesterday. Something about Bill partying in the Maldives. Seems he bought a few too many drinks for some of his clients, and we’re now a few hundred thousand dollars short. But if this project goes well and comes in on time, we’ll buy all your workers pizza.”

The foreman looked down at his phone. “Sure. Six weeks for half the money, probably a roof, some rooms of uncertain number but not too many or two few, and definitely three stainless steel refrigerators.”

“Exactly!” said Mary brightly. “And if you have any more questions, please don’t hesitate to send me an e-mail. I can’t always answer, but I promise I’ll at least think about reading your messages. When do you think you can start work?”

The foreman skimmed through his calendar. “It looks like I have an opening — yes. How does the thirty-second of Octember sound?”

How is Sharknado vs. Polar Bear Vortex not yet a thing? It’s a 1000% awful idea! You know darned well we would all tune in with huge bowls of popcorn to watch the insanity of Bruce Campbell using a bazooka that shoots tornados of hyperevolved laser sharks to attack a swirling vortex of flying mutant polar bears. Come on, Syfy, the script writes itself!

The first person to create some kind of lint tool for Smile will be shot.

I understand the “desire” to have code be “uniform,” but linting tools, automatic-formatting tools, and other such ilk are an excellent example of not understanding the problem.

There is no “one correct formatting” for source code — in any language! — and style guides just make the problem worse by making you think there is such a thing. The goal of well-written source code is to communicate to other human beings — not the computer — the intent of the program. But intent is art, not science, and like all arts, it’s subjective. And la forme suit le fond, as the French say.

For comparison, the A.P. style guide, or the Chicago Manual of Style, tell you how you should write prose. They also disagree on really basic things. Should you use an Oxford comma, or not? Should you or shouldn’t you use contractions? Are sentence fragments ever acceptable? How long a sentence or paragraph is too long? Or too short?

e e cummings wrote his famous poetry — and his name — in all lowercase. Jesus wept is both the shortest and one of the most meaningful sentences in the Bible. Shakespeare’s most famous sonnet’s first four lines are loaded with what modern authors would consider spelling errors and a sentence fragment — “Shall I compare thee to a Summers day? / Thou art more louely and more temperate: / Rough windes to fhake the darling buds of Maie, / And Sommers leafe hath all to fhort a date…“

The point is that language changes, and language is mutable. You can freely alter it to serve your purposes. Writers always have, and always will.

The same is true in programming languages, especially in a language like Smile that is itself designed to be mutated. There’s no one correct way to write anything — in any programming language. There are only ways that are easier to read than other ways — and what’s easy and pleasant to read depends heavily on your experience and background. To many inexperienced programmers, the formatting below is confusing and heresy; to more experienced programmers, this code reads like art:

switch (field.Kind) {
    case FieldKind_Primary:    flags |= INITIALIZED | BOLD;    break;
    case FieldKind_Secondary:  flags |= INITIALIZED;           break;
    case FieldKind_Disabled:   flags |= INITIALIZED | GRAYED;  break;
    case FieldKind_Password:   flags |= HIDDEN_TEXT;           break;
    case FieldKind_Hidden:                                     break;
    default:                   throw new InvalidFieldError(field.Name);
}

I could show you what that looks like after it has been through a code-formatter that would put those switch cases on three lines each, with fixed indentation, but I’m not a big fan of ruining beautiful things. Which is exactly what a linter or code-formatter would do to it.

In literature, as in any of the arts, there are always exceptions to every rule. There are reasons not just to break every rule but to beat it to a brutal, bloody death with heavy bats and spiked shoes. Of course, to break the rules properly, you must first know them, and know when to apply them, and when not to. But Picasso didn’t become famous by painting still-lifes of fruit. Monet didn’t become famous through photographic precision of people’s faces. O’Keefe didn’t become famous by painting romantic landscapes. The best artists know the rules, and then break them, establishing new rules that are then broken by the next generation.

Well-designed source code in the 1960s left extra un-punched holes on the punch card between words and numbers to make it easier to fix errors. Well-designed source code in the 1970s put broken while statements inside switch cases because of how much more efficiently it ran. Well-designed source code in the 1980s made sure to write char *x, not char* x, because of how dangerous the “more obvious” form could be. Fashions change, as requirements change, and as preferences change. Today’s “perfect formatting” is tomorrow’s “ugly punch cards.”

So stop with the linters. Stop with the code formatters. Stop making prescriptive software that exists just to enforce your opinion. Because the best code is art, and the best art could care less about your rules.