

The status of the Self language - russellallen
http://blog.selflanguage.org/2010/12/01/first-introspection-2010-12/

======
ekidd
In every argument about dynamic language performance for the last 15 years,
Self has been the final word: "If Self can reach 1/4 to 1/2 the speed of
native C code, why can't JavaScript? Why can't Ruby?" Well, JavaScript and Lua
are slowly getting there, and Ruby might in a few more years. Even if Self
could only reach that level of performance occasionally, it has been an
inspiration to many others.

It's great to hear that an old and storied project has been released as open
source. The best of luck to them, and I look forward to reading their compiler
source code some day!

~~~
chrisbroadfoot
I'm actually surprised JS has made it this far. I'm not convinced it will go
much further, though.

Can someone convince me, please? :)

~~~
apl
I'll try.

At some point in the past, you predicted (possibly implicitly, given that
we're dealing with "surprise") that JS wouldn't reach the performance it has
today. But it evidently did. So you're not very good at predicting the
development JavaScript's performance profile. Currently you believe it can't
go much further. Hence, given the historical precedent that we have, it
probably will.

There you go.

~~~
epo
What makes you think he was talking about Javascript's performance?

~~~
apl
Context? Besides, my argument doesn't really depend on whether you put
"performance" or "popularity." Also, I was joking.

------
sb
To get a feeling for the Self language and what was (is) possible, you should
(if you can, of course) take the time to watch the video:
<http://www.youtube.com/watch?v=3ka4KY7TMTU>

It contains a few gems, and is really worthwhile watching. (Disclaimer, I
think Dave Ungar has done tremendous things for PLDI; interested people should
definitely check out his UC-Berkeley PhD thesis of 1986, easily one of the
best I have ever seen...)

~~~
silentbicycle
That video is very good, but don't forget the research papers from the Self
project either (<http://selflanguage.org/documentation/published/index.html>)

Particularly good:

"An Efficient Implementation of Self"
([http://selflanguage.org/documentation/published/implementati...](http://selflanguage.org/documentation/published/implementation.html))

"Making Pure Object-Oriented Languages Practical"
([http://selflanguage.org/documentation/published/practical.ht...](http://selflanguage.org/documentation/published/practical.html))

"Organizing Programs Without Classes"
([http://selflanguage.org/documentation/published/organizing-p...](http://selflanguage.org/documentation/published/organizing-
programs.html))

~~~
sb
Yeah, I know--it seems to be a recent pattern of mine to forget some links and
add-on pointers...

The papers are very good, in addition to these, I find the following to be
particularly important (and very well written, too):

\- the classic PICs (polymorphic inline caching) paper
(<http://selflanguage.org/documentation/published/pics.html>)

\- Urs Hoelzle's PhD thesis
([http://selflanguage.org/documentation/published/urs-
thesis.h...](http://selflanguage.org/documentation/published/urs-thesis.html))

~~~
silentbicycle
Definitely, the PIC paper.

Somehow I missed Urs Hoelzle's thesis. Nice! It has some papers on dynamically
compiling APL in the biblio I haven't seen, too. :)

~~~
sb
I found the APL papers interesting, too. Unfortunately, without the
corresponding source code available, it is--at least for me--increasingly
difficult to make sense of the APL papers and I am not sure/convinced this has
anything to do with changed nomenclature. (For example, AFAIR, I don't really
see inline caching in the description of "A Software High Performance
Interpreter" by Saal and Weiss 1974.)

~~~
silentbicycle
The APL literature seems to be pretty insular, including terminology.

I've been investigating it as a fascinated outsider. Tim Budd's _An APL
Compiler_ (<http://web.engr.oregonstate.edu/~budd/Books/aplc/>) covers some
issues, but goes into much less depth than I hoped. That page has the source
accompanying the book, though.

This guy's site (<http://home.earthlink.net/~swsirlin/apl.html>) has some
further thoughts loosely based on that book and its compiler.

~~~
sb
_The APL literature seems to be pretty insular, including terminology._

I could not agree more, honestly! I think my route towards understanding some
of the optimizations based on the current implementation of J and/or NARS2k
(<http://www.nars2000.org/>), probably this is the route to enlightenment.
Before embarking on that journey, I will read up on your hints, thank you very
much!

~~~
silentbicycle
If you want to continue this discussion, my contact info is in my profile.
Take care.

------
loewenskind
This is fantastic news. I'm really happy to see Self get picked up again. It
was a breeding ground for a lot of great performance improvements we enjoy
today. It will also be good to do some proper exploration of proper prototype
based development.

------
brazzy
Am I the only one who thinks they're not exactly helping their cause with
pretentious marketspeak like "an integrated intellectual and experiential
computing narrative for supporting collective and individual creativity"?

~~~
silentbicycle
Normally, I'd agree, but in the context of Self, Smalltalk, Xerox PARC, and
everything that have come out of them, it's justified.

------
smackay
The article mentions the lingering fear of Smalltalk images but virtual
machine images offering hope for the future. I experienced this with Smalltalk
(Gemstone) apps quite some time ago and that feeling remained with Java on the
desktop. What would it take to get non-native environments to integrate better
and so gain better acceptance with end-users? Is the browser a better vector
since end-users are more accepting of different web site styles rather than
desktop app look and feels?

~~~
dfox
He is not talking about non-native look and feel, but about image-based
development. That is: you directly modify running state of VM and then save
all of this state into giant file. Source code is often contained only in this
giant binary file, or produced by some specialized tool later. This breaks
many common development workflows, for example it is hard to integrate with
common (file-based) version control systems.

~~~
duncanj
That's true. The problem is that source code is only a fraction of the
knowledge contained in the system. In most source-code-based systems, you
would write code for building a lookup table, or for reading one from storage.
This code would be executed at application startup. In Smalltalk or image-
based lisp, you simply make the table and save the image. Unfortunately, the
source code now doesn't fully describe the system. Systems like ENVY are
intended to provide a process for putting the data in the source.

