Live data from Hacker News

Smalltalk Squeak 6.0

raw.githubusercontent.com

51–60 of 73 posts

Re: Smalltalk Squeak 6.0

#51
post #42
post #40

Earlier quoted context omitted.

For some meaning of "contain things it shouldn't": Given that the base image we started working with didn't "contain things it shouldn't" why could we not be completely sure that base image + source code fileIn didn't "contain things it shouldn't" ?

First, as most other companies using ST we were not working on the original image, but on a company-specific one that had been in use for a long time and contained a lot of company-specific stuff. On the other hand, there were also things in the original images of the commercial STs that one would or should not ship with the product.

Firstly:

company-specific base image = base image + company-specific source code fileIn

Why could we not be completely sure that company-specific base image + source code fileIn didn't "contain things it shouldn't" ?

Secondly:

> … also things in the original images of the commercial STs that one would or should not ship with the product.

That doesn't seem to be an example of "You could never be completely sure that it didn't contain things it shouldn't."

That seems to be an example of you being completely sure.

Re: Smalltalk Squeak 6.0

#52
post #47
post #45

Earlier quoted context omitted.

Which is why image trimming tools did exist.

I had Envy in later projects, which was very useful, but you simply had to trust it, which is not the same as to be completely sure.

Rather than simply trust, wouldn't we test?

(At some point, we might question whether we're putting similar effort into testing other software tools.)

Re: Smalltalk Squeak 6.0

#53

Shouldn't this be Squeak Smalltalk 6.0? I'm glad that Squeak continues to embrace the Smalltalk name, community, and history - and doesn't take the Pharo approach of trying to pretend that they aren't Smalltalk.

No, it should not: A couple of years ago, we started this project called Squeak, which is simply not an attempt to give the world a free Smalltalk, but an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk, and when you fool around Squeak, please, please, think of it from that standpoint. -- Alan Kay

But that "better than Smalltalk" would not be Squeak, so I still present the system to people as "Squeak Smalltalk".

While the goal of Pharo is to encourage research even while breaking compatibility (possibly making it not Smalltalk at some point in the future), Squeak is way more conservative. The various SqueakFest events that happened were actually mostly about EToys used by children and teachers and at least some in the Squeak community have keeping that running a priority.

Personally I do use Squeak to research future languages as Alan intended, and it is also a great tool for that.

Re: Smalltalk Squeak 6.0

#55
post #23
post #9

> Switches the default bytecode set to SistaV1. This lays the basis for a new generation of VM optimizations (Sista: Speculative Inlining Smalltalk Architecture). With Sista, blocks are represented by CompiledBlocks and instantiated as FullBlockClosures, the stability of which has been improved in the course of this switch (fixed bugs in FullBlockClosure >> #= and InstructionStream >> #scanForInstructionSequence:). P…

My understanding is that the optimizations haven't been implemented yet in the VM, but that this initial step is to enable the new bytecodes. Could be wrong.

The idea in sista is to do all fancy optimizations in the image by translating bytecodes to different bytecodes. The VM (called Cog, in this case) just has to translate the bytecodes to native binaries on demand.

This requires new bytecodes, like unchecked fast primitive calls, so that sista can have Cog generate better binaries.

Re: Smalltalk Squeak 6.0

#56
post #9

> Switches the default bytecode set to SistaV1. This lays the basis for a new generation of VM optimizations (Sista: Speculative Inlining Smalltalk Architecture). With Sista, blocks are represented by CompiledBlocks and instantiated as FullBlockClosures, the stability of which has been improved in the course of this switch (fixed bugs in FullBlockClosure >> #= and InstructionStream >> #scanForInstructionSequence:). P…

Is there a specification for the SistaV1 bytecodes?

This paper compares the "blue book style" bytecodes (also known as V3 bytecodes) with the new ones used by sista:

https://www.researchgate.net/publication/280793584_A_bytecod...

Re: Smalltalk Squeak 6.0

#57
post #52
post #47

Earlier quoted context omitted.

I had Envy in later projects, which was very useful, but you simply had to trust it, which is not the same as to be completely sure.

Rather than simply trust, wouldn't we test? (At some point, we might question whether we're putting similar effort into testing other software tools.)

We tested until our ears fell off; in particular, we had also to test all the stuff that the compiler (or linker) would otherwise have told us in a statically typed language; there was no other way; might explain why I directly switched to Ada for some time after ST; but how do you test for dead code (i.e. things in the image not used but still there for some reason)? It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages.

Re: Smalltalk Squeak 6.0

#58
post #51
post #42

Earlier quoted context omitted.

First, as most other companies using ST we were not working on the original image, but on a company-specific one that had been in use for a long time and contained a lot of company-specific stuff. On the other hand, there were also things in the original images of the commercial STs that one would or should not ship with the product.

Firstly: company-specific base image = base image + company-specific source code fileIn Why could we not be completely sure that company-specific base image + source code fileIn didn't "contain things it shouldn't" ? Secondly: > … also things in the original images of the commercial STs that one would or should not ship with the product. That doesn't seem to be an example of "You could never be completely sure that i…

Not sure what you're up to; there were things in the image nobody had the source code (or the current version) anymore, but even with the source code it was a nightmare; it would undoubtedly have been less bad had I then had tools like I recently built for ST80 and the knowledge gained with them.

Re: Smalltalk Squeak 6.0

#59

Earlier quoted context omitted.

I mean, Kay was a biologist :)

Haha. Alan Kay wrote: "At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me what I was doing, and I said: "It's object-oriented programming". The original conception of it had the following parts. - I thought of objec…

It's interesting to note that he explicitly mentions "November 1966" and also refers to Simula. The ACM paper about Simula I appeared in September 1966 (see https://dl.acm.org/doi/10.1145/365813.365819), so he might have read it. Simula (or Simula I as it is called today) was a language to support discrete event simulation and had active objects (called "processes") for that purpose which "sent events" to each other (i.e. the process is activated at the event time). The language was already presented in 1962 at the second international conference on information processing held in Munich. The actually "object-oriented" Simula version with classes, inheritance and virtual methods appeared in 1967. Kay's vision applies to Smalltalk-72 to some degree, but Smalltalk-76 then also switched to inheritance and compiled virtual methods.

Re: Smalltalk Squeak 6.0

#60
post #53

Earlier quoted context omitted.

No, it should not: A couple of years ago, we started this project called Squeak, which is simply not an attempt to give the world a free Smalltalk, but an attempt to give the world a bootstrapping mechanism for something much better than Smalltalk, and when you fool around Squeak, please, please, think of it from that standpoint. -- Alan Kay

But that "better than Smalltalk" would not be Squeak, so I still present the system to people as "Squeak Smalltalk". While the goal of Pharo is to encourage research even while breaking compatibility (possibly making it not Smalltalk at some point in the future), Squeak is way more conservative. The various SqueakFest events that happened were actually mostly about EToys used by children and teachers and at least som…

I personally think that one reason why Alan lost his interrest in Squeak was partly based on the community that was too conservative and too much Smalltalk-80 oriented - while Smalltalk does not fit into his vision well already since 1976.
Post reply on HN