Sean Werkema's Blog

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.

Since there’s no longer Twitter in my life, you get to hear my tiny rants here instead.

The most useful script you’ll ever have when working with NodeJS:

rm -rf node_modules
npm cache clear --force
rm -f package-lock.json
echo crossing fingers...
npm install

Save this as npm-is-effed-again.sh. Run as often as needed. (And it’s often needed.)

I wrote a long and oddly soothing piece about how burnout became the millennial condition: https://t.co/hGHgNX3uSE

— Anne Helen Petersen (@annehelen) January 5, 2019

Here’s my thread explaining why I left, and why I just might not bother ever going back:

If @AnneHelen's essay is right — and I think it is — I've been fighting #burnout. Dang. I had it once before, and recognized it for what it was, and changed my life to be rid of it, and it came back.

— Error 307C undefined is not undefined (@sean_of_w) January 6, 2019

Something that I haven’t really explained well is why I believe Smile code is shorter, better, and simpler than nearly everything else out there.  I’ve talked about it at a high level, and I’ve shown “Hello, World” and simple test programs, which are nice, but none of that really gives you the feel of coding in Smile.

So here’s an example of some unit tests written using a simple unit-test suite that I’ll be including out-of-the-box with the Smile distro.  Writing unit tests is a little closer to the day-to-day activities of Real Programmers, and it helps you to see a little better what code in a language feels like:

#include "testing"

tests for the arithmetic unit {

    it should add small numbers {
        x = 5 + 7
        assert x == 12
    }

    check the boundary conditions {
        x = 5 + 7
        assert x != 0 (adding positive numbers should never produce zero)
    }
}

Continue reading “Syntax matters”

Downfall. 2236, Pogo Publishing, Lagos, Nigeria. 577 pages.

It goes without saying that the collapse of America was the defining event of the 21^st century.

Historian Warren Keeler’s new book, Downfall, explores the collapse of the world’s most technologically-advanced empire in breathtaking scope, and while it leaves some to be desired — I found the scant mention of the Harriman Riots disappointing — it is still among the most comprehensive analyses of the collapse to date.

The core outline — that poorly-educated, rural Americans were taken in by a fast-talking real-estate mogul who became not only America’s last President but its first Dictator, ultimately driving the nation to despotism and ruin — this story is well-known to any schoolchild today.  Still, despite all of the analyses of the rise and eventual fall of the Trump Dynasty, few attempt to trace its origins farther back than Donald Trump’s rise to power in 2016.  Keeler’s book fares excellently in this time period, chronicling not only the rot in the Democratic Comradeship that ultimately led to the failed candidacy of Hillary Crookton, but also the weaknesses in the Strong Republicans For Strength Party that allowed Trump to rise in the first place.

Keeler also excellently covers the pivotal first three years of Trump, long before he became Grand Commander.  I had not realized, for example, that the retirement of a single Justice from the American Ultimate Court — then called the Supreme Court, apparently — was what ultimately led that Court to rule in favor of abolishing term limits on the American President.  It is also interesting to wonder what might have happened had the election of 2018 swung the other way:  Perhaps the American Legislature might have been a better check on Trump’s ambitions; with just one more Democratic vote to tip the balance toward his opposition, he might not have been able to run roughshod over the other two branches of government.

But, of course, history did not play out that way.  The Legislature quickly became Trump’s rubber stamp; laws were passed to silence all information except Foxnews and Trumpitter; and by the time Democratic leaders began to disappear at the hands of ICE, his private army, even his original supporters were too terrified to stop him.  The Battle of New York City — then simply called “quieting the insurgent rats” — was the final fight between Trump’s Blackshirts and the Hashtag Resistance, and it put an end to any attempt to stop his seizure of power.  The collapse of the American economy during the subsequent Deportations — his epithet used to describe the murder of his opposition and critics — was almost inevitable.

In the wake of Donald Trump’s reign, and the failed dictatorship of his son, nearly a hundred million people died.  And, of course, America is ruined, its landscape now badly irradiated:  Trump’s decision to use his nuclear weapons on California is rightly denounced not just today but was even denounced by some of his supporters at the time.  Yet Keeler does not attempt to place judgment on either Trump or his family:  True to his trade, he is a dispassionate historian, chronicling the facts as accurately as he can from the remaining records, many of which were lost in the collapse of the internet.  I would have liked stronger opinions from Keeler on the worst of Trump’s atrocities, but I understand his desire to remain objective.

Ultimately, of course, without the collapse of America, the rise of the African Empire would have been unlikely.  And while our continent is strong and wise and capable, there are still technological and artistic wonders that America’s world knew that we are yet rediscovering.  One cannot help but wonder what the alternative history of Earth might have been — had the American people put up a little more of a fight against the greatest despot and mass-murderer mankind has ever known.

— Jax M’nungo

I’ve been coding for a lot of years — next year, it’ll have been 35 years since I wrote my first line of code — and I’ve worked on a lot of projects over those years.  Some of those projects have wildly succeeded, and some have absolutely bombed.  (I’d like to think my lifetime average is positive, though.)  Through all that work, I learned a lot of lessons the hard way, and today, after a discussion at work, I decided I’d share with the younger crowd some of the most important programming lessons I’ve ever learned.  The lessons below are hard-won, and they cycle through my head on every line of code I write, even to this day:

Continue reading “Lessons from an Old Coder”

I spent all day today dealing with too many different someone elses’ bad code, and it’s left me feeling irritable and grumpy and very elitist. I swear, most people really shouldn’t be allowed to program, ever.

So are you one of the good “programmers”? Are you actually solving more problems than you create? Take my “easy” ten-question pop quiz and find out!

1. Which book is more important: Design Patterns or Antipatterns? Why?
2. When you design any component — a class, an interface, a function, a module, a networked API, anything, in any programming language, in any environment — what’s the single most important consideration?
3. What is the real purpose of comments?
4. How would you go about trying to demonstrate that a piece of code must be or can’t possibly be the source of a bug? How about without unit tests? How about without strong typing either?
5. Name at least three problems you’ve solved in the past using metaprogramming — that didn’t involve using your language’s version of “generic types” as the solution.
6. Name at least five unrelated programming languages in which you’d be comfortable immediately switching to for your next programming project.
7. It’s been said that design patterns are really just patches for defects in the programming language’s design. Is this true? Does it apply to all languages in all circumstances? Why or why not?
8. For your most favorite programming language, list all the features and patterns that should usually be avoided most of the time.
9. When is copy+paste actually the right technique for code reuse?
10. What’s the single most important quality that all good code has, no matter what project, year, or programming language it was written in?

Answered them all? Great! Go back to coding, safe in the knowledge that your code probably doesn’t completely suck. Probably.

Stuck? Can’t answer some of them? Sorry. They’re not intended to be easy questions you can just pop the answers to right out of college. Keep working on that experience level and expertise, and maybe someday you’ll be able to answer the rest.

(But if you’re really stuck, here’s a hint: Go look up Harold Abelson’s most famous quote, and see if that teaches you anything more about the right answers.)

I just realized I haven’t posted anything really serious about Smile in all of 2017.  I’m definitely overdue for a status update!  There have been over 360 commits in it this year, more than one commit per day (on average).

Continue reading “Wow, where have I been?”