
Self Programming Language - tosh
http://www.selflanguage.org/
======
jolmg
Is there a good resource that shows the ideal use of prototypal inheritance? I
imagine that the ideal use is not mimicking class-based inheritance, or is it?

I mean if you have an array of things and you want a new instance of such
things, it's too unnatural to take one from the array, clone it and change it.
It seems more natural to have something class-like: An "empty" prototype and a
constructor function.

I guess what I'm wondering is what idioms and patterns are unique to
prototypal-inheritance OOP languages.

~~~
Stwerner
For me, what really made it click and think about how different it is from
class-based inheritance was an old Steve Yegge post: [http://steve-
yegge.blogspot.com/2008/10/universal-design-pat...](http://steve-
yegge.blogspot.com/2008/10/universal-design-pattern.html)

It is a really long post and heavily references Godel, Escher, Bach but this
section I think explains the difference really well:

 _Hofstadter offers several supporting examples for this thesis, but I 'll
paraphrase one of my all-time favorites. It goes more or less as follows._

 _Imagine you 're listening to announcers commenting on an NFL (American
football) game. They're talking about a new rookie player that you don't know
anything about. At this point, the rookie – let's say his name is L.T. – is
just an instance of the class "football player" with no differentiation._

 _The announcers mention that L.T. is a running back: a bit like Emmitt Smith
in that he has great speed and balance, and he 's great at finding holes in
the defense._

 _At this point, L.T. is basically an "instance" of (or a clone of) Emmitt
Smith: he just inherited all of Emmitt's properties, at least the ones that
you're familiar with._

 _Then the announcers add that L.T. is also great at catching the ball, so he
's sometimes used as a wide receiver. Oh, and he wears a visor. And he runs
like Walter Payton. And so on._

 _As the announcers add distinguishing attributes, L.T. the Rookie gradually
takes shape as a particular entity that relies less and less on the parent
class of "football player". He's become a very, very specific football
player._

 _But here 's the rub: even though he's a specific instance, you can now use
him as a class! If Joe the Rookie comes along next season, the announcers
might say: "Joe's a lot like L.T.", and just like that, Joe has inherited all
of L.T.'s properties, each of which can be overridden to turn Joe into his own
specific, unique instance of a football player._

 _This is called prototype-based modeling: Emmitt Smith was a prototype for
L.T., and L.T. became a prototype for Joe, who in turn can serve as the
prototype for someone else._

~~~
nerdponx
That's a helpful explanation.

How would a type system work in that context? Or is there no such thing?

~~~
Stwerner
Hah that's a good question. I haven't really thought about that or explored
type systems that would interact with this pattern. Would be really interested
in reading about it though!

~~~
nerdponx
It seems like the answer is "not well, and it's not recommended":
[https://softwareengineering.stackexchange.com/questions/9512...](https://softwareengineering.stackexchange.com/questions/95126/how-
does-a-static-type-system-affect-the-design-of-a-prototype-based-language)

~~~
jolmg
It's not just about static type systems, though. nerdponx was asking about
type systems in general. It's a tricky question even for dynamic type systems.
Javascript keeps reference to the constructor and the prototype, so you can
determine the "type" that way, but that's not the only way a prototype-based
OOP language can work. A language can work without keeping such references and
instead simply copying each property on cloning. How do you determine the type
of an object then? Is the type based on the presence of certain properties?
Does it include the equality of the values of such properties or does just
their presence suffice? Does having additional properties change the type?
There seem to be many questions with arbitrary answers in making such a
dynamic type system.

~~~
nerdponx
I made both comments!

I think I had static type systems in mind when I asked the question, but that
was helpful all the same. It seems in the case of Self it does in fact keep
the reference around.

I suppose the whole point of a static type system is moot with a fully
prototype-based language. Instead maybe you can enforce compile-time checks
(contracts?) on the messages an object is expected to receive.

~~~
jolmg
> I made both comments!

Ha! I did not notice! XP

> I suppose the whole point of a static type system is moot with a fully
> prototype-based language. Instead maybe you can enforce compile-time checks
> (contracts?) on the messages an object is expected to receive.

I think if you can do the latter, you can probably do the former. By that I
mean you can probably do neither.

If cloning is something you do in runtime, how can you enforce compile-time
checks on the messages they're supposed to receive? Such messages are defined
at runtime.

~~~
nerdponx
Does it have to be at runtime? Is there any point to an ahead-of-time compiled
prototype language?

