The Rise and Fall of Commercial Smalltalk • Hacker News Board

Re: The Rise and Fall of Commercial Smalltalk

#131

Post by codefrau » Fri, Jun 05, 2020, 12:07 AM UTC

klipt wrote: post #128

hodgesrm wrote: post #11

Earlier quoted context omitted.

Smalltalk was inspirational, but the environment was a double-edged sword. In ParcPlace Smalltalk even things like stack frames were editable classes. One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM. BTW another brilliant innovation of Smalltalk was incremental compilation. Edit a method, save, and it was instantly part of the runtime. It must…

> One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM Sounds like these live environments didn't support version control or reproducibility in the modern sense then?

They did and do support version control etc. E.g. even Smalltalk back in the day kept a log of every single change of code in what's called a "changes" file.

"Corrupting the VM" just means that you were editing the stack frame class in the live system running on the VM and as soon as you hit "save", the VM crashes. So you simply run it again. And if needed, replay the changes log up to before the crashing change.

This only takes seconds, and is part of the reason why Smalltalk is so productive.

Re: The Rise and Fall of Commercial Smalltalk

#132

Post by codefrau » Fri, Jun 05, 2020, 12:29 AM UTC

allenwb wrote: post #130

jecel wrote: post #32

Those are all very good points. Since Allen was there and I was not he is in a far better position to know. But my impression was that the Smalltalk group had been reasonably happy with their 8086 based NoteTaker computer and expected their partners (HP, Tektronix, Apple and DEC) to use commercial processors instead of designing custom ones. Even if they were far slower than the Xerox Dorado. About Squeak in a web br…

Dan Ingalls talks about Notetaker/Smalltalk-78 in his forthcoming HOPL 4 paper which should be available within the next two weeks. There were only a few Notetaker machines built and apparently they were quite slow and not really very useful. But the Notetaker image and VM was also ported to the Dorado. In 1979-80 that was the primary version that was being used within the LRG and was used as the starting point for c…

Yep, I was surprised by the linear stack when I implemented the NoteTaker JS VM with Dan. In the Lively interface, you can stop the running VM and enable the two little checkboxes on the top right to see the whole stack, rather than just the current frame.

Re "the NoteTaker image and VM was also ported to the Dorado": both the NoteTaker image (a.k.a. Smalltalk-78) and the Dorado image were initially generated from Smalltalk-76 running on the Alto. In the Notetaker image there still are branches depending on what system it's running on (see e.g. UserView>>buttons).

Smalltalk-80 was also built on Smalltalk-76 by "backporting" some of the more interesting changes from the Notetaker version, plus adding much more.

Re: The Rise and Fall of Commercial Smalltalk

#133

Post by codefrau » Fri, Jun 05, 2020, 12:34 AM UTC

Rochus wrote: post #60

poulsbohemian wrote: post #41

For those of you smalltalk fans, what are you working in today / what would you prefer to be working in today given your history with smalltalk?

I'm not actually a "Smalltalk fan", but I recently re-implemented the Smalltalk-80 virtual machine and some additional tools to analyze the original Smalltalk-80 sources and virtual image files. My goal is to run it on LuaJIT and compare the performance with other Smalltalk implementations. See https://github.com/rochus-keller/Smalltalk . I'm also working on a Simula 67 compiler, and a Golang to LuaJIT bytecode compi…

Cool. If I had a few free weekends I'd want to make that Smalltalk image run on my SqueakJS VM. One of theses days ...

Re: The Rise and Fall of Commercial Smalltalk

#134

Post by Rochus » Fri, Jun 05, 2020, 1:06 AM UTC

codefrau wrote: post #133

Rochus wrote: post #60

Earlier quoted context omitted.

I'm not actually a "Smalltalk fan", but I recently re-implemented the Smalltalk-80 virtual machine and some additional tools to analyze the original Smalltalk-80 sources and virtual image files. My goal is to run it on LuaJIT and compare the performance with other Smalltalk implementations. See https://github.com/rochus-keller/Smalltalk . I'm also working on a Simula 67 compiler, and a Golang to LuaJIT bytecode compi…

Cool. If I had a few free weekends I'd want to make that Smalltalk image run on my SqueakJS VM. One of theses days ...

Have a look at http://www.squeaksource.com/Hobbes/, but don't expect impressive performance. It's not the code in the Bluebook part 4 though. If you want to implement it yourself be prepared that it might take many weekends until it runs as expected; debugging Bluebook errors took many hours.

Re: The Rise and Fall of Commercial Smalltalk

#135

Post by davidgould » Fri, Jun 05, 2020, 12:26 PM UTC

hodgesrm wrote: post #22

fulafel wrote: post #13

Earlier quoted context omitted.

What happened then, did it get rewritten in Java?

No, the project got cancelled before Java showed up. Sybase pretty much went down the tubes after that as a major DBMS vendor. Not because our project failed, but because Sybase had a dud release in 1993 named System 10 that had serious quality problems and tanked sales.

As I recall, there were a few "ambitious" projects on the UI side, application builders or frameworks or something that were failing around then. I think there was a real loss of management focus on actual products in favor of chasing the next big thing. We also forgot to ship 4.8 (MP) for months as everyone jumped to 5.0 (aka System 10).

Re: The Rise and Fall of Commercial Smalltalk

#136

Post by davidgould » Fri, Jun 05, 2020, 12:29 PM UTC

e12e wrote: post #98

hodgesrm wrote: post #22

Earlier quoted context omitted.

No, the project got cancelled before Java showed up. Sybase pretty much went down the tubes after that as a major DBMS vendor. Not because our project failed, but because Sybase had a dud release in 1993 named System 10 that had serious quality problems and tanked sales.

