Live data from Hacker News

Smalltalk Squeak 6.0

raw.githubusercontent.com

61–70 of 73 posts

Re: Smalltalk Squeak 6.0

#61
post #53

Earlier quoted context omitted.

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.

Alan wanted what eventually became EToys for his Apple projects. They looked into doing it in Java but figured that digging the old Apple Smalltalk-80 out of the trash bin and cleaning it up would be less effort. So we got Squeak.

Then they did Etoys stuff at Disney and some other neat experiments. Then Alan moved on to 3D shared environments[1] and later to recreating personal computing in 20K lines of code[2]. The idea was to build it on top of Ian Piumarta's COLA[3][4] but to get something out the door they ended up using a stripped down version of Squeak instead. So moving on from Squeak is harder than Alan hoped.

[1] https://en.wikipedia.org/wiki/Croquet_OS

[2] http://www.vpri.org/pdf/tr2012001_steps.pdf

[3] http://www.vpri.org/pdf/rn2006001a_colaswp.pdf

[4] http://www.vpri.org/pdf/tr2006003a_objmod.pdf

Re: Smalltalk Squeak 6.0

#62
post #58
post #51

Earlier quoted context omitted.

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.

> … nobody had the source code … anymore…

!

Would we blame Ada tools because we did not archive the source code we wrote?

> … even with the source code it was a nightmare…

What I was "up to" was trying to get past sweeping condemnation to understandable criticism.

Re: Smalltalk Squeak 6.0

#63
post #62
post #58

Earlier quoted context omitted.

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.

> … nobody had the source code … anymore… ! Would we blame Ada tools because we did not archive the source code we wrote? > … even with the source code it was a nightmare… What I was "up to" was trying to get past sweeping condemnation to understandable criticism.

That was my personal impression as a trained engineer based on relevant experience, not a condemnation; I on the other hand find it annoying when some people glorify Smalltalk in retroperspective and attribute to it any great qualities without evidence and against better knowledge; nevertheless, the technology is impressive in a historical context and worth studying (but I still wouldn't use it for industrial projects anymore and would also not like to tempt other people).

Re: Smalltalk Squeak 6.0

#64
post #57
post #52

Earlier quoted context omitted.

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…

> We tested until our ears fell off…

And did you discover stuff that was reported to have been removed but your tests showed was not removed?

In other words, examples where "trust it" would be a demonstrable mistake.

> It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages.

What process was used to manage source code?

"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)

1984 "Smalltalk-80 The Interactive Programming Environment"

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

Re: Smalltalk Squeak 6.0

#65
post #64
post #57

Earlier quoted context omitted.

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…

> We tested until our ears fell off… And did you discover stuff that was reported to have been removed but your tests showed was not removed? In other words, examples where "trust it" would be a demonstrable mistake. > It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages. What process was used to manage source code? "At the outset of a project involving two or more pr…

Working with a team on industrial projects is another thing than quoting from a book that - albeit somewhat naively - even talks about configuration management in one section.

Re: Smalltalk Squeak 6.0

#66
post #63
post #62

Earlier quoted context omitted.

> … nobody had the source code … anymore… ! Would we blame Ada tools because we did not archive the source code we wrote? > … even with the source code it was a nightmare… What I was "up to" was trying to get past sweeping condemnation to understandable criticism.

That was my personal impression as a trained engineer based on relevant experience, not a condemnation; I on the other hand find it annoying when some people glorify Smalltalk in retroperspective and attribute to it any great qualities without evidence and against better knowledge; nevertheless, the technology is impressive in a historical context and worth studying (but I still wouldn't use it for industrial project…

> … annoying when some people glorify Smalltalk…

Is that something you wish to claim I do? :-)

Re: Smalltalk Squeak 6.0

#67
post #65
post #64

Earlier quoted context omitted.

> We tested until our ears fell off… And did you discover stuff that was reported to have been removed but your tests showed was not removed? In other words, examples where "trust it" would be a demonstrable mistake. > It is not for nothing that people speak of a "Big ball of Mud" in the context of image based languages. What process was used to manage source code? "At the outset of a project involving two or more pr…

Working with a team on industrial projects is another thing than quoting from a book that - albeit somewhat naively - even talks about configuration management in one section.

> Working with a team on industrial projects…

What process was used to manage Smalltalk source code?

Re: Smalltalk Squeak 6.0

#68
post #67
post #65

Earlier quoted context omitted.

Working with a team on industrial projects is another thing than quoting from a book that - albeit somewhat naively - even talks about configuration management in one section.

> Working with a team on industrial projects… What process was used to manage Smalltalk source code?

> Rather than simply trust, wouldn't we test?

How do you test for dead code?

Re: Smalltalk Squeak 6.0

#69
post #68
post #67

Earlier quoted context omitted.

> Working with a team on industrial projects… What process was used to manage Smalltalk source code?

> Rather than simply trust, wouldn't we test? How do you test for dead code?

Seems like you don't wish to say what process was used to manage Smalltalk source code on the project you describe as a "nightmare"?

Oh well.

Re: Smalltalk Squeak 6.0

#70
post #69
post #68

Earlier quoted context omitted.

> Rather than simply trust, wouldn't we test? How do you test for dead code?

Seems like you don't wish to say what process was used to manage Smalltalk source code on the project you describe as a "nightmare"? Oh well.

Why should I answer your questions when you only question everything I say anyway and do not answer my questions?

If you understood why the absence of dead code cannot be detected by testing, and that there is no algorithm that can identify all dead code reliably and in finite time in a dynamic language like Smalltalk, your questions and implications would become pointless, since you then would understand why you never can be completely sure indeed; and that's all there is to it.

Post reply on HN