Live data from Hacker News

Smalltalk Squeak 6.0

raw.githubusercontent.com

21–30 of 73 posts

Re: Smalltalk Squeak 6.0

#21
post #11
post #3

Nice to see it still going. For those unaware, Squeak linage descends directly from the last Xerox Smalltalk-80 images before being bootstraped.

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.

I’m reminded of junk DNA.

Re: Smalltalk Squeak 6.0

#22
post #15
post #11

Earlier quoted context omitted.

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…

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.

Re: Smalltalk Squeak 6.0

#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.

Re: Smalltalk Squeak 6.0

#24

Could a developer use Squeak as an emacs replacement?

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

Interesting statement, given that modern IDEs trace back to Lisp and Smalltalk graphical workstations.

Re: Smalltalk Squeak 6.0

#25
post #22
post #15

Earlier quoted context omitted.

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…

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.

Deploying an application was always an adventure. You could never be completely sure that it didn't contain things it shouldn't.

Re: Smalltalk Squeak 6.0

#26
post #24

Earlier quoted context omitted.

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

Interesting statement, given that modern IDEs trace back to Lisp and Smalltalk graphical workstations.

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.

Re: Smalltalk Squeak 6.0

#27
post #11

Earlier quoted context omitted.

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.

I’m reminded of junk DNA.

I mean, Kay was a biologist :)

Re: Smalltalk Squeak 6.0

#28

Could a developer use Squeak as an emacs replacement?

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.

Re: Smalltalk Squeak 6.0

#29
post #14

Earlier quoted context omitted.

I once worked with a guy who did all his coding in Squeak the way some do in Emacs. He shipped enterprise code this way. Implementation language was Perl.

That seems incredibly odd lol. What advantage does that have over Notepad++?

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.

Re: Smalltalk Squeak 6.0

#30
post #14

Earlier quoted context omitted.

I once worked with a guy who did all his coding in Squeak the way some do in Emacs. He shipped enterprise code this way. Implementation language was Perl.

That's wild. I've been wanting to do the same thing with Ruby for years.

Well, that makes sense, since Ruby is the cronenberg that emerged from mashing Perl and Smalltalk together...
Post reply on HN