8 ms·

SmallTalkUnix

85 points by mpweiher 5y ago

pinewurst 5y ago
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...
- mpweiher 5y ago
  Wow, that sounds really interesting! Got any references/links?
  - pinewurst 5y ago
    It was called Unix Navigator - I don't see any obvious references/links.
    - ithkuil 5y ago
      I found only https://www.ricomputermuseum.org/collections-gallery/equipment/ardent-titan https://www.ricomputermuseum.org/collections-gallery/equipme... no screenshots in sight
      - pinewurst 5y ago
        I found http://heaveneverywhere.com/Navigator/ http://heaveneverywhere.com/Navigator/ Stephen Pope and David Leibs were (and hopefully still are) excellent people.
        andrekandre 5y ago
        thats really cool! too bad the linked video is nowhere to be found....
        Zafira 5y ago
        The video is here: A Navigator for Unix -- https://www.youtube.com/watch?v=I3oqgJ1r90c https://www.youtube.com/watch?v=I3oqgJ1r90c
        ithkuil 5y ago
        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.
        andrekandre 5y ago
        nice!
tonyg 5y ago
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.
- tonyg 5y ago
  See also: https://eighty-twenty.org/2011/09/11/code-editor-pane https://eighty-twenty.org/2011/09/11/code-editor-pane
- mpweiher 5y ago
  > 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).
  - tonyg 5y ago
    > That's not even close to a file system 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.
smitty1e 5y ago
It's an interesting thesis, but I'm unsure that I agree: character != pixel Especially in the context of the hardware of the time, I'm skeptical that the sophisticated visual environment envisioned would have materialized. Unless my brief review missed something.
twoodfin 5y ago
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.
- cmrdporcupine 5y ago
  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. That, and, yeah, interoperability.
  - igouy 5y ago
    Interoperabililty meaning what exactly? "Inter-process communication" ? https://www.ibm.com/support/pages/system/files/support/swg/swgdocs.nsf/0/f443d51d7cc38f5685256ab8004f1a23/%24FILE/stpr55.pdf https://www.ibm.com/support/pages/system/files/support/swg/s... "Interface with COBOL, C, and PL/I applications" ! https://www.ibm.com/common/ssi/rep_ca/2/897/ENUS202-152/ENUS202-152.PDF https://www.ibm.com/common/ssi/rep_ca/2/897/ENUS202-152/ENUS... "Language-Shifting Objects from Java to Smalltalk" https://www.yumpu.com/en/document/read/32250538/language-shifting-objects-from-java-to-smalltalk-esug https://www.yumpu.com/en/document/read/32250538/language-shi... SOAP ? WSDL ?
flenserboy 5y ago
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.
- abecedarius 5y ago
  Fun to imagine an alternate history where https://en.wikipedia.org/wiki/Acorn_Archimedes 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.)
  - boygobbo 5y ago
    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/ http://www.rowledge.org/tim/squeak/).
badsectoracula 5y ago
> 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)
- msla 5y ago
  > 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.
  - badsectoracula 5y ago
    > 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.
azinman2 5y ago
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.
readthenotes1 5y ago
The author lost me at the capital T.
- em-bee 5y ago
  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.
  - igouy 5y ago
    Nope. Here's Smalltalk being discussed on https://wiki.c2.com/?SmalltalkLanguage https://wiki.c2.com/?SmalltalkLanguage
    - em-bee 5y ago
      nope what? i don't get how your comment relates to mine. please elaborate.
      - igouy 5y ago
        > … T in SmallTalk, that's wikiwords… https://wiki.c2.com/?SmalltalkLanguage https://wiki.c2.com/?SmalltalkLanguage There we can see a whole pile of Smalltalk wikiwords none of which are SmallTalk.
        em-bee 5y ago
        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
        igouy 5y ago
        As readthenotes1 — only SmalltalkSomething or SomethingSmalltalk