------
dang
Thread from 2017 ('Can we ever get away from the misnomer of "prototype-based
OO"?'):
[https://news.ycombinator.com/item?id=14409088](https://news.ycombinator.com/item?id=14409088).

2014:
[https://news.ycombinator.com/item?id=7047953](https://news.ycombinator.com/item?id=7047953)

2010:
[https://news.ycombinator.com/item?id=1957511](https://news.ycombinator.com/item?id=1957511)
and
[https://news.ycombinator.com/item?id=1520246](https://news.ycombinator.com/item?id=1520246)

Surely there have been others?

------
agumonkey
note that Lars Bak went onto v8(js) and then Dart
[https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)](https://en.wikipedia.org/wiki/Lars_Bak_\(computer_programmer\))

~~~
tosh
He is currently (together with Kasper Lund et al) working on a new language
and runtime for IoT use cases.

a recent talk from Curry On 2019 [https://www.curry-on.org/2019/sessions/the-
making-of-a-secur...](https://www.curry-on.org/2019/sessions/the-making-of-a-
secure-and-robust-iot-development-platform.html)

------
fzzzy
I was super obsessed with Self about 15 years ago. JavaScript's prototypal
inheritance was influenced by Self. I was more interested in Self's graphical
environment at the time, though.

~~~
masklinn
> JavaScript's prototypal inheritance was influenced by Self.

Sadly more as a shortcut to getting an "object system" up and running quickly
than as a design principle though, most of the interesting bits of Self were
left by the wayside in the process (possibly in part to provide something
which feels more like Java).

Not to mention the subtle (and not necessarily sensible) terminological swaps
e.g. in Self a prototype is a "blueprint" instance, which is already set up
with all relevant traits & mixins, and gets copied and modified to get the
proper instance.

~~~
protomyth
I thought NewtonScript was a much more interesting descendent of Self than
JavaScript. The concept of frames, dual inheritance hierarchy, and the Soup
object database really set it apart. The papers on NewtonScript are still
interesting reading.

~~~
fzzzy
I completely forgot about NewtonScript! I wonder if NewtonScript's containment
inheritance was influenced by HyperTalk. Seems likely.

~~~
protomyth
I think it was more self. The UI paper is informative:
[https://cdn.preterhuman.net/texts/computing/apple/newton/Pro...](https://cdn.preterhuman.net/texts/computing/apple/newton/Prototype-
Based_Language_for_User_Interface_-_Newton_Projects_Experience.pdf)

------
nerdponx
This was a fun watch:
[https://www.youtube.com/watch?v=Ox5P7QyL774](https://www.youtube.com/watch?v=Ox5P7QyL774)

~~~
Someone
Not only fun, educational, too. For example, I learned that Self had multiple
code generators, just as modern JavaScript engines have “give me decent code,
fast”, and “give me fast code; may take some time” engines.

------
stormcode
This language also inspired LambdaMOO (created by another Xerox Parc employee)
which is another early example of a prototype based language, with its own
built in environment, but it's all text based. I'd heard about self in a talk,
but hadn't read the docs until now. Super cool reading about it now. Good
slice of history.

------
vlaaad
I don't understand why languages like these are not mainstream. Why are we
stuck with blindly editing text files and waiting for compilation that
restarts the whole world? Why state of the art is a REPL where immediate
feedback is limited to printed text with all the actual values barely
reachable?

~~~
jolmg
> Why are we stuck with blindly editing text files

It's inherently more portable and composable.

> waiting for compilation

There are many languages that are interpreted that are mainstream.

> that restarts the whole world

You can program in mainstream languages without restarting the world. See
skewer-mode[1] for example, for programming in javascript without
restarting/refreshing. You can change top-level definitions and send them to
override the previous definitions. You can do this with any language that
allows overriding functions at runtime, IOW late-binding languages with an
eval function, like python and ruby. This way of programming is probably very
non-mainstream, though. The reason why it's not more popular is probably
because most of us are working with programs that take little to no time to
restart and get to the same state. Restarting ensures that whatever state we
see in the program is reachable with the current state of the source code.

> Why state of the art is a REPL where immediate feedback is limited to
> printed text with all the actual values barely reachable?

Again, because that's inherently more portable and composable. What do you
mean they "actual values [are] barely reachable"? You can access anything via
any REPL I can think of.

[1] [https://github.com/skeeto/skewer-mode](https://github.com/skeeto/skewer-
mode)

------
jolmg
The handbook seems down. Here's The Internet Archive's copy:

[https://web.archive.org/web/20190417013701/http://handbook.s...](https://web.archive.org/web/20190417013701/http://handbook.selflanguage.org/)

------
maitredusoi
The interface builder I hope one day to design, was design 30 years ago ...
gloups ;)

