The next meeting of the UK Smalltalk User Group will be on Wednesday, July
30th.
Russell Allen will talk to us about Self ( https://selflanguage.org/ ).
Dating back to the late 1980s, Self is a prototype based programming
language and environment in the broader Smalltalk family. Although Self has
always been a niche research system, its influence can still be seen in
areas as diverse as the fast VMs of Java and Javascript, in the prototype
semantics of Javascript, and in the Morphic user interface used by Squeak,
Pharo and Cuis.
Russell Allen ( https://twitter.com/russell_allen_ ) has a background in
law and computers and first came across Self in the late 1990s. Around 2008
he helped get Self running on Linux x86, set up the Self website and GitHub
account, and for the last decade or so he has been helping keep Self as a
project alive.
In this talk, Russell will demonstrate Self as a running system, including
the object semantics, language, and the multi-user Morphic development
environment. He’ll talk about the current status of the project and the
challenges it faces for the future.
Given the current COVID-19 restrictions, this will be an online meeting
from home. Please note that the meeting will start later than usual, to
accommodate the speaker who will connect from Australia.
If you'd like to join us, please sign up in advance on the meeting's Meetup
page ( https://www.meetup.com/UKSTUG/events/cbklbrycckblc/ ) to receive the
meeting details. Don’t forget to bring your laptop and drinks!
The next meeting of the UK Smalltalk User Group will be on Wednesday,
August 25th.
Marcus Denker will talk about Variables in Pharo.
We like to say that “Everything is an Object” in Smalltalk. This is true in
many cases: Classes, methods, even the execution stack are reflectively
available as objects.
This talk shows how this idea can be extended to Variables and how Pharo
implements first-class Variables for Globals, instance Variables, Class
Variables, and even temporary variables.
This presentation explores the Variable hierarchy, shows how variables
simplify the compiler and how the reflective API provided by variables is
used by the debugger.
In a hands-on tutorial, we extend the language by defining new kinds of
Variables.
Marcus ( https://marcusdenker.de/ ) is a permanent researcher at INRIA
Lille - Nord Europe ( http://www.inria.fr/lille/ ). Before, he was a
postdoc at the PLEIAD lab/DCC University of Chile and the Software
Composition Group, University of Bern. His research focuses on reflection
and meta-programming for dynamic languages. Marcus Denker received a PhD in
Computer Science from the University of Bern/Switzerland in 2008 and a
Dipl.-Inform. (MSc) from the University of Karlsruhe/Germany in 2004. He
co-founded Zweidenker GmbH ( https://zweidenker.de/ ) in 2009.
Given the current COVID-19 restrictions, this will be an online meeting
from home.
If you'd like to join us, please sign up in advance on the meeting's Meetup
page ( https://www.meetup.com/UKSTUG/events/cbklbrycclbhc/ ) to receive the
meeting details. Don’t forget to bring your laptop and drinks!
The discussion in the other thread is very interesting (thanks Russell
and Nicklas for the descriptions of your projects!) but I realised that
it is about strategies and unless we agree on the goals then we will be
talking past each other.
Here are some example goals:
- a living museum exhibit
People would be able to experience Self as it was when it came out. This
has a serious educational value. Back in 2000 I met a professor who
taught a course on programming languages and he dedicated two full
lessons to Self. I invited him to visit my office and gave him a demo of
the language and he was completely shocked. I showed him outliners for
doubly linked lists updating themselves as we tried different
expressions as well as the GUI demos. He was teaching his students all
the technical details about Self but could not imagine was the
experience of actually using it was like.
Alan Kay and Long Tien Nguyen imagined a way that people decades from
now might experience was Smalltalk-72 was like:
http://www.vpri.org/pdf/tr2015004_cuneiform.pdf
Dan Ingalls and friends have brought back to life old Smalltalks so
people can try them out instead of just reading about them:
https://smalltalkzoo.thechm.org/
- fun with retrocomputing
Some people like to mix the convenience of the current world with the
interesting stuff from the past. So they might have a Commodore 64
computer but load the software from a SD Card instead of audio tape.
When playing around with Smalltalk-78 the group was amazed at how
practical it was given current screen resolution and memory sizes, so
they decided to fix things that had been originally been left unfinished
and to add a bit of new functionality.
Russell's efforts with ourself.io and new code he is adding to the
snapshot is very much like this.
- back to life
Apple did very little with the Smalltalk it got from Xerox for
participating in the project with DEC, HP and Tektronix. It just sat
there bitrotting until the Squeak project. It gained sound, color and
networking to start with. Certainly Self could do the same and become an
alternative to Squeak/Cuis/Pharo.
This would require better integration with the current computing world
as well as enhancements. The privacy thing was set aside in Self 3, for
example, with the idea that it would later "be done right" in Us (or
Korz).
What other goals would make sense for Self?
-- Jecel
Russell's talk this past Wednesday was really great! I liked the idea of
starting of with a demo building a slide viewer to use for the rest of
the talk.
One of the slides was about options for moving the VM forward. I
remember at least some of the alternatives - please add any that I
forgot.
I would mention that a very significant reason Self never became popular
was that it didn't run on machines people had (a problem shared with
nearly all the Unix clones that came before Linux). This was why many
people wrote their own Self variations or Self inspired languages in the
early days. I actually bought a Sun Ultra 5 machine in 1998 (the most
money I have spent in my life so far) so I could continue to use Self
after I moved away from the University. Just a few years later with Self
running on PowerPC Macs and later x86 Macs and Linux machines people
could finally try Self. Sadly, they didn't because of the silly idea
that only things coming out right now are worth looking into. With
everybody moving to x86-64 and now also Apple ARM we are back where we
started! So how do we fix this?
- changing the C++ VM to handle 64 bits and target the currently
popular processors
During the talk I mentioned the lack of progress in the StrongTalk VM as
an example of how hard this is because you need developers who both like
C++ and Smalltalk/Self. I was a nice surprise to be contradicted by
George Cox who said he is actually working on StrongTalk:
https://github.com/gjvc/strongtalk-2020
The move from 32 bits to 64 bits in Squeak happened twice (first at HP
and then with Eliot Miranda). That wasn't an absurd amount of work and
even though there was some advantages in using Slang instead of C++ it
is likely to be doable for the Self VM. Adding x86-64 to a compiler that
already can generate x86 code is another reasonable project. Supporting
the ARM64 would require a larger effort.
- do a Graal/Truffle implementation
While I have no more interest in programming in Java than in C++, this
is actually an interesting option. The TruffleSqueak project had nice
results for (I might be wrong) a student-level effort. And with their
Polyglot project the various languages can work together in a very nice
way.
I think partial evaluation will be an important technology in future
compiling VMs, but I don't know enough about Graal to evaluate this
alternative.
- patch OpenSmalltalk VM (Cog) used for NewSpeak, Squeak, Pharo and
Cuis to support Self
This is something that I strongly recommended to the Slate guys even
before Cog. I showed how a little tweak would allow multiple dispatch to
be added to the VM. Many things needed to support prototypes (maps
instead of classes, for example) don't actually make a difference at the
VM level and so would require no changes. The way closures are handled
in Cog and in the Self 4.1 bytecodes (previous Selves used message
passing instead) are very different and Self needs to distinguish
between implicit self sends and sends to "self". Resends a slightly more
tricky than super.
Recently Cog has implemented support for multiple bytecode sets in the
same image in order to support Sista. Note that Cog itself is a dynamic
compilation system and it is the addition of Sista that makes it an
adaptive compiler more comparable to the Self VM. While there is VM
support for Sista in the form of an alternative bytecode set it mostly
exists in the image and so wouldn't help a Self system running on Cog.
- Klein
The OOPSLA 2005 paper on Klein (available to ACM members) include the
video fo the talk by David Ungar, Alex Ausch and Adam Spitz (available
to everyone):
https://dl.acm.org/doi/10.1145/1094855.1094865
One interesting thing in the talk was showing both Klein running inside
Self (like the Squeak Simulator) as well as running on a separate
computer (making it a SqueakNOS). I think it is a very interesting
project that could be extended in worthwhile directions (like running on
top of an operating system for those who like that sort of thing and
handling multiple processors like the RoarVM).
My first impression when trying to browse through Klein code was of some
confusion. I soon found out that many of the methods I was looking at
had been generated and that I needed to look at the sources for them
instead. Is this actually the case? It was a while ago so I might be
remembering it wrong.
- inverse Klein
I have no idea what this means.
-- Jecel