lispm 5y ago
https://www.gnu.org/software/smalltalk/ https://www.gnu.org/software/smalltalk/ " An uncommon feature of it is that it is well-versed to scripting tasks and headless processing." Btw., GNU Emacs is a GUI app, too.
- plafl 5y ago
  I think there was a time where the GNU Smalltalk page contained the phrase "The Smalltalk for those who can type"
igouy 5y ago
> … denial of text-files … that ultimately killed SmallTalk. Maybe business decisions matter to the success or failure of a business? "THE PARCPLACE-DIGITALK MERGER: A TALE OF TERROR?" https://techmonitor.ai/techonology/the_parcplace_digitalk_merger_a_tale_of_terror https://techmonitor.ai/techonology/the_parcplace_digitalk_me...
- smackeyacky 5y ago
  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.
jdougan 5y ago
If Smalltalk is sufficiently friendly to text files, it becomes an emacs.
- pjmlp 5y ago
  Emacs is trying to be a Lisp Machine, without actually delivering the full experience of what meant using one.
  - tonyg 5y ago
    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.
    - jdougan 5y ago
      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?).
      - em-bee 5y ago
        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.
        jdougan 5y ago
        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.
        em-bee 5y ago
lproven 5y ago
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. https://en.wikipedia.org/wiki/Newspeak_(programming_language) https://en.wikipedia.org/wiki/Newspeak_(programming_language... https://bracha.org/Site/Newspeak.html https://bracha.org/Site/Newspeak.html https://newspeaklanguage.org/ https://newspeaklanguage.org/
cmrdporcupine 5y ago
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.
indymike 5y ago
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.
- igouy 5y ago
  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." https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&ots=jiXJNN0ii3&dq=digitalk%20v%2F286&pg=PA25#v=onepage&q=digitalk%20v/286&f=false https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&ots=...
  - indymike 5y ago
    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.
    - igouy 5y ago
pipeline_peak 5y ago
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.
travisgriggs 5y ago
Side note. 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…
- em-bee 5y ago
  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.
- mpweiher 5y ago
  > 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?

85 points by mpweiher 5y ago

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...

mpweiher 5y ago
Wow, that sounds really interesting! Got any references/links?
- pinewurst 5y ago
  It was called Unix Navigator - I don't see any obvious references/links.
  - ithkuil 5y ago
    I found only https://www.ricomputermuseum.org/collections-gallery/equipment/ardent-titan https://www.ricomputermuseum.org/collections-gallery/equipme... no screenshots in sight
    - pinewurst 5y ago
      I found http://heaveneverywhere.com/Navigator/ http://heaveneverywhere.com/Navigator/ Stephen Pope and David Leibs were (and hopefully still are) excellent people.
      - andrekandre 5y ago
        thats really cool! too bad the linked video is nowhere to be found....
        Zafira 5y ago
        The video is here: A Navigator for Unix -- https://www.youtube.com/watch?v=I3oqgJ1r90c https://www.youtube.com/watch?v=I3oqgJ1r90c
        ithkuil 5y ago
        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.
        andrekandre 5y ago
        nice!

tonyg 5y ago

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.

tonyg 5y ago
See also: https://eighty-twenty.org/2011/09/11/code-editor-pane https://eighty-twenty.org/2011/09/11/code-editor-pane
mpweiher 5y ago
> 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).
- tonyg 5y ago
  > That's not even close to a file system 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.

smitty1e 5y ago

It's an interesting thesis, but I'm unsure that I agree: character != pixel Especially in the context of the hardware of the time, I'm skeptical that the sophisticated visual environment envisioned would have materialized. Unless my brief review missed something.

twoodfin 5y ago

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.

