Hacker News new | past | comments | ask | show | jobs | submit login

On my first contact with Squeak it occurred to me that, since the whole image was "alive", I could:

    True := False
The system immediately locked up.

Running the analogous

    ln -sf /dev/zero /lib/x86_64-linux-gnu/libc.so.6
will have an analogous effect on an "alive" Unix image. I mean, a Unix machine. :-)

Incidentally, in the latest Squeak,

    True := False.
doesn't work -- the compiler complains that you can't assign into a read-only variable. So let's try this:

    Smalltalk at: #True put: False.
But now the metaprogramming system complains you're trying to modify a read-only binding! So we view source on ClassBinding>>value:, and see that a resumable exception is being used to guard the modification, so let's explicitly signal that we REALLY want to modify that binding:

    [Smalltalk at: #True put: False]
      on: AttemptToWriteReadOnlyGlobal
      do: [:ex | ex resume: true].
Finally! Now, evaluating "True" yields "False".

But the image keeps running! Use of the literal class True seems to be rare enough that things are OK for at least several minutes after the change.

Doing this, however, definitely should immediately torpedo things:

    true become: false.
... huh. It didn't work. It used to! Again, on this current Squeak version, we see a different behaviour. This time, it says "Cannot execute #elementsExchangeIdentityWith: on read-only object #(false)".

So we'll have to try harder:

    true becomeForward: false.
That doesn't work either! Same error as for #become:.

Welp, I'm actually all out of ways to crash this modern image in analogous ways to the easy pitfalls of images of yesteryear...

That used to be the case with JavaScript too - until recently (ECMAScript 2015, IIRC?) you could do `undefined = null;` and other fun things like overwrite the `Array` constructor (which became a particularly nasty JSON attack vector).

> like overwrite the `Array` constructor (which became a particularly nasty JSON attack vector).


I've heard about things like that.

Wouldn't such redefinition make more sense to be isolated in a newly spawned universe? That way the whole system would not collapse yet you could still play with such concepts.

Yep! Absolutely. Just like Unix VMs (and containers, etc.): recursive whole-system composition makes perfect sense. Smalltalk hasn't been taken in that direction yet by anyone, though, as far as I know.

There are two things I'd like to do with Smalltalk. That's one, and the other is giving each object a thread-like construct and make all execution asynchronous apart from dependencies.

I tried this in the late 1990s with my tinySelf version 1 experiment:


It worked great but still had bugs when I got sidetracked by a completely different project so it was never finished.

Very cool. Re that latter, you might be interested in https://tonyg.github.io/squeak-actors/, which is similar (but not uniformly asynchronous).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact