Comment by thelazydogsback | Hacker News Reader

Comment by thelazydogsback | Hacker News Reader

thelazydogsback

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

> …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/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 ?

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.

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

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.

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

>Do you mean yourself or do you mean thelazydogsback ?

Myself.

>Depends which other systems were actually available where you were working.

Diff is from the 70s and by the time Smalltalk existed had been ported to everything under the sun. Having done both I really prefer making text files the canonical copy.

>Wasn't the problem insufficient installed memory?

For the most part. That's sort of my point, more than a meg was crazy town, and systems went to crazy lengths to accommodate that.

Moore's Law applies to memory, there's a transistor on each DRAM bit (and technically a capacitor, but DRAM these days relies on the parasitic capacitance of the transistor, so these days DRAM is just a sea of transistoslrs for the most part).

> Myself.

(Genuine question) As "someone who implemented a Smalltalk 80 VM" how much of that effort involved code management in Smalltalk?

> Having done both I really prefer making text files the canonical copy.

Change sets are saved as text files, the change log is a text file, sources is a text file …?

> There wasn't a clear seperation between the system itself and whatever you were working on.

Another serious issues is that people routinely modified the system classes. Once you had imported a few large libraries there would be any number of changes to classes like Object that would cause the libraries to mis-behave if they went missing or were changed. As nice as it was to be able to mod anything, I think it hurt reliability.

Totally. It's super freeing compared to other systems of the time where there was this strict delineation between what you could and couldn't modify, but I'm glad we ended more in a middle ground between the two.

> …people routinely modified the system classes.

People!

What can be done?

— reject libraries that change system classes?

— accept that library version G is said to work with system version F, and may not work with system version Q?

— accept that along with library source code comes the burden of resolving library conflicts?

Squeak 3.3 was an effort to evolve into a modular system that would address most of your complaints, but it was abandoned and 3.4 was based on the monolithic 3.2 instead.

Smalltalk V/Win from the early 1990s, on the other hand, did a pretty good job. Your image was saved as v.exe which started out essentially empty while the actual VM and the system classes were stored in a bunch of immutable .dll files. As you developed in the same style as in any other Smalltalk, the v.exe file would grow and grow with all the stuff that was particular to your application. You would then distribute that plus a subset of the .dll files (those needed to run you application but not to develop it).

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

Reply on news.ycombinator.com