3 ms·

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

by jecel 6y ago

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 browser, it was a completely different project than the current SqueakJS. Alan was frustrated that the IT people at schools wouldn't allow Squeak to be installed on their machines. So the native code VM was bundled into a plugin for the then popular web browsers and it became as easy to use Squeak as Flash. Except that the IT people allowed Flash but not Squeak so it ended up not helping. But in terms of performance it was better than Flash, Java (not Hotspot) or Javascript.

radiowave 6y ago
Yes, my recollection of the Squeak browser plugin was that the performance was indistinguishable from running regular Squeak, several orders of magnitude better than SqueakJS. And the startup time was vastly better than any Java plugin code. However, if you were on dial-up, and your browser didn't already have a cached copy of the smalltalk image, then you were in for a quite a wait. (Though no doubt this could have been addressed - there were people arguing at the time for the creation of a much smaller Squeak image, but a combination of the lack of a clear goal to motivate this work, and the fact that for most existing users it was a non-issue, meant that nothing came of this within the timeframe where it might have made a difference.) But it may be that this is all moot, because it could be argued that any browser-plugin deployment model would ultimately fail.
- russellallen 6y ago
  I used the Squeak browser plugin with a class of university students in the late 90s - it worked really well. Native speed, much more interactive GUI than the browsers at that time, and I could update their essentially desktop app between classes and not have to get it reinstalled by IT. I did have to do some persuading to get IT to install the plugin in the first place though. It was doomed tech in hindsight though, together with all the other plugins.
allenwb 6y ago
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 creating Smalltalk-80. In my article is a link to the the invitation letter to Tektronix to participate in the Smalltalk-80 dissemination processed. In it they said: "We estimate about one work year for a very expert systems programmer to implement the microcode for the virtual machine and implement the i/o primitives." In the following discussions and visits they only showed us and talked about the microcoded Dorado and Dolphin implementations. They we repeated said words to the effect of "We want you to design a computer to run Smalltalk". LRG was quite secretive about some things and I don't think I had ever heard of Notetaker until 1993 when I read Alan's HOPL-2 paper. One interesting thing I recently learned from Dan was that NoteTaker used a linear stack with overlapping activation records. This was dropped for the Dorado implementation and Smalltalk-80. That was unfortunate as the overhead of heap allocated stack frames was one of the major performance bottlenecks when implementing Smalltalk-80 on conventional processors. It took those of us doing such implementations a couple years to develop techniques for "cheating without getting caught" while using hidden linear stacks. In retrospect, the poor performance of Smalltalk-80's heap allocated activation contexts in combination with reference counting significantly delayed the viability of microprocessor based Smalltalk-80 implementations.
- codefrau 6y ago
  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.

by jecel 6y ago

radiowave 6y ago

Yes, my recollection of the Squeak browser plugin was that the performance was indistinguishable from running regular Squeak, several orders of magnitude better than SqueakJS. And the startup time was vastly better than any Java plugin code. However, if you were on dial-up, and your browser didn't already have a cached copy of the smalltalk image, then you were in for a quite a wait. (Though no doubt this could have been addressed - there were people arguing at the time for the creation of a much smaller Squeak image, but a combination of the lack of a clear goal to motivate this work, and the fact that for most existing users it was a non-issue, meant that nothing came of this within the timeframe where it might have made a difference.) But it may be that this is all moot, because it could be argued that any browser-plugin deployment model would ultimately fail.

russellallen 6y ago
I used the Squeak browser plugin with a class of university students in the late 90s - it worked really well. Native speed, much more interactive GUI than the browsers at that time, and I could update their essentially desktop app between classes and not have to get it reinstalled by IT. I did have to do some persuading to get IT to install the plugin in the first place though. It was doomed tech in hindsight though, together with all the other plugins.

allenwb 6y ago

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 creating Smalltalk-80. In my article is a link to the the invitation letter to Tektronix to participate in the Smalltalk-80 dissemination processed. In it they said: "We estimate about one work year for a very expert systems programmer to implement the microcode for the virtual machine and implement the i/o primitives." In the following discussions and visits they only showed us and talked about the microcoded Dorado and Dolphin implementations. They we repeated said words to the effect of "We want you to design a computer to run Smalltalk". LRG was quite secretive about some things and I don't think I had ever heard of Notetaker until 1993 when I read Alan's HOPL-2 paper. One interesting thing I recently learned from Dan was that NoteTaker used a linear stack with overlapping activation records. This was dropped for the Dorado implementation and Smalltalk-80. That was unfortunate as the overhead of heap allocated stack frames was one of the major performance bottlenecks when implementing Smalltalk-80 on conventional processors. It took those of us doing such implementations a couple years to develop techniques for "cheating without getting caught" while using hidden linear stacks. In retrospect, the poor performance of Smalltalk-80's heap allocated activation contexts in combination with reference counting significantly delayed the viability of microprocessor based Smalltalk-80 implementations.

codefrau 6y ago
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.