Self (programming language): Difference between revisions

Content deleted Content added
No edit summary
OAbot (talk | contribs)
m Open access bot: url-access updated in citation with #oabot.
 
(394 intermediate revisions by more than 100 users not shown)
Line 1:
{{Short description|Prototype-based programming language}}
'''Self''' is an [[object oriented]] [[programming language]] based on the concept of ''[[Prototype oriented|prototypes]]''.
{{Infobox programming language
| name = Self
| logo = Self-logo.svg
| logo size = 200px
| logo caption = Self logo
| screenshot = <!-- Filename -->
| screenshot caption =
| paradigms = [[Object-oriented programming|object-oriented]] ([[Prototype-based programming|prototype-based]])
| family = [[Smalltalk]]
| designers = [[David Ungar]], Randall Smith
| developers = David Ungar, Randall Smith,<br/>[[Stanford University]],<br/>[[Sun Microsystems]]
| released = {{Start date and age|1987}}
| latest release version = 2024.1
| latest release date = {{Start date and age|2024|08|28}}
| typing = [[Type system|dynamic]], [[Strong and weak typing|strong]]
| operating system = [[Cross-platform software|Cross-platform]]: [[Unix-like]], [[macOS]], [[Microsoft Windows|Windows]]
| license = [[BSD licenses|BSD]]-like
| website = {{URL|www.selflanguage.org}}
| implementations = Self
| dialects =
| influenced by = [[Smalltalk]], [[APL (programming language)|APL]]<ref>{{cite conference|doi=10.1145/1238844.1238853|last1=Ungar|first1=David|last2=Smith|first2=Randall B.|book-title=Proceedings of the third ACM SIGPLAN conference on History of programming languages |title=Self |date=2007 |isbn=9781595937667|s2cid=220937663}}</ref>
| influenced = [[NewtonScript]], [[JavaScript]], [[Io (programming language)|Io]], [[Agora (programming language)|Agora]], [[Squeak]], [[Lua (programming language)|Lua]], [[Factor (programming language)|Factor]], [[Rebol]]
}}
 
