SmallTalkUnix
ThoughtStorms Wiki
This was written in response to LionKimbro saying he wanted to get beyond text for programming. (Ie. TextFreeProgramming)
I'm afraid we'll have to part company on your latter assertion. I love text files. There's nothing that can't be represented by a good text file. I'll go further and say that it's denial of text-files (and the underlying file-system standards, text file management tools) that ultimately killed SmallTalk. Had someone seen this clearly in 1980, and figured out how make a transparent two-way connection between Smalltalk space and text-file space, 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 (rather than wait for the X consortium to re-invent the wheel), in a language that was optimised for GUI programming (rather than C and then the hell of C++). Smalltalk would have been the default OO language for professional GUI apps. on workstations from Sun and Silicon Graphics. It would have been the default scripting language in Unix. (Would anyone have bothered picking up Perl if you could pop up the graphical script editor to write a 3 line Smalltalk script, that could run on the CommandLine and interact with TheUnixPipe?)
With Smalltalk established as the only serious GUI / Unix scripting game in town, Mac and Windows would have had to be more Smalltalk-like. Visual Basic, Python, Ruby and Java would never have been invented. (Or, at least, not in their current forms. Instead we might have seen language evolution in the form of improvements to or different flavours of Smalltalk, much as there were companies evolving Lisp)
And yet people would have still kept source-code in Subversion and Git. And used diff and patch (and occasionally sed) and all the other command-line goodies.
The Free Software Foundation would have had to ensure a graphical Smalltalk environment was available in Gnu and so one would have quickly migrated to Gnu/Linux. If it existed, Emacs would have become a GUI app. But it may have been that much of the ingenuity that went into extending Emacs, instead would have gone towards evolving the class-browser into an even more powerful and scriptable editor / IDE.
By the mid-90s, the default web-browser would have been assembled from flexible Smalltalk components. The web-server might have had some fast C innards, but the majority of it would be written in industrial-strength Smalltalk. [Lion's] hope for a web, not of documents but of networked GUI components would have been a plausible development in that environment.
In short, Smalltalk's rejection of the file-system and command-line, both crucial text environments, forced programmers to choose unnecessarily between the graphic and the textual toolsets, and naturally, the better (more powerful and flexible) won. For professional programmers, the command-line is still king and graphical tools never really reached the potential that Smalltalk apps. like the class-browser hinted at.
See also :
Hacker News discussion
This got picked up by HackerNews https://news.ycombinator.com/item?id=29948392
with some interesting comments. Including a link to NavigatorForUNIX
What will happen if one rewrites the entire Linux using Smalltalk?
Dec 15, 2017 https://www.quora.com//What-will-happen-if-one-rewrites-the-entire-Linux-using-Smalltalk/answer/Phil-Jones-He-Him
It's hard to see why you'd want to clone it exactly.
You probably could do it, in say a tenth of the lines of code in Smalltalk. But as many people have pointed out, that it still a hell of a lot of work.
The nice thing about creating OSes / machines from the ground up in new / high level languages is that you can strip out all the cruft and have nice shiny new elegant systems with several orders of magnitude fewer lines of code.
Lisp machines, Smalltalk, even REBOL are examples of this.
Having said that, I personally think that Unix has some very great virtues. Especially the file system, process and piping model. And that it was Smalltalk's refusal to play well with the Unix world of plain-text files and pipes which led to its failure to be more widely adopted and valued.
I wouldn't rewrite Linux in Smalltalk. But if I were to reinvent Smalltalk, I'd make sure that it supported something very like Unix's file system; and pipes and processes. And that it supported a shell / terminal very like the Unix one.
There are several aspects of this.
The Unix terminal isn't perfect. But nor is the Smalltalk distinction between Workspace and Transcript in two entirely separate windows. I'd like something more like a single split window with commands typed in one panel, and responses appearing in the other.
I want to be able to mount external drives (HD, pendrive, other computers) in standard formats like NTFS or FAT and be able to navigate within them inside my Smalltalk system indistinguishably from the way I navigate within my Linux terminal. I need to be able to copy pictures and media files back and forward between external drives and my local system.
I'd want freeform text "files" and streams to be first-class citizens of the environment. Any collection or object should be able to serialize to both JSON and CSV-like representations as standard. And piping the value of any text-file / collection through simple text / csv / json aware filters should be normal practice.
It should be as simple on the command-line as
fileName pipe: map | (filter1 [args])| filter2 | fold
etc.
I want to be able to do the equivalent of commands like "find" at the terminal to get a textual representation of the class-hierarchy, and to be able to navigate / process within it by piping it through extra filters and transformers.
I like the fact that the Unix pipe launches each tool in a separate process with asynchronous communication. In a single character. That's a stunning level of elegance / expressivity. A Smalltalk "operating system" should have concurrency.