As part of my ongoing interest in the origins of object-oriented programming and design patterns like MVC, I started to think the best way to fully grasp these things was to go back to the beginning. While there are modern Smalltalk’s like Squeak, Pharo, and Cuis that retain a lot of the old-school vibe, they’re also pretty different.

I could go into detail on how all of those options aren’t quite what I’m looking for, but since I want to write about that later, the short version for now is that I started looking into how you could emulate the original Smalltalk-80 environment on modern hardware. That ended up being incredibly easy when I found this “by the Bluebook” implementation of it on GitHub.

After a couple minutes installing, I got it running and saw this:

At first glance, this looks incredibly similar to something like the desktop of the Apple Lisa or early Mac OS. It’s easy to see why people might think that Apple sort of stole the graphical user interface from it’s rich neighbor Xerox. It’s not true, though.

The first thing is that the Smalltalk environment wasn't really an operating system the same way something like Mac OS was. It’s more like an IDE that runs on bare hardware.

For example, there’s no traditional file system. Smalltalk environments were stored as images which contained the entire state of the system. That means all of the objects, code, data, whatever, were stored as Smalltalk objects. The creators of Smalltalk wanted to make a system where the person using it was also modifying and programming the system as they used it. That’s really cool as a programming environment, but not really how we think of normal people using computers today.

There’s also no desktop, icons, or pull down menus. The whole desktop metaphor isn’t really there, because that isn’t really what it was. It’s sort of pure in an appealing way. There aren’t many different categories of things there. Windows, pop-up menus, lists. Not a lot. You can collapse different windows you’re not using and organize them on your screen, but they’re all just still windows, as opposed to also having icons for files and folders and apps and other sorts of things.

If you want to do anything with a window, you might notice there’s no controls. All window operations are done modally, meaning you click, select what you want to do, and then do that thing. You can’t even move or resize a window by clicking and dragging. There is click and drag for scrollbars and text, but not for windows. Weird.

If you wanted to move this window you would select “move”, which collapses the window and ties it to your mouse location. You then move your mouse to wherever you want the window to be and click again to place it. Oh, and you can only click, because there are no key commands in this system whatsoever.

Looking at all of this together, yeah, the Lisa and Macintosh took a lot from Xerox. But, they also added a lot. The Smalltalk environment was a revolutionary GUI, but it was still a system you would have had to have been a computer operator or something to really use. It’s not a personal computer at all.

The fact Apple was able to see the potential and then figure out all of the metaphors and affordances which needed to be there for regular humans to use a computer like this, and that they got so many of those things right by the time of the original Macintosh is pretty incredible.

#programming #apple #smalltalk #ui

I’ve been thinking this week about how I write code and the quality I want to aim for. I’ve worked some pretty big and successful projects. I’ve seen things. So with that in mind, here’s what I’ve decided. There are only two times technical debt will ever be addressed: upfront or never.

What counts as upfront?

Upfront is anytime before the feature is “done.” I’m a pretty big fan of a style I call “getting in there and making a mess.” It’s actually one of the things I really like about SwiftUI. The whole style of writing SwiftUI encourages hammering out your view to the point where things are functional and then using the refactoring tools to break things up into components. Love that.

Figuring out what your abstractions are or where the objects are hidden is super valuable. It’s also generally only going to happen upfront.

You were probably wrong

I don’t care how many Uncle Bob or Martin Fowler books you read, your architecture is probably going to suck, you’ll never really fix it, and you’re going to spend the rest of time with it hanging around your neck. It’s that feeling where writing code in a project goes from being exciting to something where you mutter under your breath before starting each day once more unto the breach.

Your clean architecture you made super DRY will be the biggest piece of technical debt you have.

Eventually the other people at your job will start telling you why it’s actually a good thing. You don’t understand! We’re not like other companies, we’re cool and quirky and we needed to abstract away every API in the framework we use and put our own crazy thing on top of it. They’re wrong. Those people have been indoctrinated.

You don’t want to be the person starts talking about rewriting everything after their first week, but after a little while if everything still feels crazy and like it makes everything suck a little more, it probably does. Trust that instinct. Or don’t! Eventually you’ll be indoctrinated too. Or you’ll quit or get fired. One of those.

You never know less than when you’re starting

This is a truism that made sense to me as soon as I heard it the first time. The worst time to make decisions is upfront. You know so little. This is a terrible to commit to anything.

Wait. Didn’t I say that the only time decisions get made is upfront? Yeah, I did. Listen, life contains a lot of contradictions. Things aren’t always going to make sense. You should get used to that.

So what should you do?

The thing you can do upfront is refactor as you go (don’t overdo it) and make it as easy possible to change your mind later. Delay, delay, delay. Just make as few decisions as you can, so when you have to do the next thing.

Since I should probably finish this with something kind of actionable, here’s my recommendations.

The biggest thing I would think about is cohesiveness and getting an ability to feel out if things are remaining that way as you try and pull out your abstractions.

Avoid heavily abstracting away the API of whatever framework you’re writing on top of as much as possible.

Never (never, never) import a complex overarching architecture into your project. Do not. Especially not one that I promise you it will be terrible. My biggest red flag is anything that starts asking you to pass calls through multiple things to do one thing. Keep things as simple as you can as long as you can.

I get that this had some contradictions in it, but as I said, life is like that sometimes. The thing with technical debt is to minimize and delay. Also, don’t listen to thought leaders.

#programming #architecture

If you enjoyed my MVC Isn’t MVC post from a couple of days ago, you might also be interested in the latest episode of the Rooftop Ruby podcast. Joel and I discuss our thoughts on the post before getting into more detail on MVC, the forgotten editor controller, and how we might be able to implement something closer to the original MVC on the web using modern technologies like morphdom and Turbo Stream broadcasts.

You can find Rooftop Ruby by searching for it in your podcast app or clicking the link above.

#programming #podcast #ruby