One of the cooler things I ever saw Claus Gittinger do with his innovative Smalltalk/X was implement a user space file system interface to the Smalltalk image/object memory.
You fired up a Smalltalk virtual machine, and then did a mount. The root Smalltalk namespace became the mount root. Classes were directories, subclasses sub directories I think?. Methods showed up as files, meta data (like class properties) showed up as special files (dot files maybe? It’s been too long). Because Smalltalk/X had private (or scoped) classes, Namespaces wet just classes themselves.
It was pretty cool. You could grep, ls, navigate.
But it wasn’t just for viewing! If you vim’ed a method/file and saved it, it changed the method. Of the live system? Want to rename the class? Just mv it. Also useful for changing class hierarchies.
And because Smalltalk, was this crazy navel gazing virtual machine with turtles all the way down… you could cd to the very objects that molementuaons of the live user space file driver!
I think the author of the original article is naive though.
While this was cool and meta, it actually demonstrated one of the problems that the Smalltalk Browser with its direct integration to live object memory of code objects was trying to solve.
A rich full self hosted all-objects system was not small. In these years, you could get a cool poster from Microsoft showing the class framework for MFC C++. It was like 300 classes. A full up VisualWorks or Smalltalk/X image might have 2,000. When I would do meta analysis on Smalltalk method ASTs, it was not uncommon to traverse 20,000 methods.
Today, I don’t do Smalltalk, haven’t for nearly 10 years now. I still find programming with files very quaint. It’s like we’re stuck in a world where VHS beat Beta…
> it actually demonstrated one of the problems that the Smalltalk Browser with its direct integration to live object memory of code objects was trying to solve.
> [2000 classes/20000 methods]
Can you explain? Do you think this is too many methods to represent them as files in the filesystem?
that directory structure is very close to what you get when you export smalltalk code from eg pharo so that you can commit it to a revision control system.
> This was written in response to LionKimbro saying he wanted to get beyond text for programming. (Ie. TextFreeProgramming) [..] I'll go further and say that it's denial of text-files [..] that ultimately killed SmallTalk. Had someone seen this clearly in 1980 [..] we might have seen a very different evolution of computing : a true synthesis of Smalltalk and Unix. Smalltalk could have become the graphical shell on top of Unix, providing it instantly with a sophisticated GUI
This seems to rely on the assumption that Unix was the best approach for OSes one could do in 1980. Perhaps we should also think not just getting beyond text for programming but also beyond Unix as the lowest common denominator in thinking about OSes?
(BTW "beyond text" doesn't mean "beyond symbols" since somehow you'd need to represent the program neither "beyond keyboard" - especially if you consider that chances are your keyboard already has a bunch of symbols like "@#$%^" that aren't really text, they just are some random symbols that someone at some point decades ago decided it'd be useful to be part of ASCII)
> especially if you consider that chances are your keyboard already has a bunch of symbols like "@#$%^" that aren't really text
Of course they're text. What else could they possibly be?
As for going beyond text, it becomes difficult to coordinate richer types of files between different groups, especially if every group is convinced that other groups are missing some vitally important functionality and, therefore, everyone will be convinced of the essential rightness of their cause given enough time.
> Of course they're text. What else could they possibly be?
Symbols.
> As for going beyond text, it becomes difficult to coordinate richer types of files between different groups
Well, yeah, the reason why we focus on Unix as a lowest common denominator for OSes, text files as the best way to store code, etc isn't because they are objectively superior to everything else, but because they are things that were good enough and existed earlier enough to gain approval and have people learn and rely on them.
But while this is a practical concern, that doesn't mean we can't think of alternatives. Perhaps with a stroke of luck or the right circumstances (e.g. some new type of platform) it could even catch on.
Both predate computers as shorthand spellings of words and phrases. @ for example dates to 1500s Italy. # is often used to denote a number is an ordinal number, or as a substitution for the word pounds (weight, not currency).
As you see, these are symbols that can be replaced with a textual description of what they mean - being something like "macros" for text. So as i wrote, we are already using symbols that aren't text and we do enter some of them via dedicated keys on the keyboard.
The main issue here is to see these symbols for what they are: an arbitrary set of symbols that we limit ourselves to because they are printed on the keycaps of the keyboards we have.
But we don't have to only use symbols found on keycaps, we don't have to use keyboards that essentially inherit the same layout and most of the keys from centuries old typewriters, we don't have to limit ourselves to a handful of letters and symbols chosen decades ago for devices that were already primitive in 1980.
The by far main reason we do all that isn't because the current system is better but because of what is essentially software peer pressure.
No, we dont because non-keyboard symbols are irritating to type. Look at the history of APL and other symbol based languages.
In any case, the computer doesn't care. It is either a character or something similar stored as binary representing part of an instruction to be compiled into other binary.
I have seen a few proposals for creating languages which are exclusively stored as a generic AST, sufficiently abstract that it can be edited in any variety of "languages" in a capable editor, then stored back into the AST. I havent seen a good proposal for making that actually workable, however. It sounds a bit like storing code as the output from LLVM then expecting an editor to be able to open it as C# or JavaScript or Lisp.
Their wikipedia pages give several modern day usages, including those I listed and the sibling comment (@ meaning at the price of, # as shorthand for pounds, etc)
There's nothing that can't be represented by a good text file
even a plain text file has a bunch of metadata that should actually be part of the file object itself and not rely on the storage medium where different systems have a different idea what metadata should be associated with the data.
a plain byte-stream is the simplest, but also the most limited way to represent data.
with text based systems i have the option of either loosing the metadata when i copy the bytestream, or i rely on crude methods like EXIF data on images which i can't change without breaking the ability to easily detect if the image itself is changed or not.
I’d love to believe this: A Smalltalk universe of objects with a foundation in the Unix files & processes & pipes model would be intriguing.
But it ignores the commercial aspect: I don’t think anyone was giving away an industrial strength Smalltalk development environment at the same time gcc was gaining traction against the proprietary C/C++ toolchains.
What Smalltalk really needed was a Linus or a Guido ca. 1993.
Smalltalk needed that in 1983, not 1993. By 1993 it was too late, consumers expected a personal computer to be, well, a PC, defined by the norms and standards of the successful entrants from the 80s, IBM and Apple. In 1983 they were still open to alternatives. By 1993 they expect C or a Wirth PL, files/filesystems, and maybe a Mac-like desktop metaphor.
In large part the problem was the vision that the language offered was beyond what consumer-accessible hardware could handle well by at least 10 years. The Alto was a bespoke minicompter-esque machine custom built by Xerox and was far beyond what landed on regular office desks until the late 80s. Tektronix and others tried really hard to optimize Smalltalk-80 to run on 8mhz/68000 class machines at reasonable spec and it was still pretty sluggish. On top of clock speed, RAM and disk space was super expensive in the 80s.
And Smalltalk was also heavily blockaded by gatekeepers commercial and academic until it was too late, as well. There was no serious open source Smalltalk-80 until Squeak in the late 90s.
Sept 21, 1987 — "A version of the Smalltalk-80 object-oriented development environment … has been announced by Parcplace Systems.
Smalltalk-80 DE version 2.2 is said to provide Unix environments with interprocess communication via sockets and access to Unix C shells. On the Apple Macintosh, it provides access to Desk Accessories and provides the ability to cut and paste between the Smalltalk-80 system and the clipboard."
Ok, sure, but "is said to provide" is not proof that it provided that. Lots of companies have put out marketing material that blatantly lied or inaccurately represented their upcoming product -- in fact not only was it more blatant back then but the term originated back then - "Vapourware".
The fact that the only papers thusfar procured were written 15 years later really does not help your point.
Just waiting for someone to say what exactly they mean by interoperability, and then have them show it was not provided in Smalltalk implementations (and then have them show it was provided by other tools during the same period).
There was actually a Smalltalk shell for Unix - it was bundled with the Ardent Titan (cough) "mini-supercomputer". Best feeling keyboard I ever remember using but a very meh system otherwise. Old man shakes fist at clouds...
unfortunately due to the video quality it's very hard to see the details. I doubt the original analog quality was that bad, it either got crippled by digitalization or it had degraded before being digitalized.
The Newspeak programming language was specifically designed to address some of these issues. It is capable of working with plain-text files, enabling code to be stored in Git and so on.
In early development, it was bootstrapped on top of Squeak Smalltalk.
The author is basically describing GNU Smalltalk, which has been around since the mid-90s, I believe. (Wikipedia says initial release 2003 but I'm pretty sure I saw it a long time before that. The GNU mailing list goes back to 2000 and even at that point references a 1.8 version...)
That's a Smalltalk without a GUI that fits well into the Unix environment.
Quite a lot of assumptions and conjecture about how things would have turned out…
Maybe better to frame as “it could have” or “what if”? And even then, who knows. It’s not like everything SmallTalk related is a panacea, it’s unclear how a text file and data structures have meaningful and usable bi-directional interchanges, or that the GUI of Suns had much sway in what was going on in the rest of the computing world which probably had seen few of these miraculous hypothetical SmallTalk systems running at huge pricing for enterprises.
I think this is wide of the mark. Smalltalk has a filesystem: the global dictionary. Sure, it's flat, but so was the root directory in DOS 1 and CP/M. See Self for an evolution of this idea toward something better. Smalltalk has a command line: literally every editable text field, but in particular the code pane of the system browser. Furthermore, not everything in Unix is a text file. It's... not easy working with a.out, .a, .tar, .Z, .so etc using a text editor.
> Smalltalk has a filesystem: the global dictionary.
That's not even close to a file system.
> Sure, it's flat
Right, and that makes it almost completely useless. How are Apple DOS, CP/M etc. doing today?
But more significantly, it is not the least interoperable. How do systems outside of Smalltalk get access to the Smalltalk global? How is such access mediated? How are permissions handled? What's more, if other systems could get access to a pointer (and it didn't move out from under them during a GC), how would they be able to deal with the data?
Filesystem doesn't just mean a hierarchical directory tree with nodes, it also means interoperable, serialised representations, including but not limited to: ASCII, RTF, JPEG, PNG, PDF, JSON, HTML, etc.
Representations that can also be shipped over the wire. There is a reason the WWW was invented on a NeXT box, not on an Alto (or Dorado).
Nonetheless, Smalltalk is to Unix as globals dictionary is to file system, image is to virtual machine, etc.
> How do systems outside of Smalltalk get access to the Smalltalk global? How is such access mediated? How are permissions handled? What's more, if other systems could get access to a pointer (and it didn't move out from under them during a GC), how would they be able to deal with the data?
How do systems outside of Unix get access to the file system? How is such access mediated? How are permissions handled? What's more, if other systems could get access to a disk sector (and it didn't move out from under them during normal system activity), how would they be able to deal with the data?
Answer these questions, and you'll have answered those you asked about Smalltalk. If you squint a little.
The OP is about envisioning Smalltalk and Unix working together. I'm not following your point of making analogies between Smalltalk and Unix, unless... Are you suggesting Smalltalk could have/should have/was a contender to be the OS, that it would replace unix, that would have been preferable?
IMO, Smalltalk-the-system is best thought of as an OS, yes. (Remember how everyone ridiculed the idea of Smalltalk's images right up until virtual machines became a thing?) It has a runtime and a systems programming language, too: the Smalltalk VM, and Smalltalk-the-language. Analogously, Unix has its kernel and C, respectively. The global variables of Smalltalk are analogous to Unix files. Smalltalk processes to Unix processes. It's not a perfect analogy but I found it surprisingly useful once I stumbled across it.
I think you'd have to burn the disk packs (ie: neither Smalltalk nor Unix as they stand make a suitable foundation), but out of the ashes I think something largely based on Smalltalk taking into account lessons from the forty (!) years that followed it could definitely end up being preferable.
Coming back to OP, and viewing Smalltalk as an operating system on equal footing with Unix: Different operating systems interact best via networks. Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well.
OK, so the OP says if smalltalk had worked with files better, maybe smalltalk on unix could have been a thing that would have changed history. Your response is... that's irrelevant because... smalltalk was really making the play to be the OS, not to work with OSs, and it works just fine with files on it's own terms, for that goal. Do I understand your argument correctly?
> Smalltalk-the-system is best thought of as an OS
That is the is that OP is lamenting, the fact that this attitude was a significant (not: sole) cause in Smalltalk's demise. He is talking about the ought, it shouldn't have been this way, and if it hadn't been this way it would have been a LOT better.
Keep in mind that you can still build a pure Smalltalk OS on top of the Smalltalk that's not an OS, if you want to.
> It's not a perfect analogy
It is at best an analogy, and not a particularly good one at that, as whereas Smalltalk can function as an OS (you can port Squeak to bare metal fairly easily, for example), it isn't a very good at it, at least not when it comes to the functions OSes are expected to fulfil these days. And so the analogy stays at most an analogy, and breaks down even at that pretty quickly.
It turns out that what OP was talking about was created, sort of: NeXTstep. Except it substituted Objective-C for Smalltalk. Heck, it even did messaging at the OS layer (Mach).
> ...viewing Smalltalk as an operating system on equal footing with Unix...
That is exactly the problem.
> Different operating systems interact best via networks.
And that turns out to be significantly more difficult than various languages interacting on the same box.
> Which neither Smalltalk-the-OS, Smalltalk-the-language, Unix-the-OS nor C-the-language support particularly well.
True. Objective-S supports REST servers and clients effectively at the language level. And filesystems and Unix pipes. http://objective.st/ And it doesn't insist on being the entire world.
I think he's wrong, both about the "is" and about the "ought".
The reason I posted originally, way upthread, was to respond to OP's claim of "Smalltalk's rejection of the file-system and command-line". I don't believe it rejected either thing. It has an internal file system, as discussed, but it also had and has perfectly reasonable support for reading and writing external, traditional files. And it has various kinds of command-line, as discussed.
I don't think it was anything about Smalltalk's ability to handle JPEGs or email or NFS or even text files that was the problem. I don't believe that appeasing the Unix world is (or would have been) either necessary or sufficient for Smalltalk success. I think the success of Unix is path-dependent; a historical accident. It had momentum and Smalltalk didn't. It blows my mind that people still think Unixisms are somehow some kind of universal apex of computing [†]! I suppose there are, at some level, reasons for Smalltalk's relative lack of success; and while I don't know what they are, I don't think OP gives a good one.
> [Interacting via networks] turns out to be significantly more difficult than various languages interacting on the same box.
I... don't believe this to be the case. At all. In theory or practice. It has certainly not been my experience.
> Objective-S supports [a bunch of Unix stuff]
Sure, OK. So do a million other languages.
What is, to my mind, special about Smalltalk is exactly that it takes the identity between programming language runtime and operating system seriously, and tries to flip the script: what if, instead of dumbing down our languages to fit our operating systems, we raised our ambitions about what an operating system could be, to fit our languages?
Smalltalk as it stands is a poor operating system, of course. You're right that it doesn't come close to covering "the functions OSes are expected to fulfil these days". It is basically a time capsule of 1978. Semi-cooperative scheduling, Monitors and Semaphores for mutexing, flat file system, insufficient internal isolation/namespacing, poorly integrated networking. If even a small fraction of the energy put into making Unix cover those functions had been put into Smalltalk... well. We'll never know unless someone puts in the time.
--
[†] "... an utterly insignificant little blue green planet whose ape-descended life forms are so amazingly primitive that they still think [Unix is] a pretty neat idea"
> I don't believe it rejected either thing. [files/command line]
I understood that you believe that. My point is that you are wrong.
The point of files and the command line is not to have some sort of analogous mechanisms somewhere, no matter how far you had to stretch the analogies, and you had to stretch them pretty much to or slightly beyond the breaking point.
The point is to be integrated into the Unix filesystem and the Unix command line (or the Windows one, doesn't matter). Because they are integration mechanisms.
> It blows my mind that people still think Unixisms are somehow some kind of universal apex of computing
Well, that should blow your mind, because they are not the "apex", they are the lowest common denominator, the minimum that you need to play. But if you don't adhere to this minimum, you can't play. And so Smalltalk got left behind.
> [..] Smalltalk is exactly that it takes the identity between programming language runtime and operating system seriously
The point is that this, while an attractive idea, and a locally productive one, it is not actually a good one, because it creates isolated worlds. And it turns out that not being isolated is more important than being locally optimal.
Just like the image is a great hack, because it provides so many things "for free" that other environments have to work really hard at. But, paradoxically, it turns out the price is still too high. Which doesn't mean that other systems couldn't and shouldn't learn from the image. Just not duplicate it.
What Objective-S is trying to do is combine the two, because I don't think you have to isolate yourself and try to be the OS to achieve the good parts of Smalltalk. And no, GNU-Smalltalk wasn't it, otherwise I would have just used that.
i read it as mpweither arguing that the lack of interoperability is the fault of smalltalk, whereas tonyg points out that the fault might just as well be on the unix side. just as you are not going to blame unix that windows can't read a unix filesystem, it's not clear that smalltalk should be blamed that unix can't access a smalltalk image.
if i want windows to access data on unix, then i write it to a filesystem that windows can read. likewise if i want a unix system to access the data inside a smalltalk image i need to write it from smalltalk to outside the image onto a unix filesystem.
It's not a symmetric situation as these are not at the same level of the stack.
Unix, as an OS, can and, maybe more importantly, does host a plethora of languages and even operating systems (as VMs). Smalltalk does not, and if you take the OS = language idea seriously, cannot.
So Ruby can read Unix directories and files. Ruby cannot read Smalltalk "directories" (the Smalltalk dictionary) or files (objects). And Smalltalk cannot read Ruby objects.
Python can read Unix directories and files. Python cannot read Smalltalk directories or files. And Smalltalk cannot read Python objects.
Java can read Unix directories and files. Java cannot read Smalltalk directories or files. And Smalltalk cannot read Java objects.
etc.
All of these can interoperate fairly trivially (though possibly not particularly well) via the filesystem. They cannot (and could not, without significant effort) interoperate via Smalltalk.
interaction of different system at the object level has been done before though and i think that is an area that could use more research and evolution to become usable.
> interaction of different system at the object level has been done before though
Yes. I have used this (CocoaJava, Tcl/ObjC, Ruby/ObjC, etc.) and also implemented it myself (Squeak/Objective-C, among others). Even though I'd say that Objective-C is probably about as good at this as it gets, the end results are still complicated and fragile.
In the end, what ends up most workable is that one object model is declared "it", and the rest of the languages then just skins on top of that object model. (See the various .NET languages and reimplementations, JVM languages and reimplementations, and now Truffle/Graal).
i think there are three kinds of object level interaction. one is skins where the application is written in a different language than the VM it runs on top of.
the second is some form of object-message passing where two independent applications written in different languages (or also the same language) are able to pass objects back and forth. those objects need not be native objects to either language.
in the third the objects being passed are still connected to the source and calling a method on the object gets sent back to the application it originates from.
i believe CORBA falls into that category.
the one system that i am most familiar with here is bridging pike with php or java and it too is only used one-way in that there are clients written in php, java and pike, but the server is in pike only.
i am mostly interested in the second and third type.
the first type doesn't allow me to write truly native applications because in the end even of i use eg. Clojure, i am still creating and using a java application.
the second type allows me to transport rich data objects, and i see the goal here as replacing the currently text based filesystem with such objects.
one issue is how to transport the objects. xml and json have been used a lot for the second type, but both are to limited.
we need better object formats and interfaces and filesystems that support them.
If Smalltalk is pretending to be Unix, it could just speak NFS I suppose. Or use HTTP. Or 9P. Certainly there are classes in most images that model file systems.
But thinking of Smalltalk as its own thing, and coming at the angle of interoperation between systems across networks at a higher level than chunks of untyped binary data, there are a few contenders: there have been various distributed Actor implementations. CORBA was available, back when that was relevant. Craig Latta has been doing some wonderful crazy things with interoperation between separate images (e.g. Context, nee Spoon: http://netjam.org/context/).
But we weren't talking about the entire Smalltalk system and whether it is possible to make it interoperate. You obviously can make it interoperate in various ways.
What we were talking about was the globals dictionary, the only instance of SystemDictionary, that serves as the repository of global variables in Smalltalk systems. That is not an integration point and not a filesystem, despite tonyg's insistence that since it has some very superficial similarities, it therefore is a filesystem.
> You obviously can make it interoperate in various ways.
That's sufficient clarification.
(My guess is that these discussions are read mostly by people without any actual experience of Smalltalk, who may take "… not the least interoperable…" generally and literally.)
The assertion that denial of text files killed SmallTalk isn't true. What killed SmallTalk (and really limited Unix growth) was this:
Hardware cost + software cost compared to emerging cheap commodity computers. SmallTalk was expensive, and required very expensive equipment to run. So most of us either just ignored SmallTalk or viewed it as a utopian ideal that our PC IDEs could never really deliver on... but... we were making software for computers with MILLIONS of users.
So what about Unix? It wasn't until the 386 and 68030 in the later part of the 80s that the hardware finally had the features Unix really needed to be great (Xenix on a 286 was... meh but worked).
So, the idea that somehow a graphical Unix based on smalltalk would emerge... well... would have been cool... and it kind of did happen when NeXT came out with their computer... but it was Objective-C instead of SmallTalk, but most of the smalltalk on Unix dream was there.
March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."
I remember this one - they had a neural network add on (all things old are new again).
I seem to remember this one having it's own GUI... which was more bad timing. Windows 2.0 came out in 87, and it was pretty clear the future looked a lot like Windows (obtainable) or OS/2. In July of 88 Windows/286 & Windows/386 came out (really Windows 2.0 v2.0) and started carving market away from Desqview and some of the other real mode multitasking shells and being bundled with new PCs. The big advantage of supporting Windows over a bespoke GUI was application integration - things like printer support, a shared clipboard, a unified format for help files... all really made building for Windows attractive.
All that, plus the attitude problems coming out of ParcPlace when it came to support for customers, the far too late delivery of needed collaboration tools and the relentless innovation around languages while the Smalltalkers thought they had an unassailable lead.
I dabbled in a little VisualWorks recently and it was fun but it's best if the past is left there sometimes. I did enjoy my time with VisualWorks back in the 1990s but .NET is much more productive whether as a solo developer or in a team.
Ok, speculate all day, but...instead, build an example, for older hardware. Allow a 68040 or so, even. That shouldn't be all that hard with modern tools. Let's see if it would have been better / useful / good. It could, at worst, point to another direction which could be taken now.
Fun to imagine an alternate history where https://en.wikipedia.org/wiki/Acorn_Archimedes shipped with Smalltalk as OS. (I've never tried that hardware and I'm not sure if the first model would really be zippy enough. But it's a machine with plenty of fans, and obviously a better future than the 68000's.)
As someone who did use an Archimedes A440 when it came out (late 1987 I think), it was plenty zippy enough. It's original desktop shell Arthur was written in BBC Basic, so I think it could have handled Smalltalk. There is a port of Squeak for recent versions of RiscOS (http://www.rowledge.org/tim/squeak/).
People like to fantasize about how things would’ve been better if the industry was dominated by X language.
I feel they forget to acknowledge that most programmers rarely adopt the design patterns and overall styles that make languages like SmallTalk and Lisp so highly praised.
if you are referring to the T in SmallTalk, that's wikiwords.
once upon a time wikis were designed to detect words like that and automatically turn them into links to other wiki articles. that's also the reason why all articles on wikipedia start with a capical letter even though sometimes that is incorrect.
but all of them have a middle capital in there. that's the feature. you can't use Smalltalk as a wikiword. only SmallTalk, SmalltalkSomething or SomethingSmalltalk
Ironically, I think following OP's prescription would yield a Smalltalk trying to be a Smalltalk without actually delivering the full experience of what it meant to use one! A kind of pyrrhic victory.
I don't know. All I know is that now I want an an emacs implemented in Smalltalk. Maybe copy the Genera/Zmacs approach, maybe something else (plan9/acme?).
a large weakness of smalltalk (pharo/squeak at least, i don't know about the others) for every day use is a good text editor. it doesn't have to be emacs or vi, but something in that range would be nice to have.
The frustrating part is that there was a summer of code project to build a better editor in Pharo (I think the name was Safara). But as I remember, the author dropped it and it became incompatible with the next version of Pharo.
and it looks like it was a gsoc project for squeak with an attempt to port to pharo after gsoc was over, and apparently it was never fully completed to begin with even for squeak. the author then probably dropped it because life got in the way. that's an unfortunate outcome of some gsoc projects. not all end up being successfully integrated.
getting this to work on pharo now would be a bit more effort than merely keeping up with pharos development.
One of the cooler things I ever saw Claus Gittinger do with his innovative Smalltalk/X was implement a user space file system interface to the Smalltalk image/object memory.
You fired up a Smalltalk virtual machine, and then did a mount. The root Smalltalk namespace became the mount root. Classes were directories, subclasses sub directories I think?. Methods showed up as files, meta data (like class properties) showed up as special files (dot files maybe? It’s been too long). Because Smalltalk/X had private (or scoped) classes, Namespaces wet just classes themselves.
It was pretty cool. You could grep, ls, navigate.
But it wasn’t just for viewing! If you vim’ed a method/file and saved it, it changed the method. Of the live system? Want to rename the class? Just mv it. Also useful for changing class hierarchies.
And because Smalltalk, was this crazy navel gazing virtual machine with turtles all the way down… you could cd to the very objects that molementuaons of the live user space file driver!
I think the author of the original article is naive though.
While this was cool and meta, it actually demonstrated one of the problems that the Smalltalk Browser with its direct integration to live object memory of code objects was trying to solve.
A rich full self hosted all-objects system was not small. In these years, you could get a cool poster from Microsoft showing the class framework for MFC C++. It was like 300 classes. A full up VisualWorks or Smalltalk/X image might have 2,000. When I would do meta analysis on Smalltalk method ASTs, it was not uncommon to traverse 20,000 methods.
Today, I don’t do Smalltalk, haven’t for nearly 10 years now. I still find programming with files very quaint. It’s like we’re stuck in a world where VHS beat Beta…