4 ms·

I tried writing a ST for the Z-80 and then the first PC, but I bit off a bit more than I could chew considering I wasn't taking the minimal language approach (l

I tried writing a ST for the Z-80 and then the first PC, but I bit off a bit more than I could chew considering I wasn't taking the minimal language approach (like "A little Smalltalk") but was trying for the self-bootstrapped whole VM and I had no image available so I had to try and wire everything up in a magical state -- still a great exercise though. I've tried ST on Tektronix and the Apple Lisa. A GUI dev. environment ahead of its time, though "image save"-based development with classes strewn around everywhere isn't the best model for development, nevermind delivery where you never know what your code is going to be running next to. ST is also largely to "blame" for single receiver dispatch, and to a less extent the overuse of implementation inheritance, as most languages for performance don't have messages as first-class objects meaning that delegation becomes harder so inheritance was used over composition in most OO languages following. (Though you can use monkey-patching in langs that support it.)

igouy 7y ago
> …though "image save"-based development with classes strewn around everywhere isn't the best model for development… What do you mean "classes strewn around everywhere" ? "Smalltalk-80 The Interactive Programming Environment" chapter 23 explains the different ways class definitions, comments and methods could be saved to text files; and filed into a vanilla image in a standard build process. http://sdmeta.gforge.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://sdmeta.gforge.inria.fr/FreeBooks/TheInteractiveProgra... > …nevermind delivery where you never know what your code is going to be running next to. Do you mean you never know what non-smalltalk code would be running on the same machine as the smalltalk code ? Why would that be a problem ? Why would that be more of a problem with a Smalltalk image than with .pyo ?
- monocasa 7y ago
  The issue on Smalltalk 80 was that diffing and combining images was a huge pain. There wasn't a clear seperation between the system itself and whatever you were working on. On top of that, Smalltalk VMs generally assumed that they were the only Smalltalk VM running on a given system so it's not like you could run the different apps like different containers or processes, or whatever. Additionally Smalltalk pretty heavily encouraged making modifications to the system classes as part of the porting process. So, not the OP, but my answers to your questions: >What do you mean "classes strewn around everywhere" ? It was rarely clear where your classes ended, and the system ones began, which got in the way of distribution, particularly if you wanted to run on different hardware. It was surmountable, but a pain in the ass compared to Unix (which is not really the world's highest bar, particularly at the time). > Do you mean you never know what non-smalltalk code would be running on the same machine as the smalltalk code ? > Why would that be a problem ? It's what's versus running in the same VM image, including modifications to the system classes themselves. There's no good boundary between apps other than they don't have references to eachother. >Why would that be more of a problem with a Smalltalk image than with .pyo ? Because a .pyo only has the classes that pertain to what it's trying to do, and doesn't stop you from running other python instances at the same time. Imagine if there was only one python vm allowed to run at once, the source was an afterthought (and considered not idiomatic), and pyos were basically just memory dumps each with their own unique monkey patching of system classes. There's a good chance that squeak/pharo have done work to address this, but that was the state of the world for Smalltalk 80. It was designed right at the cusp of collaboration on design of personal computer apps, and it shows in the overall design.
  - igouy 7y ago
    > …the state of the world for Smalltalk 80… Please look at chapter 23,"Smalltalk-80 The Interactive Programming Environment" (system change set, change-management, conflict resolution). > …only Smalltalk VM running on a given system… I remember running side-by-side Smalltalk images on the same system (one with Windows UI look and one with Mac UI look -- so I could tell which was which) in 1994. > …which got in the way of distribution, particularly if you wanted to run on different hardware. Let's say you'd been developing on a Mac and wanted to show on a Windows machine: you simply installed the Windows VM on the Windows machine, and copied your image file (and change log) from the Mac to the Windows machine — done. > …rarely clear where your classes ended, and the system ones began… Prefixing class names was a common way to make it really clear which were your classes.
    - monocasa 7y ago
      You're talking to someone who implemented a Smalltalk 80 VM. >Please look at chapter 23,"Smalltalk-80 The Interactive Programming Environment" (system change set, change-management, conflict resolution). It was still a huge pain in the ass compared to other systems. >I remember running side-by-side Smalltalk images on the same system (one with Windows UI look and one with Mac UI look -- so I could tell which was which) in 1994. So 14 years of Moore's law later, you could run two. My point was directed at the early eighties. Matching the OPs description of ST and first PC. >Let's say you'd been developing on a Mac and wanted to show on a Windows machine: you simply installed the Windows VM on the Windows machine, and copied your image file (and change log) from the Mac to the Windows machine — done. You were heavily encouraged to modify the base image to support different machines in the early eighties. Moving an image from.one hardware watch to another didn't practically work quite a bit of the time. Stuff like the screen resolution was hardcoded into the images, so you'd just be met with a blank or unintelligible screen if you tried. >Prefixing class names was a common way to make it really clear which were your classes. And if you had any dependencies that really broke down.
      - igouy 7y ago
        > You're talking to someone who implemented a Smalltalk 80 VM. Do you mean yourself or do you mean thelazydogsback ? > …compared to other systems. Depends which other systems were actually available where you were working. *> So 14 years of Moore's law later…" Wasn't the problem insufficient installed memory?
saijanai 7y ago
Simply use the squeak VM as your starting point. If there is a C compiler and sufficient memory to hold the image, all of squeak can be ported to a new processor in a few week. Alan Kay's original Smalltalk team did that with the MIckey Mouse PDA when they were working at Disney — they knew who they would be working for next and so named the opensource Smalltalk-80 project at Apple "Squeak" in honor of that venerable old mouse. Even after the team left Disney, the name stuck (and now you know the rest of the story).

igouy 7y ago

> …though "image save"-based development with classes strewn around everywhere isn't the best model for development… What do you mean "classes strewn around everywhere" ? "Smalltalk-80 The Interactive Programming Environment" chapter 23 explains the different ways class definitions, comments and methods could be saved to text files; and filed into a vanilla image in a standard build process. http://sdmeta.gforge.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf http://sdmeta.gforge.inria.fr/FreeBooks/TheInteractiveProgra... > …nevermind delivery where you never know what your code is going to be running next to. Do you mean you never know what non-smalltalk code would be running on the same machine as the smalltalk code ? Why would that be a problem ? Why would that be more of a problem with a Smalltalk image than with .pyo ?

monocasa 7y ago
The issue on Smalltalk 80 was that diffing and combining images was a huge pain. There wasn't a clear seperation between the system itself and whatever you were working on. On top of that, Smalltalk VMs generally assumed that they were the only Smalltalk VM running on a given system so it's not like you could run the different apps like different containers or processes, or whatever. Additionally Smalltalk pretty heavily encouraged making modifications to the system classes as part of the porting process. So, not the OP, but my answers to your questions: >What do you mean "classes strewn around everywhere" ? It was rarely clear where your classes ended, and the system ones began, which got in the way of distribution, particularly if you wanted to run on different hardware. It was surmountable, but a pain in the ass compared to Unix (which is not really the world's highest bar, particularly at the time). > Do you mean you never know what non-smalltalk code would be running on the same machine as the smalltalk code ? > Why would that be a problem ? It's what's versus running in the same VM image, including modifications to the system classes themselves. There's no good boundary between apps other than they don't have references to eachother. >Why would that be more of a problem with a Smalltalk image than with .pyo ? Because a .pyo only has the classes that pertain to what it's trying to do, and doesn't stop you from running other python instances at the same time. Imagine if there was only one python vm allowed to run at once, the source was an afterthought (and considered not idiomatic), and pyos were basically just memory dumps each with their own unique monkey patching of system classes. There's a good chance that squeak/pharo have done work to address this, but that was the state of the world for Smalltalk 80. It was designed right at the cusp of collaboration on design of personal computer apps, and it shows in the overall design.
- igouy 7y ago
  > …the state of the world for Smalltalk 80… Please look at chapter 23,"Smalltalk-80 The Interactive Programming Environment" (system change set, change-management, conflict resolution). > …only Smalltalk VM running on a given system… I remember running side-by-side Smalltalk images on the same system (one with Windows UI look and one with Mac UI look -- so I could tell which was which) in 1994. > …which got in the way of distribution, particularly if you wanted to run on different hardware. Let's say you'd been developing on a Mac and wanted to show on a Windows machine: you simply installed the Windows VM on the Windows machine, and copied your image file (and change log) from the Mac to the Windows machine — done. > …rarely clear where your classes ended, and the system ones began… Prefixing class names was a common way to make it really clear which were your classes.
  - monocasa 7y ago
    You're talking to someone who implemented a Smalltalk 80 VM. >Please look at chapter 23,"Smalltalk-80 The Interactive Programming Environment" (system change set, change-management, conflict resolution). It was still a huge pain in the ass compared to other systems. >I remember running side-by-side Smalltalk images on the same system (one with Windows UI look and one with Mac UI look -- so I could tell which was which) in 1994. So 14 years of Moore's law later, you could run two. My point was directed at the early eighties. Matching the OPs description of ST and first PC. >Let's say you'd been developing on a Mac and wanted to show on a Windows machine: you simply installed the Windows VM on the Windows machine, and copied your image file (and change log) from the Mac to the Windows machine — done. You were heavily encouraged to modify the base image to support different machines in the early eighties. Moving an image from.one hardware watch to another didn't practically work quite a bit of the time. Stuff like the screen resolution was hardcoded into the images, so you'd just be met with a blank or unintelligible screen if you tried. >Prefixing class names was a common way to make it really clear which were your classes. And if you had any dependencies that really broke down.
    - igouy 7y ago
      > You're talking to someone who implemented a Smalltalk 80 VM. Do you mean yourself or do you mean thelazydogsback ? > …compared to other systems. Depends which other systems were actually available where you were working. *> So 14 years of Moore's law later…" Wasn't the problem insufficient installed memory?

saijanai 7y ago

Simply use the squeak VM as your starting point. If there is a C compiler and sufficient memory to hold the image, all of squeak can be ported to a new processor in a few week. Alan Kay's original Smalltalk team did that with the MIckey Mouse PDA when they were working at Disney — they knew who they would be working for next and so named the opensource Smalltalk-80 project at Apple "Squeak" in honor of that venerable old mouse. Even after the team left Disney, the name stuck (and now you know the rest of the story).