Self Language

Self is like Smalltalk, OnlyMoreSo

Self slogan from DavidUngar.

The Self homepage at http://selflanguage.org contains much information, as well as source for Linux and MacOsx (and SparcSolaris? for an older version). Self 4.5 was released for download in 14 January 2014.

(The original Sun page at http://labs.oracle.com/self/ is now only useful for historical purposes. Alternate and older Linux and CygWin sources and binaries are at http://www.gliebe.de/self/ )

Self was first announced in academic literature in 1987. The latest release was version 4.5 in January 2014, and is available from the language homepage. The MacOs version has the poly-whatsit-inline-thingummies now and has a working source-level performance profiler.

The reference manual and a tutorial are at http://selflanguage.org/documentation/index.html

Published papers on Self are at http://bibliography.selflanguage.org/index.html

Blog at: http://blog.selflanguage.org/

Other information about this language (papers, alternate implementations) is available from: http://www.cetus-links.org/oo_self.html

Self has no classes, only prototypes (see PrototypeBasedProgramming and ClassesPrototypesComparison). This makes implementation of lambda forms and singletons cleaner: there's no need to define a class when you just want an object. However it makes the structure of the program less explicit: in many cases there are many objects that behave the same way and it's good to make them members of the same class.

That's not a very good objection to PrototypeBasedProgramming. If it's really true you can create a "class" object, or just have prototypes keep track of their progeny. Classes are available but the language doesn't force classes on you.

Right, but I think there's an even simpler answer to the objection: objects with similar behaviour in a prototype language are made progeny of the same object and inherit some/most/all (whatever you want) of their behaviour from it. -- JasonGrossman

Yes. See the paper "Organizing Programs Without Classes", available at the Self website: http://research.sun.com/self/papers/organizing-programs.html

My own experience with Self has been that it's always perfectly clear when two objects are the same "type." The system keeps track (under the hood) of which objects are part of the same "clone family", and the environment will display that information when you're looking at an object. When you're looking at the prototypical "point" object, the object will be labelled "point". If you clone that object, the new object will be labelled "a point". (Of course, you could then mess around with the object and add slots to it or something, in which case it wouldn't be "a point" anymore, and so the environment would just label it as "an object".) I find it very intuitive; I really don't miss classes at all.

And all of this is on top of the fact (which Jason pointed out) that every point object will have a parent slot pointing explicitly to "traits point".

I can describe this aspect of the system in more detail, if anybody wants me to.

-- AdamSpitz

Self makes no distinction between member access and method calls: everything is just a slot. The caller doesn't need to know if a slot is (like a) read-write variable, a read-only value, or a method, and that can be redefined transparently in any object.

Self objects can change behaviour dynamically: if they had classes, then we could say that they change class.

SelfUsesCapitalizationForSyntax, which is a little weird.

-- MartinPool

(...says the guy who just typed "SelfUsesCapitalizationForSyntax". :) )

I'm growing to like the capitalization thing. The rule is simple, it doesn't really constrain me in any significant way, and my eye is learning to use the capitalization to parse the code more quickly. I feel a little twinge of annoyance whenever SmalltalkLanguage forces me to use parentheses now (and also whenever it forces me to type out the word "self" [SelfDotSyndrome] :). -- AdamSpitz

Note that HaskellLanguage also uses capitalization for syntax; I'm finding it less weird than I expected. -- ShaeErisson

So does English, and especially German. It complements using periods to end statements. -- Brock

Also see http://www.consultar.com/JSelf/ for a project in progress to run Self inside a JavaVirtualMachine.

This topic really piques my interest because I spent two years developing for the Apple Newton PDA. Development happened in a language specifically designed for the Newton called NewtonScript whose closest kin is Self. I learned this prototypical OO language before doing any serious work in a class-based OO language (JavaLanguage) and I believe it has broadened the way I think about design.

The former head of research for FileMakerPro told me that NewtonScript is based on Self -- ShaeErisson

I love how dynamic the language is. As was written above, there is no distinction between instance variables and methods. 'Slots' are basically named buckets inside an object which can contain either data or code. In one program where execution speed was important, I checked an initalization variable at startup and used that to determine which routine to put in a particular slot. I was essentially modifying the code at runtime.

