There was a browser that worked on Squeak 3, Whisker, that had some of these attributes. I used it up until it became unsupported. It took a little getting used to as its primary orientation was horizontal, but in the age of widescreen monitors that is an advantage.
Yes, Whisker is exactly what came to mind for me as well.
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.
I fondly remember the browser in F-script Anywhere was fantastic for debugging your own apps and reverse engineering other people's.
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.
Also it'd be nice to have something that is more spatial. A famous memory technique is remembering where things are in space[1], but I've never seen a code browser that works spatially. (I have no idea how to actually do this.)
Imo, the problem with the 4-pane browsers are:
1 - The left-most 'package' pane is a flat list. And there are 10K + classes in e.g. Pharo. There are 900+ (!) packages in Pharo, in the pane, so its not easy to scroll through. This is solved 'manually' by have a hierarchical naming of packages. I think this pane should just have tree view.
2 - When developing an app, you may be working on classes in multiple packages. You want to have 'project' view with a simple way of switching between them, without having 10+ system browser windows open, like shown in the article. Dolphin Smalltalk has implemented this concept.
Shameless plug: SmallJS (https://small-js.org) has these too..
Extending that, an outliner can be a great way to deal with this stuff. The problem becomes the self-referential nature of OO systems. Outliners are good when you get to the method of interest, but then you have the problem of browsing senders and implementers.
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.
While I agree that the package column has room for improvement, some of the 'largesse' can be handled by the search field at the bottom of it, and once you get to doing something serious you could set up your own image and ditch a lot or most of the standard distribution.
I think I'd prefer a pane view over a tree view because the higher levels retain their scroll position even as I browse beneath. Is there a similar UX possible for tree views?
You can run any smalltalk code from workspace-style frames in the Inspector, Workspace, Explorer, Finder and Debugger. You can edit classes and methods in these windows, as well as spawn Browsers as desired. I'm not sure what the integration points are that are lacking. That's not to say there can't be a better way, but I cannot see the point he is making.
I couldn’t discern a point either. Having been a smalltalk programmer the only thing I really miss is the exceptions and the way they could be intercepted and a value injected back into the execution flow.
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.
Do Smalltalk IDEs really not have the concept of different "views" of the code? The 4-pane hiearchical view is clearly valuable, but why would it need to be "surpassed" rather than complemented by other views that are available when needed and can be switched to or even shown alongside the traditional view?
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.
They have many views, the trouble is the proliferation of these views as you go through the code. You browse to a class and method, then you want to see the senders, and so you open that, and then see the implementors of a method a sender calls, and so on.
when i was in uni in 2014 i learned that smalltalk became obsolete, later i went to industry to see that no one use smalltalk(or prolog) and yet on this site ppl bringing up smalltalk every single month, why is that i wonder
Yeah there's a difference between being popular and influential. Smalltalk is influential without being all that popular.
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.
A lot of systems are obsolete, in the sense that you cannot find work in them. Nonetheless, people use them to prototype ideas that will eventually find their way into industry. Is Haskell obsolete? Not exactly, but it's hard to find real-world projects that use it. Concepts developed in Haskell get imported into other systems.
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.
The Potsdam university (near Berlin, Germany) and Hasno Platner Instute [1] has been actively teaching and researching Squeak Smalltalk for decades. Same in Buenos Aires and several other places. Science papers every month for 5 decades, under many names besides Smalltalk. Weekly online conferences, presentations.
People like the language - I like it though I have only written a few bits and bobs in it. They also like Fortran, Prolog, and (dare I say it) Haskell, and many others that don't appear here so often. Just because a language is not this week's hotness (looking at you Rust) does not make it "obsolete".
Likely because whilst it didn't work out commercially, the ideas smalltalk, prolog and other more esoteric languages (forth, apl) focus on are themselves very interesting.
In what way, obsolete? There is quite a bit of worthwhile research done in Smalltalk-related languages and some corporations are quite successful in building on such languages.
It's not dominant in the way of Wordpress but also not insignificant.
There was a browser that worked on Squeak 3, Whisker, that had some of these attributes. I used it up until it became unsupported. It took a little getting used to as its primary orientation was horizontal, but in the age of widescreen monitors that is an advantage.
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...
Yes, Whisker is exactly what came to mind for me as well.
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.
I fondly remember the browser in F-script Anywhere was fantastic for debugging your own apps and reverse engineering other people's.
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.
https://www.chromium.org/developers/f-script-anywhere/
From a conceptual point of view, browsing code is like browsing a fractal. Tools must take this into account.
Who remembers the Occam folding editor (1983)? This was the first time I saw this kind of outline-based navigation for code: https://www.transputer.net/tn/03/tn03.html#x1-30002
Also it'd be nice to have something that is more spatial. A famous memory technique is remembering where things are in space[1], but I've never seen a code browser that works spatially. (I have no idea how to actually do this.)
[1] https://en.wikipedia.org/wiki/Method_of_loci
Imo, the problem with the 4-pane browsers are: 1 - The left-most 'package' pane is a flat list. And there are 10K + classes in e.g. Pharo. There are 900+ (!) packages in Pharo, in the pane, so its not easy to scroll through. This is solved 'manually' by have a hierarchical naming of packages. I think this pane should just have tree view. 2 - When developing an app, you may be working on classes in multiple packages. You want to have 'project' view with a simple way of switching between them, without having 10+ system browser windows open, like shown in the article. Dolphin Smalltalk has implemented this concept. Shameless plug: SmallJS (https://small-js.org) has these too..
Extending that, an outliner can be a great way to deal with this stuff. The problem becomes the self-referential nature of OO systems. Outliners are good when you get to the method of interest, but then you have the problem of browsing senders and implementers.
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.
While I agree that the package column has room for improvement, some of the 'largesse' can be handled by the search field at the bottom of it, and once you get to doing something serious you could set up your own image and ditch a lot or most of the standard distribution.
I think I'd prefer a pane view over a tree view because the higher levels retain their scroll position even as I browse beneath. Is there a similar UX possible for tree views?
You can run any smalltalk code from workspace-style frames in the Inspector, Workspace, Explorer, Finder and Debugger. You can edit classes and methods in these windows, as well as spawn Browsers as desired. I'm not sure what the integration points are that are lacking. That's not to say there can't be a better way, but I cannot see the point he is making.
I couldn’t discern a point either. Having been a smalltalk programmer the only thing I really miss is the exceptions and the way they could be intercepted and a value injected back into the execution flow.
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.
Do Smalltalk IDEs really not have the concept of different "views" of the code? The 4-pane hiearchical view is clearly valuable, but why would it need to be "surpassed" rather than complemented by other views that are available when needed and can be switched to or even shown alongside the traditional view?
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.
They have many views, the trouble is the proliferation of these views as you go through the code. You browse to a class and method, then you want to see the senders, and so you open that, and then see the implementors of a method a sender calls, and so on.
https://blog.lorenzano.eu/content/images/2026/01/Pasted-imag...
when i was in uni in 2014 i learned that smalltalk became obsolete, later i went to industry to see that no one use smalltalk(or prolog) and yet on this site ppl bringing up smalltalk every single month, why is that i wonder
Yeah there's a difference between being popular and influential. Smalltalk is influential without being all that popular.
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.
A lot of systems are obsolete, in the sense that you cannot find work in them. Nonetheless, people use them to prototype ideas that will eventually find their way into industry. Is Haskell obsolete? Not exactly, but it's hard to find real-world projects that use it. Concepts developed in Haskell get imported into other systems.
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.
The Potsdam university (near Berlin, Germany) and Hasno Platner Instute [1] has been actively teaching and researching Squeak Smalltalk for decades. Same in Buenos Aires and several other places. Science papers every month for 5 decades, under many names besides Smalltalk. Weekly online conferences, presentations.
https://www.hpi.uni-potsdam.de/hirschfeld/projects/index.htm...
People like the language - I like it though I have only written a few bits and bobs in it. They also like Fortran, Prolog, and (dare I say it) Haskell, and many others that don't appear here so often. Just because a language is not this week's hotness (looking at you Rust) does not make it "obsolete".
Likely because whilst it didn't work out commercially, the ideas smalltalk, prolog and other more esoteric languages (forth, apl) focus on are themselves very interesting.
In what way, obsolete? There is quite a bit of worthwhile research done in Smalltalk-related languages and some corporations are quite successful in building on such languages.
It's not dominant in the way of Wordpress but also not insignificant.