The status of the Self language | Hacker News Reader

The status of the Self language

blog.selflanguage.org

42 pointsrussellallen23 comments

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!

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? :)

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.

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

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

Nicely done!

LOL! You make a compelling argument.

It would be nice if the v8/spidermonkey/etc teams gave some insight into what kind of optimisations they have made/are making.

Not just for inspiration, but for implementation too! Self's non-intuitive map optimisation has found its way into V8 and the latest PyPy: http://morepypy.blogspot.com/2010/11/efficiently-implementin...

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

Thanks for the recommendation. PhD Dissertation Linked: http://www.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-287.p...

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

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

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

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

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. :)

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

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.

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!

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

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.

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"?

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

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?

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.

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.

Reply on news.ycombinator.com