The objects in JavaScript are rather like this. Objects are just associative arrays or maps, from names to members, and members can be functions as well as variables, allowing you to reassign them whenever. There is a standard prototype 'slot' (or property, in JavaScript terminology) that causes the object to effectively inherit features of another object (the value of that property.) So in reality, something rather like Self is most likely enabled in the Web browser you are reading this page with. :) It might make sense to consider the experiences of JavaScript users if you want a picture of what large scale Self usage would be like! Probably not much fun. (Personally I would miss StaticTypeSafety...) -- DanielEarwicker

The prototype of an object is essentially a delegate. If some bit of code tries to access a slot of an object (either read/write data or method call) and the object doesn't have the slot, then the prototype is automatically checked. This prototype approach is really strong in building GUI code. For example, you could have a BasicButton? object with data slots specifying label, font, color, size, etc. It can handle basic event processing and call a method slot called 'buttonClicked'. Then each time you need a button in your GUI, you set the prototype to BasicButton? and override the label and buttonClicked slots.

I've heard it argued that prototypical languages are more fundamental than class-based languages because you can emulate class-based behavior in a prototypical language, but not vice versa.

I've recently heard it argued that they both can emulate each other -- GregVaughn

It's true, they can. I've been reading up on metaclasses in PythonLanguage, and I suddenly realized metaclasses would let you do prototypical Python, I'm sure it would work the other way around as well. -- ShaeErisson

Has anyone played with Kansas, the collaborative development environment that Sun based on SelfLanguage? -- ShaeErisson

Has anyone tried doing ExtremeProgramming in Self?

I'm starting to do a bit of XP-like stuff in Self now. (Our project doesn't really fit into the classic XP mold - we're more-or-less our own GoalDonor, and there's not much of a deadline, so we don't bother with any of the planning stuff - but we do AutomatedTesting and PairProgramming and RefactorMercilessly and all of that.) XP in Self is wonderful for all the same reasons that XP in SmalltalkLanguage is wonderful (only more so ;).

The only really interesting thing is the collaborative features of the Self environment. When we program in pairs, instead of both sitting at the same computer, we sometimes sit at our own individual computers (which are right beside each other) and pop up the Self window on both screens. Self gives us each a mouse pointer and a keyboard focus (so it's not like we're constantly fighting over control of the mouse cursor). Most of the time it's pretty much the same as sharing a single computer, but occasionally it smooths the process a little bit. (Instead of trying to get me to notice a typo - "Complier? Look, you spelled it complier instead of compiler. Over there. Up one line." - my partner can just fix it himself.) And sometimes there's the occasional boring task (renaming a bunch of methods, for example) that we can divide up and work on simultaneously.

We've only just started experimenting with this kind of stuff, and I'm sure there are a bunch of cool things we could be doing that we're not doing. :) If we had a larger team, we could probably take better advantage of the extra working room that Self gives us. (We've got an infinite flat plane to work in, so if we wanted to, each pair could go off and work in a different area, and we'd still all be sharing the same world. Real ContinuousIntegration. :)

If anybody's got any suggestions, or questions, or experiments you'd like us to try, I'd love to hear them. :)

-- AdamSpitz

-- rk

We're using version 4.2.1, which you can get from the Self homepage (http://research.sun.com/self). The version from Sun only runs on the SPARC and on MacOsx. (We're running it on MacOs 10.3.) It's also possible to go to http://gliebe.de/ and get an older version (4.1.6, maybe?) that runs on Linux or (they claim - I haven't tried it) CygWin on MicrosoftWindows.

To make it run... well, the version from Sun ought to just work, right out of the box. (If it doesn't, please let me know.) I have no idea about the x86 version. (I have gotten Self running on a Linux machine before, so I can promise you that it's possible, but that was about a year ago, and I don't have the machine anymore, and I don't remember the instructions.)

-- AdamSpitz

Self's great innovation performance-wise is PolymorphicInlineCaches. They are now also used in VisualWorksSmalltalk.

I'm researching the Self VM right now, and it lives on in languages like JavaScript. It's my impression that Sun killed it in favour of Java; and they own it. But even if it "dies", it's still an amazing piece of technology that we can reapply elsewhere. -- SunirShah

