Smalltalk Squeak 6.0(raw.githubusercontent.com) |
Smalltalk Squeak 6.0(raw.githubusercontent.com) |
Nice to see Sista finally seeing the light of the day. Hope it will be available Pharo as well, by the next release. That's awesome!
This requires new bytecodes, like unchecked fast primitive calls, so that sista can have Cog generate better binaries.
https://www.researchgate.net/publication/280793584_A_bytecod...
For those unaware, Squeak linage descends directly from the last Xerox Smalltalk-80 images before being bootstraped.
There are two zombie processes (OID 6662 and 19ba). There are also a couple of BlockContext and MethodContext which have a nil sender and a reference to an unknown method, but which are still referenced from somewhere (i.e. the collection is prevented, even with mark & sweep). E.g. OID 79a2 of class BinaryChoice. I have a full list if anybody is interested.
Also check out https://Squeak.slack.com for a nice discussion group.
> This is the first Squeak that supports high-resolution displays on all major platforms and offers a flexible UI scale factor through improved support for TrueType fonts.
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.
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 KayWhile 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.
That used-to-be my feeling too.
Now I have more appreciation of the amount of archaic baggage that is dragged into discussion once the label Smalltalk is attached :-)
The fact that Emacs has been in use (for decades) as a tool aimed at primarily solving everyday problems, means that it's been optimized for practicality to a ridiculous extent. That's not the case with Squeak, since it still has a very strong academic/research focus and a much smaller userbase than Emacs.
That's not to say that Squeak is useless, I'm a hardcore Emacs user and I do use Squeak too, but it's nowhere near as practical. It does however offer by far the best environment to experiment with Smalltalk and image-based development.
On the other hand, I don't recommend Pharo, as I found it even less practical than Squeak with frequent braking changes and a -seemingly- complete lack of focus that has pulled the project in widely different directions over the years. At least, Squeak is cohesive and hasn't broken with Alan Kay's vision.
Nonsense! Pharo's focus is to make writing Pharo more Pharo and easier for Pharo users. Mind, if your app isn't a Smalltalk VM and IDE, then, yea, it's full of tumult and turmoil. Aren't they on their 3rd or 4th GUI toolkit rewrite now? I mean, credit where credit is due, they eat their own dog food to be sure, but as a meal, that's just not as inviting to others.
> At least, Squeak is cohesive and hasn't broken with Alan Kay's vision.
He shipped enterprise code this way. Implementation language was Perl.
I feel that every time I reach for the mouse a kitten dies in some distant universe far far away.
With Emacs I am less concerned with editing than managing my work related data and work flow, and still think Smalltalk is better for it. I see myself getting back to Smalltalk after I get some more experience with Emacs.
Both Emacs and Smalltalk though are in serious need of native SQL or some kind of good database support not for applications but managing the workspace itself. You can only get so far with plists, collections, hash tables and what nots.
Even the org-roam guys have switched to SQLite to manage the data.
It certainly seems possible and could potentially make for a great IDE foundation, I just haven't seen it done, other than the Glamorous Toolkit - https://gtoolkit.com
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
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 objects being like biological cells and/or individual
messaging came at the very beginning -- it took a while to see how to
do messaging in a programming language efficiently enough to be
useful)."
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
But maybe he put a lot of work into it to be a better Perl editor.
> … no algorithm that can identify all dead code reliably…
Why were you so concerned with the removal of all dead code?
Compared to "… nobody had the source code…" it seems like a minor issue.
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" ?
imo the more usual concern would be mistakenly removing code that was not dead.
Without a design document, we might think there would be no senders of #factorial without understanding that the intention was to invoke that method on the command line.
For example,
$ cat fact.st
Stdio stdout
nextPutAll: 100 factorial printString;
nextPut: Character lf.!
SmalltalkImage current snapshot: false andQuit: true!
$ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
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.
!
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.
Is that something you wish to claim I do? :-)
(At some point, we might question whether we're putting similar effort into testing other software tools.)
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...
Oh well.
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.