> 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:). Provides new encoding accessors.
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!
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.
Don't know if it's true, but it makes a fun story: ST80 used reference counting with counts saturating at some low number (like 127), and of course there are problems collecting circular references. A comprehensive analysis of a modern image, with Xerox PARC lineage, discovered garbage that had been uncollected for 20-30 years.
It is true, that there is uncollected garbage in the original Xerox ST80 image. I've built some tools to analyze the image and also a VM which can be interrupted at any time to analyze the current state of the image (see https://github.com/rochus-keller/Smalltalk).
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.
It's things like this that always made me look a bit askance at Smalltalk. It feels a little like "Document_Final_FINAL_v3_(2).docx", a little like a dirty old whiteboard where you can still see outlines of notes from last year. Might not be a fair assessment, but as an outsider I've always felt this way about image-based systems.
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 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.
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.
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).
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.
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"
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.
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.
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.
This file is part of the build system, and the text is meant to be read within the Squeak IDE, so it's going to look a little weird on the web. If you scroll all the way to the bottom, there's a bunch of code for styling the text, opening and arranging windows, setting up the menu bar etc.
Lovely to see the new Squeak release on here. There are some really exciting new third party things happening too, such as a visual Smalltalk editor called Sandblocks. I made a demo of it here: https://www.youtube.com/watch?v=jnbSocgf-xc
> 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.
You can try - I certainly did - but it's inferior, in nearly every way: performance most of all, usability, interfacing with the host OS, availability of libraries, APIs, interactive documentation, discoverability, customization..
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.
> 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.
There is a Glamorous Toolkit (Pharo not Squeak) project called Lepiter that is conceptually similar in a lot of ways to org-roam and org-babel. It comes with support for working with Javascript and a couple other languages. That might be of interest depending on how you spend most of your emacs time. (I agree that in a dream alternate reality something like full-on emacs would have grown out of Smalltalk.)
If Ruby had ever come up with a Pharo-like coding environment then I would have already done it. But just trying to find a simple-enough editor written in Ruby to build on is tough.
Presumably he could write his own code- and data-munging tools in Smalltalk and invoke them straight from the running image -- kinda like what you can do with Emacs Lisp.
That's fascinating. At least Emacs comes with an editor, can't say as much for Squeak. I mean, it has AN editor, its just not very good compared to something like Emacs or vi, and I'm talking editor functionality, not everything else. It's more like a lightly enhanced Text Area.
But maybe he put a lot of work into it to be a better Perl editor.
For them, presumably the same thing that emacs has over Notepad++ for me (though not IDEs, universally, just most editors). Emacs (as an environment) is almost fully extendable in user code with much greater ease than most other editors. And not just in a "write this plugin, place it in the right directory, and restart the editor" sense. In the more extreme sense of you can extend it live, even just temporarily. Squeak, as an environment, is very similar to that experience, probably even more extreme than what emacs offers in some ways. If it had a larger community behind it (to use in this style), I'd certainly entertain it.
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.
That's a thought that pops up regularly whenever I run into Pharo/Squeak. They seem to have a more homogeneous system from top to bottom. The graphical layer of emacs is really "small" and restricted.
I have not seen Squeak (or other Smalltalk environments, e.g. Pharo) being used like and IDE, which is what I infer you mean by "developer... emacs replacement".
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
Clarification: I meant using those environments for other languages, like people do with emacs, which is what I inferred the person I responded to was asking.
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 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.
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.
What is the block of code starting under the "THANK YOU ALL FOR YOUR CONTRIBUTIONS" line? Is that an easter egg of sorts that would show up if run inside Squeak?
Not really an Easter egg, just the normal release process. That code basically sets up the GUI for the released image - sets up the menubar, opens and arranges windows, etc. The release notes at the top will get styled and appear in a window in the IDE.
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!