This is an episode of Thoughts on Functional Programming, a podcast by Eric Normand.
How is Smalltalk so small? Four rewrites.
[00:00:00] How was Smalltalk so small?
[00:00:07] Hello, my name is Eric Normand and this is my podcast. You are welcome.
[00:00:18] Ever since I learned about Smalltalk. I have been intrigued especially by the size of it. In the early history of Smalltalk, Alan Kay says that Smalltalk 76 had 50 classes and 180 pages of source code. That was it. That included everything. The GUI. All the applications that came with it such as animation. The painting application [00:01:00] music sound synthesis. Memory management, all the OS stuff. 180 pages.
[00:01:10] 50 classes. To me, it's amazing. Surprising. Because, if you look at any system out there, () besides Smalltalk, that gets complete functionality, it is huge. I mean, 50 classes is the size of a small Java library, at the least. I've seen some libraries that have 200, 500 classes. And they somehow built a whole operating system, with GUI, and word processing, printing, everything, from [00:02:00] 50 classes.
[00:02:03] I've always wondered how they did that and if there's some lesson we can learn from it so that our systems are not so big and complicated.
[00:02:22] So I think there's a lot of reasons, but one reason has recently, it kind of made a connection there. And I think it's one of the main reasons. And so I want to bring it up. And talk about it right now.
[00:02:40] So the real, the answer that I think is one of the main reasons is that Smalltalk was actually rewritten several times from scratch by the same team who were exploring how to build this thing.[00:03:00]
[00:03:01] There was an original version which was very naively written in 71. And then from the learnings of that, they made a Smalltalk 72. And then there was a kind of Smalltalk 74. And then finally a Smalltalk 76. So about every two years, they started over, porting all the lessons they learned. And how to make it faster and more elegant. They brought all that over each time.
[00:03:40] And I think that's it. I think if, if you were to rewrite your, you know, the company you work for, if you were going to rewrite their software every two years, you would achieve something like that, where you could learn a lot. Build it into the next [00:04:00] version. And find an elegance.
[00:04:05] There's parallels of this with other disciplines. I'll just tell a little story. I think it'll help.
[00:04:14] When I was in college. You know, we, we had to study poetry and literature. And I'd been studying that in high school and everything. And I always had the idea that some people could write a perfect novel or a perfect poem, basically on the first try. Yeah. They might make some typos, or just misspellings grammatical mistakes, and then they go back and correct them. But the large structure of the thing was mostly due to inspiration and genius.
[00:04:53] That's what I thought. And some people had it and some people didn't. And [00:05:00] we recognize the people and the works that, that had that.
[00:05:07] And when I was in college, I went to a course where the teacher handed out. And we were, we were analyzing poetry. And. To help us understand how the poem was constructed, it was written. The work that went into the poem. She handed out a photocopy of the manuscript or one of the manuscripts of one of the drafts of this poem. It was handwritten because it was like 19th century poetry. And it was, it was not the last draft. You could, you could see that. The poem was different from the final version.
[00:05:59] But there were so [00:06:00] many marks in the margins from the author writing in suggested changes. I'll move this here. You know, change this word. It's not strong enough. Like just all over the page. And she told us that this was the 10th revision. That all the other revisions were like that too.
[00:06:26] And my mind was blown.
[00:06:31] Because no one had ever presented that to me before. I was just always told, read this book, read this poem. And they were always, you know, pretty decent. And I just thought that they just came out of people's heads, like, fully formed.
[00:06:55] And the reason I bring that story up is because I think we do the [00:07:00] same in software. We expect to be able to write software, like a good piece of software, the first time.
[00:07:14] There's never time in the schedule for going back. Now there might be time to rework a little piece, like you're working on a feature. And you kind of get it working. And then you say, well, I got to fix some things I left out, some corner cases, and you know, I'll go back and fix it. And maybe I have a better idea for how to do it since I'm done now.
[00:07:40] But you don't go back and write the whole thing. Rewrite it. You don't go back in, say, "oh, this other piece that I kind of had to look at. I have a better idea for how to write this." We don't, we don't do that enough. And. [00:08:00]
[00:08:01] Well, the success of Smalltalk in what it's achieved– it's not popular. No. But it did spawn object oriented programming. It spawned the gooey. It made mouse and WYSIWYG editing. You know, there's countless things. Desktop publishing. All of that stuff came out of Smalltalk and that team.
[00:08:35] And. So it does have success. And so that success comes from, in large part, this rewrite –the rewriting process. The make a prototype, see how it works, learn something from it. If you learn how to make it better. Do it. Make it better? [00:09:00] Start again.
[00:09:02] So that's one of the things I've been thinking about. That we don't iterate enough in the large picture. Might iterate on small features. But we don't go back and rebuild things again. I think that if we did, we would have much better software.
[00:09:24] All right. My name is Eric Normand. Thank you for listening. And as always. Rock on!