I set out to create a better text repl experience for Common Lisp couple of months ago, but was inspired by the pharo interface and built something much larger: https://atgreen.github.io/icl/
I use it all the time.
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.
While the article makes good points, I simply find it amazing that a programming user interface (with small changes) has been around for so long: I think kit was in 1983 that Xerox Special Information Systems provided me with a free 1 month Smalltalk license for my Xerox 1108 Lisp Machine. That Smalltalk interface is amazingly similar to Pharo Smalltalk which I still occasionally use.
I worked as a Smalltalk developer for a few years, and it spoiled to such an extent that I’ve tried to make an extension for IntelliJ to replicate the browser for Java development. Maybe I should revive that project, actually…
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..
Whenever I tried dabbling in Smalltalk, I would feel constrained by the system in terms of raw real estate. I never cared to view the system through the narrow slit of the method code editor. I would suffer the explosion of windows. All of it was off putting to me, and I never pushed through it to work with a project long enough in order for it to be comfortable.
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.
Totally agree the only viewing methods in isolation,
is less valuable than viewing the methods around it "for free".
Indeed the methods in my classes are caryfully ordered,
to keep ones that are used together on the source together.
(And SmallJS is file based)
> 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.
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.
Rather than a fixed 4-pane browser, a potential solution is to use something like the macOS finder's "Column" view, where each layer of the hierarchy produces a new pane, as many as you need to drill down to the particular thing you're looking for.
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.
cuis smalltalk has multiple "browsers". One browser allows you to restrict your view of the system (the leftmost pane) to a specific package (eg: the one you're actively creating right now).
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?
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.
Longtime HN user morphle, who commented elsewhere in this thread, has researched and designed chips and hardware for that purpose (edit: for scaling that form of computing). He has been trying to find funds and partners to bring them to market.
Disclaimer: never met or spoken or worked with him
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.)
Self's environment was a panning desktop where you would inspect an object's slots and as you kept opening things, they would exist in some space nearby. You could, in theory, keep these things open and have a much more spatial feeling about the system.
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.
The paper printouts on the table are a kind of simple spatial browser. Thanks to this, we have UNIX (at least it explains how they were able to create anything at all with just a teletype back then).
To add to this, a quote from an article about the editor ed:
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.
> 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.
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.
This is why a lot of people like Vim.When you can target precisely where you want to edit, it becomes effortless instead of being a chore. With windows (panes), you can easily arrange buffer (contents of files mostly) spatially like you would on a desk. Even with vi (which lacks windows), you can make do with marks (bookmarks on lines)
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,…
I use the pdf view of Literate Programming projects uploaded to my Kindle Scribe in a similar fashion --- at need I've augmented this by switching to my MacBook for coding and using my Samsung Galaxy Book 3 Pro 360 as a second pdf view (which never fails to cause comment from my spouse).
Don't remember that, but I do remember the one for Gupta SQLWindows. I had a discussion about with its designer on reddit some years back, and he admitted it was a horrible mistake. Programs are text, folding is not a great way to represent text.
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.
The best feature of the Smalltalk browser is that there's no such thing as a 'file' in the organization of the code.
I get that we have to have files and directories as operating systems use that concept,
but it really doesn't make sense to be constrained organize code that way.
In particular,
tying visibility and module organization to "what file is in what directory" introduces an abstraction useless for source code.
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.
Historically, Smalltalk has many browsers (views). This System Browser is one of many browsers, and the most busy-looking.
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:
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.
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.
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.
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.
mostly because everything relevant we have today was built on smalltalk ideas and it still executed them better in the 70s than modern languages do today.
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.
I set out to create a better text repl experience for Common Lisp couple of months ago, but was inspired by the pharo interface and built something much larger: https://atgreen.github.io/icl/ I use it all the time.
The browser inspector stuff looks very interesting, gotta check this out!
Very cool!
Just saw your post to the Common Lisp reddit.
Consider also posting to the larger Lisp reddit.
this is great! i was on a common lisp exploration a few months ago and mostly got stuck wishing i had smalltalk style tooling
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.
While the article makes good points, I simply find it amazing that a programming user interface (with small changes) has been around for so long: I think kit was in 1983 that Xerox Special Information Systems provided me with a free 1 month Smalltalk license for my Xerox 1108 Lisp Machine. That Smalltalk interface is amazingly similar to Pharo Smalltalk which I still occasionally use.
Eclipse, due to its evolution from Visual Age set of IDEs, coded in Smalltalk, also keeps a code browser view for Java that is like the Smalltalk one.
VB6 also had a COM API browser thing that was remarkably similar to a Smalltalk browser.
its also the only view that makes writing java tolerable
I worked as a Smalltalk developer for a few years, and it spoiled to such an extent that I’ve tried to make an extension for IntelliJ to replicate the browser for Java development. Maybe I should revive that project, actually…
Please do. I would love it for Python and TypeScript as well. It could use data from where the "Structure" pane gets its contents
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..
Whenever I tried dabbling in Smalltalk, I would feel constrained by the system in terms of raw real estate. I never cared to view the system through the narrow slit of the method code editor. I would suffer the explosion of windows. All of it was off putting to me, and I never pushed through it to work with a project long enough in order for it to be comfortable.
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.
Totally agree the only viewing methods in isolation, is less valuable than viewing the methods around it "for free". Indeed the methods in my classes are caryfully ordered, to keep ones that are used together on the source together. (And SmallJS is file based)
a simple workflow for development is to have 2 browsers open, 1 test runner, and 1 workspace.
put one browser on your code and the other on your tests
> 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.
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.
Rather than a fixed 4-pane browser, a potential solution is to use something like the macOS finder's "Column" view, where each layer of the hierarchy produces a new pane, as many as you need to drill down to the particular thing you're looking for.
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.
cuis smalltalk has multiple "browsers". One browser allows you to restrict your view of the system (the leftmost pane) to a specific package (eg: the one you're actively creating right now).
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?
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/
Longtime HN user morphle, who commented elsewhere in this thread, has researched and designed chips and hardware for that purpose (edit: for scaling that form of computing). He has been trying to find funds and partners to bring them to market.
Disclaimer: never met or spoken or worked with him
From a conceptual point of view, browsing code is like browsing a fractal. Tools must take this into account.
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
Self's environment was a panning desktop where you would inspect an object's slots and as you kept opening things, they would exist in some space nearby. You could, in theory, keep these things open and have a much more spatial feeling about the system.
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.
Talking about Self... https://github.com/pavel-krivanek/Selfie
...but the infinite desktop is still missing there.
The paper printouts on the table are a kind of simple spatial browser. Thanks to this, we have UNIX (at least it explains how they were able to create anything at all with just a teletype back then).
To add to this, a quote from an article about the editor ed:
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.
> 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.
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.
Literate Programming would arguably be that. It's unfortunate it's not more widely known/used.
This is why a lot of people like Vim.When you can target precisely where you want to edit, it becomes effortless instead of being a chore. With windows (panes), you can easily arrange buffer (contents of files mostly) spatially like you would on a desk. Even with vi (which lacks windows), you can make do with marks (bookmarks on lines)
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,…
I use the pdf view of Literate Programming projects uploaded to my Kindle Scribe in a similar fashion --- at need I've augmented this by switching to my MacBook for coding and using my Samsung Galaxy Book 3 Pro 360 as a second pdf view (which never fails to cause comment from my spouse).
Ah, yes ... "volcanic" organisation.
shuffles papers
"Hang on ... it's here somewhere ..."
Absolutely! So let's have a code browser like that (somehow).
Check out Code Bubbles: https://www.andrewbragdon.com/codebubbles_site.asp
Was this ever revisited or followed up on?
Seems to be over a decade old (and I had trouble getting to the site on my phone).
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
Don't remember that, but I do remember the one for Gupta SQLWindows. I had a discussion about with its designer on reddit some years back, and he admitted it was a horrible mistake. Programs are text, folding is not a great way to represent text.
I kind of want those things for ruby. Not as an exclusive thing, but something to add-on onto at all times. Objects everywhere.
> 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 unable to like anything offering me to observe the library with something different than a hierarchy.
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...
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.
>lambda expressions
smalltalk blocks do this better
The best feature of the Smalltalk browser is that there's no such thing as a 'file' in the organization of the code. I get that we have to have files and directories as operating systems use that concept, but it really doesn't make sense to be constrained organize code that way. In particular, tying visibility and module organization to "what file is in what directory" introduces an abstraction useless for source code.
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.
Historically, Smalltalk has many browsers (views). This System Browser is one of many browsers, and the most busy-looking.
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://worrydream.com/EarlyHistoryOfSmalltalk/
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...
smalltalk invented the concept of views
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.
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...
northern michigan university was using it heavily 8-10 years ago
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 world did Prolog not work out commercially? It's still used where it makes sense to do so.
oh, thanks! I didn't know that Prolog was still used commercially.
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.
Roman empire is obsolete. Men can't stop thinking about it.
mostly because everything relevant we have today was built on smalltalk ideas and it still executed them better in the 70s than modern languages do today.
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.