Heh, so that's just after the split of what became ms sql server on the Microsoft side. https://en.m.wikipedia.org/wiki/Sybase > 1993: Sybase and Microsoft dissolve their partnership. Microsoft receives a copy of the SQL Server code base. (...) Sybase SQL Server version 4.2 and Microsoft SQL Server are identical. (...) From this point the products diverge as Microsoft includes more Windows features whilst Sybase adds…

Fun fact, I handled producing and validating the last source code SQL Server source code exchange between Sybase and MS.

Re: The Rise and Fall of Commercial Smalltalk

#137

Post by entha_saava » Sat, Jun 06, 2020, 2:13 AM UTC

pjmlp wrote: post #82

entha_saava wrote: post #73

I have a question to people who used smalltalk. Maybe I have read it somewhere but couldn't understand the unique advantage in modern day terms. What is so different in smalltalk that is not possible / easy in modern IDE+Debugger environments? Especially those with hot reload or 'Edit & Continue' features?

You have access to the full stack, whereas even on .NET and Java there is a certain separation between runtime and lets call it user space. On a proper Smalltalk environment, beyond a set of pre-defined VM intrinsics you can access and change everything, GC, JIT compiler, compiler, how the debugger works, IDE like features, you name it. Then it is very uniform, everything is an object, even it isn't implemented as su…

> you can access and change everything, GC, JIT compiler, compiler, how the debugger works, IDE like features, you name it.

Do you mind explaining what is use case for this?

Re: The Rise and Fall of Commercial Smalltalk

#138

Post by jecel » Sat, Jun 06, 2020, 4:31 AM UTC

codefrau wrote: post #132

allenwb wrote: post #130

Earlier quoted context omitted.

Dan Ingalls talks about Notetaker/Smalltalk-78 in his forthcoming HOPL 4 paper which should be available within the next two weeks. There were only a few Notetaker machines built and apparently they were quite slow and not really very useful. But the Notetaker image and VM was also ported to the Dorado. In 1979-80 that was the primary version that was being used within the LRG and was used as the starting point for c…

Yep, I was surprised by the linear stack when I implemented the NoteTaker JS VM with Dan. In the Lively interface, you can stop the running VM and enable the two little checkboxes on the top right to see the whole stack, rather than just the current frame. Re "the NoteTaker image and VM was also ported to the Dorado": both the NoteTaker image (a.k.a. Smalltalk-78) and the Dorado image were initially generated from Sm…

Didn't Digitalk Methods and Smalltalk/V also use a linear stack? Self did as well and to make that simpler they made using a block from a method that had already returned an error (an optimization that some have regretted).

About the NoteTaker being too slow to be usable, having used Squeak on 386 and 486 machines I am hardly shocked. On the other hand people would be being Osborn 1 a few years after the Notaker with just a fraction of the speed (but not trying to run Smalltalk, of course).

By the way, quite a bit of information about the NoteTaker on the web is wrong. So I was really glad when Bitsavers got hold of all the original material (mostly memos):

http://bitsavers.trailing-edge.com/pdf/xerox/notetaker/

Re: The Rise and Fall of Commercial Smalltalk

#139

Post by jecel » Sat, Jun 06, 2020, 4:53 AM UTC

allenwb wrote: post #130

jecel wrote: post #32

Those are all very good points. Since Allen was there and I was not he is in a far better position to know. But my impression was that the Smalltalk group had been reasonably happy with their 8086 based NoteTaker computer and expected their partners (HP, Tektronix, Apple and DEC) to use commercial processors instead of designing custom ones. Even if they were far slower than the Xerox Dorado. About Squeak in a web br…

Dan Ingalls talks about Notetaker/Smalltalk-78 in his forthcoming HOPL 4 paper which should be available within the next two weeks. There were only a few Notetaker machines built and apparently they were quite slow and not really very useful. But the Notetaker image and VM was also ported to the Dorado. In 1979-80 that was the primary version that was being used within the LRG and was used as the starting point for c…

Allen, thanks for confirming the microcode thing. It certainly wasn't the impression I had gotten from the green book, but history does tend to get cleaned up as it is retold.

To be fair to the PARC people other people had done Alto clones:

https://en.wikipedia.org/wiki/Lilith_(computer)

https://en.wikipedia.org/wiki/PERQ

I myself got into a graduate computer architecture course even though I was just an undergraduate so I could design a TTL microcoded Smalltalk computer. I was extremely disappointed to learn this was illegal and seriously considered moving away from Brazil at that time (1983, I think).

Re: The Rise and Fall of Commercial Smalltalk

#140

Post by em-bee » Sun, Jun 07, 2020, 7:52 AM UTC

stcredzero wrote: post #18

hodgesrm wrote: post #11

Earlier quoted context omitted.

Smalltalk was inspirational, but the environment was a double-edged sword. In ParcPlace Smalltalk even things like stack frames were editable classes. One of the first mistakes I made was trying to edit the stack frame class in a running VM. It immediately corrupted the VM. BTW another brilliant innovation of Smalltalk was incremental compilation. Edit a method, save, and it was instantly part of the runtime. It must…

BTW another brilliant innovation of Smalltalk was incremental compilation. Actually, Smalltalk compilation to bytecodes isn't incremental, from a certain point of view. The compiler finishes completely with bytecodes, usually instantly from the POV of the programmer. The compilation is complete. However, the binding is late. (Usually termed "late binding." You see, usually only one method has to be compiled at any gi…

the key feature i like here is that code can be changed and recompiled while an application is running.

when an error occurs, the application does not crash but freezes allowing me to fix the error and resume.

to the point that when the aplication is a website and an error occurs while a browser is accessing it, the loading of the page just stalls until the error is fixed, at which point it resumes without any user intervention from the browser side.