'''Self''' is a [[General-purpose programming language|general-purpose]], [[High-level programming language|high-level]], [[Object-oriented programming|object-oriented]] [[programming language]] based on the concept of ''[[Prototype-based programming|prototypes]]''. Self began as a dialect of [[Smalltalk]], being [[dynamically typed]] and using [[just-in-time compilation]] (JIT) with the prototype-based approach to objects: it was first used as an experimental test system for language design in the 1980s and 1990s. In 2006, Self was still being developed as part of the Klein project, which was a Self virtual machine written fully in Self. The latest version, 2024.1 was released in August 2024.<ref>{{cite web |title=Self "Mandarin" 2017.1 |website=[[GitHub]] |url=https://github.com/russellallen/self/releases/tag/2024.1 |date=24 May 2017 |access-date=1 November 2024}}</ref>
=== History ===
 
Several just-in-time compilation techniques were pioneered and improved in Self research as they were required to allow a very high level object oriented language to perform at up to half the speed of optimized [[C (programming language)|C]]. Much of the development of Self took place at [[Sun Microsystems]], and the techniques they developed were later deployed for [[Java (programming language)|Java]]'s [[HotSpot (virtual machine)|HotSpot]] [[virtual machine]].
Self was designed primarily by David Ungar and Randall Smith in 1986. The first implementation was built at [[Stanford University]] in 1987, and used as a bootstrap to bring up the rest of the enviornment that's needed for a real development system. The first public release was in 1990, and the next year the team moved to [[Sun]] where they continued work on the language. Several new releases followed until falling dormant in 1995 with the 4.0 version, but the latest 4.1 version was released in 2002 and runs on [[Mac OS X]] and [[Solaris Operating Environment|Solaris]].
 
At one point a version of Smalltalk was implemented in Self. Because it was able to use the JIT, this also gave extremely good performance.<ref>{{cite conference |last1=Wolczko |first1=Mario |date=1996 |title=self includes: Smalltalk |conference=Workshop on Prototype-Based Languages, ECOOP '96 |place=Linz, Austria}}</ref>
=== The problem ===
 
== History ==
Traditional object languages, such as [[Smalltalk]], are based on a duality. ''Classes'' define the basic qualities and behaviours of objects, and ''instances'' are a particular object based on a class. For instance you might have a "Person" class that has a "name" and the ability to perform "have baby" and "drive car". "Bob" is a particular instance of the class Person with the name set to Bob, and you can ask Bob to "have baby".
Self was designed mostly by [[David Ungar]] and Randall Smith in 1986 while working at [[PARC (company)|Xerox PARC]]. Their objective was to advance the state of the art in object-oriented programming language research, once [[Smalltalk]]-80 was released by the labs and began to be taken seriously by the industry. They moved to [[Stanford University]] and continued work on the language, building the first working Self compiler in 1987. Then, focus changed to working to build a full system for Self, in contrast to only the language.
 
The first public release was in 1990, and the next year the team moved to [[Sun Microsystems]] where they continued work on the language. Several new releases followed until falling largely dormant in 1995 with version 4.0. In 2006, version 4.3 was released, for [[macOS|Mac OS X]] and [[Oracle Solaris|Solaris]]. in 2010, a new release, version 4.4,<ref>{{cite web |title=Self 4.4 released |url=https://blog.selflanguage.org/2010/07/16/self-4-4-released/ |date=16 July 2010 |access-date=24 May 2017 |url-status=dead |archive-url=https://web.archive.org/web/20171205194557/https://blog.selflanguage.org/2010/07/16/self-4-4-released/ |archive-date=5 December 2017}}</ref> was developed by a group comprising some of the original team and independent programmers, for Mac OS X and [[Linux]], as are all later versions. In January 2014, a follow-up, 4.5 was released,<ref>{{cite web |title=Self Mallard (4.5.0) released |url=http://blog.selflanguage.org/2014/01/12/self-mallard-4-5-0-released/ |date=12 January 2014 |access-date=24 May 2017 |url-status=dead |archive-url=https://web.archive.org/web/20171206074534/https://blog.selflanguage.org/2014/01/12/self-mallard-4-5-0-released/ |archive-date=6 December 2017}}</ref> and three years later, version 2017.1 was released in May 2017.
This example shows one of the problems with this approach. Bob cannot have a baby, but we've said that any Person can. To "solve" this we need to add a finer level of grainularity in our original design, and have "Male" and "Female" subclasses of Person. This is, obviously, a contrived (and perhaps in the future, incorrect) example, but this is a very real problem. Unless you can predict with certainty what qualities the objects will have in the distant future, you cannot design your class heirarchy properly. All too often the program will evolve to require additional behaviours, and suddenly the entire system has to be re-designed to break out the objects in a different way.
 
The [[Morphic (software)|Morphic]] [[user interface]] construction environment was originally developed by Randy Smith and John Maloney for the Self programming language.<ref>{{cite conference |last1=Maloney |first1=John H. |last2=Smith |first2=Randall B. |book-title=Proceedings of the 8th annual ACM symposium on User interface and software technology |title=Directness and liveness in the morphic user interface construction environment |date=1995 |pages=21–28 |doi=10.1145/215585.215636 |isbn=089791709X |s2cid=14479674 |url=http://bibliography.selflanguage.org/directness.html |access-date=24 March 2020|url-access=subscription }}</ref> Morphic has been ported to other notable programming languages including [[Squeak]], [[JavaScript]], [[Python (programming language)|Python]], and [[Objective-C]].
Experience with early OO languages like Smalltalk showed that this sort of issue came up time and time again. Systems would tend to grow to a point and then become very ridgid, as the basic classes deep below the programmers code were simply "wrong". Without some way of easily changing the original class, you may have a serious problem.
 
Self also inspired a number of languages based on its concepts. Most notable, perhaps, were [[NewtonScript]] for the [[Apple Newton]] and [[JavaScript]] used in all modern browsers. Other examples include [[Io (programming language)|Io]], Lisaac and [[Agora (programming language)|Agora]]. The IBM Tivoli Framework's distributed object system, developed in 1990, was, at the lowest level, a prototype based object system inspired by Self.
Dynamic languages such as Smalltalk allowed for this sort of change via well-known methods in the classes, by changing the class the objects based on it would change their behaviour. But in other languages like [[C plus plus|C++]] there is no such ability, and making such a change can actually break other code, a problem known as the [[fragile base class problem]]. In general such changes had to be done very carefully, as other objects based on the same class might be expecting this "wrong" behavior - "wrong" is often dependant on the context.
 
== Prototype-based programming languages ==
=== The solution ===
{{main|Prototype-based programming}}
Traditional class-based OO languages are based on a deep-rooted duality:
#[[Class (object-oriented programming)|Classes]] define the basic qualities and behaviours of objects.
#[[Object (computer science)|Object instances]] are particular manifestations of a class.
 
For example, suppose objects of the <code>Vehicle</code> class have a ''name'' and the ability to perform various actions, such as ''drive to work'' and ''deliver construction materials''. <code>Bob's car</code> is a particular object (instance) of the class <code>Vehicle</code>, with the name "Bob's car". In theory one can then send a message to <code>Bob's car</code>, telling it to ''deliver construction materials''.
The problem here is that there is a duality, classes and instances. Self simply eliminated this duality.
 
This example shows one of the problems with this approach: Bob's car, which happens to be a sports car, is not able to carry and deliver construction materials (in any meaningful sense), but this is a capability that <code>Vehicle</code>s are modelled to have. A more useful model arises from the use of [[subclass (set theory)|subclass]]ing to create specializations of <code>Vehicle</code>; for example <code>Sports Car</code> and <code>Flatbed Truck</code>. Only objects of the class <code>Flatbed Truck</code> need provide a mechanism to ''deliver construction materials''; sports cars, which are ill-suited to that sort of work, need only ''drive fast''. However, this deeper model requires more insight during design, insight that may only come to light as problems arise.
Instead of having an "instance" of an object that is based on some "class", in Self you make a copy of an existing object, and change it. So "Female" would be created by making a copy of an existing "Person" object, and then adding the "have baby" method. Basic objects that were used primarily to make copies of were known as ''prototypes''.
 
This issue is one of the motivating factors behind '''prototypes'''. Unless one can predict with certainty what qualities a set of objects and classes will have in the distant future, one cannot design a class hierarchy properly. All too often the program would eventually need added behaviours, and sections of the system would need to be re-designed (or [[Refactoring|refactored]]) to break out the objects in a different way.{{Citation needed|date=February 2007}} Experience with early OO languages like [[Smalltalk]] showed that this sort of issue came up again and again. Systems would tend to grow to a point and then become very rigid, as the basic classes deep below the programmer's code grew to be simply "wrong". Without some way to easily change the original class, serious problems could arise.{{Citation needed|date=February 2007}}
This may not sound earth shattering, but in fact it greatly simplifies dynamism. If you have to fix a problem in some "base class" because your program has a problem, simply change it and make copies of it instead. No other program will see this change. If at some point in the future men can have babies, big deal, add it.
 
Dynamic languages such as Smalltalk allowed for this sort of change via well-known methods in the classes; by changing the class, the objects based on it would change their behaviour. However, such changes had to be done very carefully, as other objects based on the same class might be expecting this "wrong" behavior: "wrong" is often dependent on the context. (This is one form of the [[fragile base class problem]].) Further, in languages like [[C++]], where subclasses can be compiled separately from superclasses, a change to a superclass can actually break precompiled subclass methods. (This is another form of the fragile base class problem, and also one form of the [[fragile binary interface problem]].)
Better yet, this actually dramatically simplifies the entire OO concept as well. Everything might be an object in traditional systems, but there is a very fundamental difference between classes and instances. In Self, there isn't.
 
In Self, and other prototype-based languages, the duality between classes and object instances is eliminated.
=== The language ===
 
Instead of having an "instance" of an object that is based on some "class", in Self one makes a copy of an existing object, and changes it. So <code>Bob's car</code> would be created by making a copy of an existing "Vehicle" object, and then adding the ''drive fast'' method, modelling the fact that it happens to be a [[Porsche 911]]. Basic objects that are used primarily to make copies are known as ''prototypes''. This technique is claimed to greatly simplify dynamism. If an existing object (or set of objects) proves to be an inadequate model, a programmer may simply create a modified object with the correct behavior, and use that instead. Code which uses the existing objects is not changed.
Self objects are a collection of "slots". Slots are accessors methods that return values, and placing a colon after the name of a slot sets the value. For instance if you have a slot called "name", "myPerson name" returns the value in name, and "myPerson name:'gizifa'" sets it. Note that there is no distinction in Self between fields and methods, everything is a slot.
 
== Description ==
The syntax for talking to slots is Smalltalk-like, with "object_name slot_name" pairs being listed from left to right with the rightmost expression being returned. Lines end on an optional period. For instance:
Self objects are a collection of "slots". Slots are accessor methods that return values, and placing a colon after the name of a slot sets the value. For example, for a slot called "name",
<syntaxhighlight lang="smalltalk">myPerson name</syntaxhighlight>
returns the value in name, and
<syntaxhighlight lang="smalltalk">myPerson name:'foo'</syntaxhighlight>
sets it.
 
Self, like Smalltalk, uses ''blocks'' for flow control and other duties. Methods are objects containing code in addition to slots (which they use for arguments and temporary values), and can be placed in a Self slot just like any other object: a number for example. The syntax remains the same in either case.
<code>'Hello, World!' print.</code>
 
Note that there is no distinction in Self between fields and methods: everything is a slot. Since accessing slots via messages forms the majority of the syntax in Self, many messages are sent to "self", and the "self" can be left off (hence the name).
Is the Self version of the [[hello world]] program. The ' syntax is a shortcut that makes a copy of the known string object and puts "Hello, World!" into its only slot. Grouping is as in math, using parens. For instance:
 
=== Basic syntax ===
<code>'Hello, World!' uppercase print.</code>
The syntax for accessing slots is similar to that of Smalltalk. Three kinds of messages are available:
;unary : <code>''receiver'' slot_name</code>
;binary : <code>''receiver'' + ''argument''</code>
;keyword : <code>''receiver'' keyword: ''arg1'' With: ''arg2''</code>
 
All messages return results, so the receiver (if present) and arguments can be themselves the result of other messages. Following a message by a period means Self will discard the returned value. For example:
Is equivalent to:
 
<codesyntaxhighlight lang="smalltalk">('Hello, World!' uppercase) print.</codesyntaxhighlight>
 
This is the Self version of the [["Hello, World!" program]]. The <code>'</code> syntax indicates a literal string object. Other literals include numbers, blocks and general objects.
A slightly more complex example:
 
Grouping can be forced by using parentheses. In the absence of explicit grouping, the unary messages are considered to have the highest precedence followed by binary (grouping left to right) and the keywords having the lowest. The use of keywords for assignment would lead to some extra parenthesis where expressions also had keyword messages, so to avoid that Self requires that the first part of a keyword message selector start with a lowercase letter, and subsequent parts start with an uppercase letter.
<code>labelWidget clone label: 'Hello, World!'.</code>
 
<syntaxhighlight lang="smalltalk">valid: base bottom
makes a copy of the "labelWidget" object with the copy message (no shortcut this time), then sends it a message to put "Hello, World" into the slot called "lable". Now let's do something with it:
between: ligature bottom + height
And: base top / scale factor.</syntaxhighlight>
 
can be parsed unambiguously, and means the same as:
<code>(desktop activeWindow) draw: (labelWidget clone label: 'Hello, World!').</code>
 
<syntaxhighlight lang="smalltalk">valid: ((base bottom)
In this case the (desktop activeWindow) is performed first, returning the active window from the list of windows that the desktop object knows about. Next (read inner to outer, left to right) the code we examined earlier returns the labelWidget. Finally the widget is sent into the draw slot of the active window.
between: ((ligature bottom) + height)
And: ((base top) / (scale factor))).</syntaxhighlight>
 
In Smalltalk-80, the same expression would be written as:
==== Inheritance ====
 
<syntaxhighlight lang="smalltalk">valid := self base bottom
In traditional languages, classes exist in a global pool. Self has a similar concept based on a "root" object that contains a number of slots. Each of these slots contains an object with the same name.
between: self ligature bottom + self height
and: self base top / self scale factor.</syntaxhighlight>
 
assuming <code>base</code>, <code>ligature</code>, <code>height</code> and <code>scale</code> were not [[instance variable]]s of <code>self</code> but were, in fact, methods.
Every object in Self has a "parent" slot, which contains a pointer to the object it was created from. Any message not handled by a particular object is then sent to its parent. This is how Self handles inheritance, based on a delegation style. Consider the meaning of:
 
=== Making new objects ===
<code>myObject parent: someOtherObject.</code>
Consider a slightly more complex example:
 
<syntaxhighlight lang="smalltalk">labelWidget copy label: 'Hello, World!'.</syntaxhighlight>
This is quite interesting, it changes the "class" at runtime.
 
makes a copy of the "labelWidget" object with the copy message (no shortcut this time), then sends it a message to put "Hello, World" into the slot called "label". Now to do something with it:
[need examples of how to make a new "class" using the cloning operations]
 
<syntaxhighlight lang="smalltalk">(desktop activeWindow) draw: (labelWidget copy label: 'Hello, World!').</syntaxhighlight>
See also:
* [[Platonic form]]
 
In this case the <code>(desktop activeWindow)</code> is performed first, returning the [[active window]] from the list of windows that the desktop object knows about. Next (read inner to outer, left to right) the code we examined earlier returns the labelWidget. Finally the widget is sent into the draw slot of the active window.
'''External Resources:'''
 
=== Delegation ===
* [http://research.sun.com/self/ Self Home Page at Sun Microsystems]
{{main|Delegation (object-oriented programming)}}
* [http://www.cs.ucsb.edu/labs/oocsb/self/papers/papers.html Papers on Self from UCSB (mirror for the Sun papers page)]
In theory, every Self object is a stand-alone entity. Self has neither classes nor meta-classes. Changes to a particular object do not affect any other, but in some cases it is desirable if they did. Normally an object can understand only messages corresponding to its local slots, but by having one or more slots indicating ''parent'' objects, an object can '''delegate''' any message it does not understand itself to the parent object. Any slot can be made a parent pointer by adding an asterisk as a suffix. In this way Self handles duties that would use [[inheritance (object-oriented programming)|inheritance]] in class-based languages. Delegation can also be used to implement features such as [[namespace]]s and [[lexical scoping]].
* [http://www.cetus-links.org/oo_self.html Self resources at Cetus Links]
 
* [http://www.lsi.usp.br/~jecel/merlin.html Merlin Project]
For example, suppose an object is defined called "bank account", that is used in a simple bookkeeping application. Usually, this object would be created with the methods inside, perhaps "deposit" and "withdraw", and any data slots needed by them. This is a prototype, which is only special in the way it is used since it also happens to be a fully functional bank account.
* [http://groups.yahoo.com/group/self-interest/ Yahoo! Group on Self]
 
===Traits===
Making a clone of this object for "Bob's account" will create a new object which starts out exactly like the prototype. In this case we have copied the slots including the methods and any data. However a more common solution is to first make a more simple object called a [[trait (computer programming)|traits object]] which contains the items that one would normally associate with a class.
 
In this example the "bank account" object would not have the deposit and withdraw method, but would have as a parent an object that did. In this way many copies of the bank account object can be made, but we can still change the behaviour of them all by changing the slots in that root object.
 
How is this any different from a traditional class? Well consider the meaning of:
 
<syntaxhighlight lang="smalltalk">myObject parent: someOtherObject.</syntaxhighlight>
 
This excerpt changes the "class" of myObject at runtime by changing the value associated with the 'parent*' slot (the asterisk is part of the slot name, but not the corresponding messages). Unlike with inheritance or lexical scoping, the delegate object can be modified at runtime.
 
=== Adding slots ===
Objects in Self can be modified to include additional slots. This can be done using the graphical programming environment, or with the primitive '_AddSlots:'. A '''primitive''' has the same syntax as a normal keyword message, but its name starts with the underscore character. The _AddSlots primitive should be avoided because it is a left over from early implementations. However, we will show it in the example below because it makes the code shorter.
 
An earlier example was about refactoring a simple class called Vehicle in order to be able to differentiate the behaviour between cars and trucks. In Self one would accomplish this with something like this:
 
<syntaxhighlight lang="smalltalk">_AddSlots: (| vehicle <- (|parent* = traits clonable|) |).</syntaxhighlight>
 
Since the receiver of the '_AddSlots:' primitive isn't indicated, it is "self". In the case of expressions typed at the prompt, that is an object called the "lobby". The argument for '_AddSlots:' is the object whose slots will be copied over to the receiver. In this case it is a literal object with exactly one slot. The slot's name is 'vehicle' and its value is another literal object. The "<-" notation implies a second slot called 'vehicle:' which can be used to change the first slot's value.
 
The "=" indicates a constant slot, so there is no corresponding 'parent:'. The literal object that is the initial value of 'vehicle' includes a single slot so it can understand messages related to cloning. A truly empty object, indicated as (| |) or more simply as (), cannot receive any messages at all.
 
<syntaxhighlight lang="smalltalk">vehicle _AddSlots: (| name <- 'automobile'|).</syntaxhighlight>
 
Here the receiver is the previous object, which now will include 'name' and 'name:' slots in addition to 'parent*'.
 
<syntaxhighlight lang="smalltalk">_AddSlots: (| sportsCar <- vehicle copy |).
sportsCar _AddSlots: (| driveToWork = (''some code, this is a method'') |).</syntaxhighlight>
 
Though previously 'vehicle' and 'sportsCar' were exactly alike, now the latter includes a new slot with a method that the original doesn't have. Methods can only be included in constant slots.
 
<syntaxhighlight lang="smalltalk">_AddSlots: (| porsche911 <- sportsCar copy |).
porsche911 name:'Bobs Porsche'.</syntaxhighlight>
 
The new object 'porsche911' started out exactly like 'sportsCar', but the last message changed the value of its 'name' slot. Note that both still have exactly the same slots even though one of them has a different value.
 
== Environment ==
One feature of Self is that it is based on the same sort of [[virtual machine]] system that earlier Smalltalk systems used. That is, programs are not [[Standalone program|stand-alone]] entities as they are in languages such as [[C (programming language)|C]], but need their entire memory environment in order to run. This requires that applications be shipped in chunks of saved memory known as ''snapshots'' or ''[[system image|images]]''. One disadvantage of this approach is that images are sometimes large and unwieldy; however, debugging an image is often simpler than debugging traditional programs because the runtime state is easier to inspect and modify. (The difference between source-based and image-based development is analogous to the difference between class-based and prototypical object-oriented programming.)
 
In addition, the environment is tailored to the rapid and continual change of the objects in the system. Refactoring a "class" design is as simple as dragging methods out of the existing ancestors into new ones. Simple tasks like test methods can be handled by making a copy, dragging the method into the copy, then changing it. Unlike traditional systems, only the changed object has the new code, and nothing has to be rebuilt in order to test it. If the method works, it can simply be dragged back into the ancestor.
 
===Performance===
Self VMs achieved performance of approximately half the speed of optimised C on some benchmarks.<ref>{{cite journal |url=http://research.sun.com/jtech/pubs/97-pep.ps |title=Design and Implementation of Pep, a Java Just-In-Time Translator |last1=Agesen |first1=Ole |journal=Theory and Practice of Object Systems |volume=3 |issue=2 |date=March 1997 |pages=127–155 |doi=10.1002/(SICI)1096-9942(1997)3:2<127::AID-TAPO4>3.0.CO;2-S |archive-url=https://web.archive.org/web/20061124224739/http://research.sun.com/jtech/pubs/97-pep.ps |archive-date=November 24, 2006 |url-status=dead|url-access=subscription }}</ref>
 
This was achieved by [[just-in-time compilation]] techniques which were pioneered and improved in Self research to make a high level language perform this well.
 
===Garbage collection===
The [[Garbage collection (computer science)|garbage collector]] for Self uses [[Tracing garbage collection#Generational GC (ephemeral GC)|generational garbage collection]] which segregates objects by age. By using the memory management system to record page writes a write-barrier can be maintained. This technique gives excellent performance, although after running for some time a full garbage collection can occur, taking considerable time.{{Vague|date=April 2020}}
 
===Optimizations===
The run time system selectively flattens call structures. This gives modest speedups in itself, but allows extensive caching of type information and multiple versions of code for different caller types. This removes the need to do many method lookups and permits conditional branch statements and hard-coded calls to be inserted- often giving C-like performance with no loss of generality at the language level, but on a fully garbage collected system.<ref>{{cite thesis |url=https://www.cs.tufts.edu/~nr/cs257/archive/craig-chambers/thesis.pdf |title=The Design and Implementation of the SELF Compiler, an Optimizing Compiler for Object-Oriented Programming Languages |first=Craig |last=Chambers |publisher=[[Stanford University]] |degree=PhD |date=March 13, 1992}}</ref>
 
==See also==
* [[Morphic (software)]]
* [[Cecil (programming language)]]
 
==References==
{{reflist}}
 
==Further reading==
* [http://bibliography.selflanguage.org/ Published papers on Self]
*{{citation
| first1= C. |last1= Chambers
| year=1992
| title = The Design and Implementation of the Self Compiler, an Optimizing Compiler for Object-Oriented Programming Languages
| citeseerx = 10.1.1.30.1652
| publisher=[[Stanford University]]
}}
* [http://blog.rfox.eu/en/Programming/Series_about_Self.html Series of four articles "Environment and the programming language Self"]
 
==External links==
* {{Official website|www.selflanguage.org}}
* {{GitHub|russellallen/self}}
* [https://web.archive.org/web/20020606124955/http://research.sun.com/self/ Former Self Home Page at Sun Microsystems]
 
{{Smalltalk programming language}}
 
{{DEFAULTSORT:Self (Programming Language)}}
[[Category:Programming languages]]
[[Category:Dynamic programming languages]]
[[Category:Dynamically typed programming languages]]
[[Category:Object-oriented programming languages]]
[[Category:Prototype-based programming languages]]
[[Category:Software using the BSD license]]
[[Category:Cross-platform free software]]
[[Category:Free and open source compilers]]
[[Category:Programming languages created in 1987]]
[[Category:1987 software]]
<!-- Hidden categories below -->
[[Category:Articles with example Smalltalk code]]