cmrdporcupine 5y ago
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. That, and, yeah, interoperability.
- igouy 5y ago
  Interoperabililty meaning what exactly? "Inter-process communication" ? https://www.ibm.com/support/pages/system/files/support/swg/swgdocs.nsf/0/f443d51d7cc38f5685256ab8004f1a23/%24FILE/stpr55.pdf https://www.ibm.com/support/pages/system/files/support/swg/s... "Interface with COBOL, C, and PL/I applications" ! https://www.ibm.com/common/ssi/rep_ca/2/897/ENUS202-152/ENUS202-152.PDF https://www.ibm.com/common/ssi/rep_ca/2/897/ENUS202-152/ENUS... "Language-Shifting Objects from Java to Smalltalk" https://www.yumpu.com/en/document/read/32250538/language-shifting-objects-from-java-to-smalltalk-esug https://www.yumpu.com/en/document/read/32250538/language-shi... SOAP ? WSDL ?

flenserboy 5y ago

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.

abecedarius 5y ago
Fun to imagine an alternate history where https://en.wikipedia.org/wiki/Acorn_Archimedes 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.)
- boygobbo 5y ago
  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/ http://www.rowledge.org/tim/squeak/).

badsectoracula 5y ago

> 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)

msla 5y ago
> 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.
- badsectoracula 5y ago
  > 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.

azinman2 5y ago

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.

readthenotes1 5y ago

The author lost me at the capital T.

em-bee 5y ago
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.
- igouy 5y ago
  Nope. Here's Smalltalk being discussed on https://wiki.c2.com/?SmalltalkLanguage https://wiki.c2.com/?SmalltalkLanguage
  - em-bee 5y ago
    nope what? i don't get how your comment relates to mine. please elaborate.
    - igouy 5y ago
      > … T in SmallTalk, that's wikiwords… https://wiki.c2.com/?SmalltalkLanguage https://wiki.c2.com/?SmalltalkLanguage There we can see a whole pile of Smalltalk wikiwords none of which are SmallTalk.
      - em-bee 5y ago
        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
        igouy 5y ago
        As readthenotes1 — only SmalltalkSomething or SomethingSmalltalk

lispm 5y ago

https://www.gnu.org/software/smalltalk/ https://www.gnu.org/software/smalltalk/ " An uncommon feature of it is that it is well-versed to scripting tasks and headless processing." Btw., GNU Emacs is a GUI app, too.

plafl 5y ago
I think there was a time where the GNU Smalltalk page contained the phrase "The Smalltalk for those who can type"

igouy 5y ago

> … denial of text-files … that ultimately killed SmallTalk. Maybe business decisions matter to the success or failure of a business? "THE PARCPLACE-DIGITALK MERGER: A TALE OF TERROR?" https://techmonitor.ai/techonology/the_parcplace_digitalk_merger_a_tale_of_terror https://techmonitor.ai/techonology/the_parcplace_digitalk_me...

smackeyacky 5y ago
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.

jdougan 5y ago

If Smalltalk is sufficiently friendly to text files, it becomes an emacs.

pjmlp 5y ago
Emacs is trying to be a Lisp Machine, without actually delivering the full experience of what meant using one.
- tonyg 5y ago
  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.
  - jdougan 5y ago
    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?).
    - em-bee 5y ago
      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.
      - jdougan 5y ago
        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.
        em-bee 5y ago

lproven 5y ago

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. https://en.wikipedia.org/wiki/Newspeak_(programming_language) https://en.wikipedia.org/wiki/Newspeak_(programming_language... https://bracha.org/Site/Newspeak.html https://bracha.org/Site/Newspeak.html https://newspeaklanguage.org/ https://newspeaklanguage.org/

cmrdporcupine 5y ago

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.

indymike 5y ago

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.

igouy 5y ago
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." https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&ots=jiXJNN0ii3&dq=digitalk%20v%2F286&pg=PA25#v=onepage&q=digitalk%20v/286&f=false https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&ots=...
- indymike 5y ago
  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.
  - igouy 5y ago

pipeline_peak 5y ago

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.

travisgriggs 5y ago

Side note. 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…

em-bee 5y ago
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.
mpweiher 5y ago
> 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?