Wiki description: https://wiki.squeak.org/squeak/1993
Archive of its homepage. Has an image of the browser in use. https://web.archive.org/web/20070228113449/http://www.mindsp...
I don't currently use Smalltalk, most of my code is now written (and read) in vscode. The means available for showing the context around the code under consideration (splitting and resizing panes, hunting through lists of tabs, scrolling around) feel pretty crude by comparison.
But, let's contrast it to Java, which pretty much is in the same boat as a modern Smalltalk. A very large core system of packages, classes, and methods. Wrapped in a spider web of dependencies. And, granted, I've been working with Java a long time, and this is all quite comfortable to me. But at the same time, it doesn't suffer the issues that the Smalltalk browser presents.
Consider, regarding the parent point, the entirety of the JDK is not typically presented in the modern IDE. It's just back there. There's no real estate committed to it. There's your project (typically), with its classes.
I use NetBeans, so I have a project view of packages and classes, I have code tabs of individual classes, and a contextual method navigator within a class.
Its routine to potentially have a tab explosion, in contrast to a window explosion when exploring code. But when I do that, all I get is the code window, not the entire project or context of the class.
That is, in my code, I can click on, say, an ArrayList method, and jump to the JDK source code for the method within the ArrayList. I don't get its entire package hierarchy, I get its method list (uncatagorized, but alphabetical) while viewing the code file. So, the impact of viewing a new method is minimal -- it's just a new tab.
But as a benefit, I get to see not only the method I'm interested in, but I get to see the context of the code around the method. When I code, I don't write methods in a vacuum. I organize my code somewhat around aspect of the logic of the class. So, if there's a method that does one thing, chances are that the methods around it are doing similar or related things, or part of the logic of whats going on. Proximity in the source file tells part of the story not captured at the method level.
Sure, I can click around, in the navigator, in the IDE directly to visit other methods, but I can also scroll about, have the breadth of the class as a canvas and gather the ebb and flow of the logic within it. This is stark contrast to the ST "tiny" method browser.
I can also search globally within the source methods rather than just method signatures, while still having access to call trees and references and many of the other wonders of the ST browser.
put one browser on your code and the other on your tests
Java is used in many places. Smalltalk is not. The whole comparison falls short due to this already. TIOBE ranks Java #4 right now, which is not too bad, even though TIOBE also sucks.
Still, there's nothing worse than a Smalltalk without a class category list. Smalltalk/MT, for example, just had a class hierarchy browser, and the category class member variable was left blank. I found it very hard to know where to start looking for behavior.
Smalltalk is how computing should have been: an open book. I hope that one day we can rediscover that magic, we surely have the computing power available to do so.
Disclaimer: never met or spoken or worked with him
I don't remember there being any way to collapse and re-expand this context so that it could persist yet be out of the way when you didn't want to look at it.
...but the infinite desktop is still missing there.
It’s important to realize that in ed you were usually editing a file you had already printed beforehand. If you only wanted to fix a few small things in a multi-page listing, you simply entered the corrections in ed on the relevant lines, added something here and there, and at the same time you would just write the simple minor fixes directly into the printout by hand-without having to tediously retype everything.
You had the files on paper, which is a very pleasant and ergonomic medium for reading. You can literally surround yourself with it, cover your desk, and easily move your eyes between dozens of functions. If you learn to keep order and stay oriented in that mountain of paper, you can be very effective.
Moreover, from an ergonomic point of view you wouldn’t be doing badly at all. Printed paper in natural light is definitely easier on the eyes than low-refresh-rate screens in the years that followed. Paper lets you quickly add notes, sketch a little graph, basically work in a very natural way - one people were used to back then from the moment they first held a crayon.
Most of the time a programmer isn’t writing code but reading it. In that respect, people back then may actually have had it better than we do today. When it did come to writing, the only truly more complicated part was essentially making corrections. The history of everything you’d done was right there on paper. I don’t want to idealize the way they worked back then, but all of this explains how they were able to work effectively even with such primitive tools.
That only works if your printouts aren’t too long, and contain the majority of the logic in your programs.
Today, the latter rarely is the case. Maybe, we need a way to print code with t selected documentation of called functions added?
That ‘selected’ would be a tricky problem, though. What I need to understand the code may not be what you need, or what I need a month from now.
Same with Emacs. You bring a whole toolset for each buffer (major and minor modes). And then you got to editing. Like imenu for automatically finding interesting places like functions, structure,… declarations, outline mode that use regex to provide an outline tree that you can then edit, view-mode that adapt the keybinds for scrolling,…
Abstractions have to be earned.
Abstractions have to be exposed so they can be either questioned or exuding their properly valued and time tested structural ontology.
In 2015 I wrote how a cool Smalltalk IDE in a web browser would be:
https://blog.sebastiansastre.co/posts/the-smalltalk-ide-i-wi...
> Why has the four-pane browser survived so long without being replaced by newer (possibly better) metaphors?
Smalltalk died though. The ideas may persist but smalltalk is a dead language really.
I’m sure we could code up a class browser for any language that offers introspection like C# but I don’t see the point any more when programming has reverted to functional styles or chunks of lambda expressions.
If that kind of thing doesn't exist (and the article sure sounds like that), then yes, it appears the smalltalk ecosystem really has fallen decades behind the state of the art in the IDE area.
You can browse within it, and also spawn off other kinds of browsers from it.
And these browsers are extensible with others. As someone new to Smalltalk, I was pretty easily able to add a visual class hierarchy browser into this environment:
https://www.neilvandyke.org/smalltalk-chg/
Half the things we know or think about in HCI, the people at PARC figured out before we were born, and sometimes before the hardware to test it existed.
https://blog.lorenzano.eu/content/images/2026/01/Pasted-imag...
I suspect that's largely because most smalltalk implementations don't store code in git. "A smalltalk" is more like a Linux distro than a phone app. It's almost like the main purpose of a smalltalk is to build more smalltalks. It's a good way for developers to build a deep, powerful tool for other developers, but it's a less good way to build user experiences targeted at non-programmers, who are going to want to have a bunch of different apps to use not a bunch of different operating systems to use.
Good economics for the classroom; bad economics for the real world. Then and now, though, a great way to play with novel ideas in programming languages.
https://www.hpi.uni-potsdam.de/hirschfeld/projects/index.htm...
Systems are only truly obsolete when there is no real reason to use them. PL/1 is obsolete. It's hard to find even legacy code using it, and nobody would use it for experimentation.
Just saw your post to the Common Lisp reddit.
Consider also posting to the larger Lisp reddit.