JavaScript is very much a prototypical language and it's extremely easy to work with. I wish there were a good development environment. (The debugger provided by the MozillaBrowser is pretty good though.) It's much easier to add new behavior to third-party classes than even SmalltalkLanguages? and other class-based languages (I am a big Smalltalk fan). The ability to add new properties on the fly saves ton of code during GUI development. -- Ram Nukala

JavaScript is a very nice language that has been tainted by association with bad web code. SmalltalkLanguage is wonderful. Self seems to have all the good things of both. But I can't use any of them. Why? They combine a great language with a very specialized environment... Smalltalk and Self are informed and guided by the GUI, and you live or die by the GUI (yes, I know that this is an oversimplification, but in general it's hard to even talk about Smalltalk without a GUI with Smalltalk people), JavaScript with web applications, and so on. I should be able to take a Smalltalk program and compile it to an executable from a script, or run a JavaScript file directly from CMD.EXE or /bin/sh. But while I've found fragments of tools like these, they're always so wrapped around with limitations as to be useless... and I end up programming in CeeLanguage or /bin/sh or TclLanguage because I can depend on them being there where and when I need them. Has anyone any suggestions (other than Castaneda-like Stopping The World and changing careers)? -- Peter da Silva

Suggestions:

Okay, so what's wrong with VisualWorks' headless package? Isn't it supposed to do exactly what Peter wants? A Smalltalk executable without any GUI, browsers or debugger?

Just double-checking something. IIRC, Self does not have hidden variables. If that's correct then it means Self can't support capabilities, or any other notion of security, as is. It also means that it's the absolute perfectest candidate for adding an orthogonal security scheme. So can someone confirm or refute that Self's variables are always accessible from outside the object?

Yes, that's true. -- AdamSpitz

I just watched Self: The Video. (See http://www.merlintec.com:8080/Self The page calls it Self: The Movie, though it calls itself "the Video".) Is it just me or do they spend more time talking about the things they inherited from SmalltalkLanguage (as if they were Self innovations) & very little time talking about what differentiates Self from Smalltalk?

It's interesting that they show a Smalltalk environment running under Self. (& they claim it out performs commercial Smalltalks.)

-- RobertFisher

I suspect that the benchmarking mentioned in the movie was done on the AnaMorphic? HotSpotVm, a virtual machine. As I understand, it was done by MarioWolczko?. (Reportedly Sun bought the Anamorphic company assigned the employees and the technology to the Self project, thought the timelines in this essay, http://research.sun.com/features/tenyears/volcd/papers/ungar.htm , are confusing. Names to look for include LarsBak?, UrsHoelzle? and JohnMaloney?.) It is indeed interesting that Smalltalk on Self on HotSpot is so fast, and makes HotSpot sound all the more interesting technology. Now that HotSpot is open source (as part of OpenJdk http://openjdk.java.net/groups/hotspot/ ), it can, in principle, be ported to more architectures and more operating systems, and the DavinciMachine project could result in it again supporting fast Self and fast Smalltalk.

Is Anamorphic also associated with JohnMaloney?'s MorphicInterface for Self, which reappeared in SqueakSmalltalk and then in DanIngalls's LivelyKernel? research at Sun ?

I just read this in the Self manual: "It is an error to evaluate a block method after the activation record for its lexically enclosing scope has returned. Such a block is called a non-lifo block because returning from it would violate the last-in, first-out semantics of activation object invocation. This restriction is made primarily to allow activation records to be allocated from a stack. A future release of Self may relax this restriction, at least for blocks that do not access variables in enclosing scopes."

If it is really true that you can't call a closure after the enclosing lexical scope has terminated, then what is the point of having them? This seems like a very onerous restriction.

-- VincentToups

While I can't speak for Self specifically, in general you can pass the closure to functions you call. This allows one to perform actions that depend on or alter the closed over data without the called code having to explicitly know about it.

Non-Lifo blocks still work fine for most common uses of closures in SmalltalkLanguage type systems such as true ifTrue: [] False: []. If you need more, making one off objects is easy: (| value = ( 3 + 4 ) |) will act as if it were a block, only without the automatic wrapping to the calling context.

-- RussellAllen

CategoryProgrammingLanguage CategorySelf CategoryPrototypeProgramming

EditText of this page (last edited January 26, 2014) or FindPage with title or text search