Self is like Smalltalk, Only More So
Self slogan from David Ungar.
The Self homepage at selflanguage.org 
contains much information, as well as source for Linux and Mac Osx (and Sparc Solaris for an older version). Self 4.5 was released for download in 14 January 2014.
(The original Sun page at labs.oracle.com is now only useful for historical purposes. Alternate and older Linux and Cyg Win sources and binaries are at www.gliebe.de )
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 Mac Os version has the poly-whatsit-inline-thingummies now and has a working source-level performance profiler.
The reference manual and a tutorial are at selflanguage.org
Published papers on Self are at bibliography.selflanguage.org
Blog at: blog.selflanguage.org
Other information about this language (papers, alternate implementations) is available from: www.cetus-links.org
Self has no classes, only prototypes (see Prototype Based Programming and Classes Prototypes Comparison). 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 Prototype Based Programming. 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. -- Jason Grossman
Yes. See the paper "Organizing Programs Without Classes", available at the Self website: research.sun.com
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.
-- Adam Spitz
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.
Self Uses Capitalization For Syntax, which is a little weird.
-- Martin Pool
(...says the guy who just typed "Self Uses Capitalization For Syntax". :) )
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 Smalltalk Language forces me to use parentheses now (and also whenever it forces me to type out the word "self" [Self Dot Syndrome] :). -- Adam Spitz
Note that Haskell Language also uses capitalization for syntax; I'm finding it less weird than I expected. -- Shae Erisson
So does English, and especially German. It complements using periods to end statements. -- Brock
Also see www.consultar.com for a project in progress to run Self inside a Java Virtual Machine.
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 Newton Script whose closest kin is Self. I learned this prototypical OO language before doing any serious work in a class-based OO language (Java Language) and I believe it has broadened the way I think about design.
The former head of research for File Maker Pro told me that Newton Script is based on Self -- Shae Erisson
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 Java Script 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 Java Script 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 Java Script users if you want a picture of what large scale Self usage would be like! Probably not much fun. (Personally I would miss Static Type Safety...) -- Daniel Earwicker
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 Basic Button 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 Basic Button 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 -- Greg Vaughn
It's true, they can. I've been reading up on metaclasses in Python Language, and I suddenly realized metaclasses would let you do prototypical Python, I'm sure it would work the other way around as well. -- Shae Erisson
Has anyone played with Kansas, the collaborative development environment that Sun based on Self Language? -- Shae Erisson
Has anyone tried doing Extreme Programming 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 Goal Donor, and there's not much of a deadline, so we don't bother with any of the planning stuff - but we do Automated Testing and Pair Programming and Refactor Mercilessly and all of that.) XP in Self is wonderful for all the same reasons that XP in Smalltalk Language 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 Continuous Integration. :)
If anybody's got any suggestions, or questions, or experiments you'd like us to try, I'd love to hear them. :)
-- Adam Spitz
Which version of self are you using?
Where can I get the software?
What does it run on?
What do I need to do to make it run?
-- rk
We're using version 4.2.1, which you can get from the Self homepage (research.sun.com ). The version from Sun only runs on the SPARC and on Mac Osx. (We're running it on Mac Os 10.3.) It's also possible to go to gliebe.de and get an older version (4.1.6, maybe?) that runs on Linux or (they claim - I haven't tried it) Cyg Win on Microsoft Windows.
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.)
-- Adam Spitz
Self's great innovation performance-wise is Polymorphic Inline Caches. They are now also used in Visual Works Smalltalk.
I'm researching the Self VM right now, and it lives on in languages like Java Script. 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. -- Sunir Shah
Java Script 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 Mozilla Browser is pretty good though.) It's much easier to add new behavior to third-party classes than even Smalltalk Languages 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
Java Script is a very nice language that has been tainted by association with bad web code. Smalltalk Language 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), Java Script 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 Java Script 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 Cee Language or /bin/sh or Tcl Language 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:
Delegator Is Delegation In Java makes Delegation available in the Java Language. It's an API in native Java so adoption for Java Programmers shouldn't be a problem -- Klaas Van Schelven
Lua Language is very similar to Java Script, but had a chance to mature for longer before public release. While it doesn't have a prototype object model in the core language, it's easy to add one in less than a page of code using "metatables", and the primary Lua book (Programming In Lua) does so to demonstrate OOP. It also integrates remarkably well with Cee Language, and is portable to literally anywhere with an ANSI C compiler. -- Scott Vokes
Io Language is a prototypical language that takes a lot from Self and has an execution model that's more like a Scripting Language.
Slate Language takes from Self, Strong Talk, and Squeak, and attempts to do better than any of them (by learning their lessons and the lessons of those that came after, eg Dylan Language).
Gnu Smalltalk is an Image Based Language, like a typical Smalltalk Language, but it's much more file-oriented that typical Smalltalks. Most editions don't even *have* a GUI, though that seems to be changing. Development is usually done in Emacs, and it seems to be possible to write shell script-like things with it. It's faster than Squeak, by my measurements, though not as well supported.
There are several Java Script engines in Unix that can run from the shell:
njs (supersedes ngs-js) www.njs-javascript.org
Older: ngs-js people.ssh.com
Mozilla spidermonkey (in C) www.mozilla.org
Mozilla Rhino Interpreter (written in Java) www.mozilla.org
Okay, so what's wrong with Visual Works' 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. -- Adam Spitz
I just watched Self: The Video. (See www.merlintec.com:8080 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 Smalltalk Language (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.)
I suspect that the benchmarking mentioned in the movie was done on the Ana Morphic Hot Spot Vm, a virtual machine. As I understand, it was done by Mario Wolczko. (Reportedly Sun bought the Anamorphic company assigned the employees and the technology to the Self project, thought the timelines in this essay, research.sun.com , are confusing. Names to look for include Lars Bak, Urs Hoelzle and John Maloney.) 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 Open Jdk openjdk.java.net ), it can, in principle, be ported to more architectures and more operating systems, and the Davinci Machine project could result in it again supporting fast Self and fast Smalltalk.
Is Anamorphic also associated with John Maloney's Morphic Interface for Self, which reappeared in Squeak Smalltalk and then in Dan Ingalls's Lively Kernel 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.
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 Smalltalk Language 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.
See original on c2.com