Self has an even bigger legacy, the JVM is basically all the technology that made Self fast ported over to Java. David Ungar pioneered not only Self and prototype based inheritance, but also generational garbage collection, and polymorphic inline caching.

Before Sun cannibalised the Self team into Java, it was actually slow as a snail.

Another fun fact, a reduced version of Self was used the programming language for most of the Apple Newton, because Dylan was taking too long to get off the Ground.

Ungar's thesis is one of the most magnificent tours de force it's ever been my pleasure to read. It's mostly a series of "Here's why this technique is impossible to implement efficiently, but never mind that; here's how we implemented it efficiently anyway."

Yeah, it was very readable. It implemented the SOAR processor, Smalltalk On A RISC, which is credited by the Berkeley crowd as the RISC-III.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-287...

However, I don't think SPARC would be saddled with tagged integers were it not for SOAR.

Then Lars Bak (who worked on Self and HotSpot) used the techniques to make JavaScript fast with v8

This is the second time this week I've seen Lars Bak mentioned. I'm so glad to have learned about his work on virtual machines, it's a direct line through the history of programming languages, from Self, Smalltalk, Java, V8 JavaScript engine, and Dart as well.

Having played with Self a bit before the Newton came out and then seeing it in NewtonScript, it was a very cool thing to watch the idea of system-wide prototype-based inheritance filter through the community. I think it was a bit too much for most people to grok, but the ability of a coder to modify only a few prototypes in the system soup to change the behavior of existing apps was absolutely amazing.

Contrast to nowadays where people mainly seem to view it as a source of bugs and security vulnerabilities. Which is true and reasonable, but a shame. I always like monkey-patching, at least in small personal projects. But if you want to distribute anything, you end up needing to go back and remove all of it. .

Something similar in thought (but less generic), was the concept of "datatypes" in AmigaOS. It meant software could seamlessly import and export data in formats even though it had no knowledge of its internal representation.

A word processor could include for instance PNG images even though PNG was not even invented when the word processor was created!

> Self has an even bigger legacy, the JVM is basically all the technology that made Self fast ported over to Java.

Java only became fast after the HotSpot server compiler, which was written by Cliff Click (and Micahael Paleczny / Christopher Vick) and takes a different approach than Smalltalk / Self compilers.

Can you explain the differences?

This. And while we're at it, we shouldn't discount awk which had a profound impact on Self (and ultimately JavaScript) syntax, in turn. So much so, in fact, that the following pointless code (which doesn't even show JavaScript/awk regexp constants) is both JavaScript and awk:

    function f(x) {
      a[x] = "whatever"
      for (e in a)
        if (a[e] == x)
          return e
    }

Edit: but awk doesn't belong onto the list because it's far from dead

What were the specific impacts awk had on Self?

There's an interesting language strongly influenced by Self : Lisaac ( http://www.lisaac.org ). Lisaac is a purely prototype language extending the Self's prototype paradigm with extremely good performance (close to C code, biggest part of the research around this language was about high performance code generated by the compiler).

For instance, you can define a dynamic inheritance : your inheritance can be defined by a function which return an object - so, a prototype - among several.

The author of this language explain me that Self was one of the most important day in his life ;-)

Classes in JavaScript are just syntactic sugar around prototypes.

Ironically, what it really needs is explicit syntax for prototypes.

I don't think it did. Those of us who bothered to spend more than a glancing look at prototypes figured them out pretty easily. Including Classes in JavaScript feel like pandering: there really wasn't much to directly gain from them, but they threw them in there anyways because the TC knew it'd gain JavaScript some popularity.

Wha? That's a take.

Here's mine: ES6 classes are wildly smart. They provide the benefits of prototypical inheritance--you can just reach into the thing and do what you want to do!--while making it way easier for many developers to read and parse in short order, while reducing the difficulty spike in moving to JavaScript (or, today, TypeScript).

"Pandering". Right.

I can write old-style object prototypes. It makes my eyes bleed and makes me make more mistakes. So I'm just not gonna do that anymore.

It makes your eyes bleed? If you thought mine was a take...

Anyways, let's not act like ES6 classes aren't without their slew of issues, obscure syntax, and most importantly, problems when it comes to transpiling and backwards compatibility:

https://medium.com/@WebReflection/a-case-for-js-classes-with...

"Let's" not, but I don't care about much of anything in that article. I haven't written something that targets a browser that isn't ES2015 since...2016.

It's 2020. Things move on.

Great attitude. Let's move on and leave 13% of the global internet population behind.

It depends somewhat on when you tried to learn prototypes in JS. The time before Firefox implementation detail `__proto__` leaked into general web platform usage had some rough spots, as the big obvious example to mind. It still took almost too long after that before `Object.getPrototypeOf()` and `Object.setPrototypeOf()` were standardized. Admittedly "the prototype of this instance" shouldn't always be accessed and/or manipulated directly in "proper" prototype-oriented code, but there are a lot of practical cases that show up where it ends up being useful.

Lua's implementation of "object oriented programming" is also entirely based on Self's.

That's interesting that the curriculum didn't teach it! I went to a not terrific school and we learned about Self in undergrad P/L theory.

The reputation of the school is a proxy. Teachers are the ones doing the teaching. I think you got lucky!

A lot of smaller no-reputation schools actually have pretty good teachers, compared to some of the bigger or more well known schools. In my case I transferred in my 3rd year from a school with 2k or so CS students to one with 150. Our professors were teachers, not researchers. We had their full attention. Compared to my experience at the larger and better known school where until you were a senior you were one of 150-250 students in the courses. They lectured, you spent time with TAs (very mixed results, I had good ones but mostly mediocre or awful ones who just wanted the check).

I'm surprised Clojure isn't in the list either.

Edit: To clarify, Clojure is mostly a dead language that didn't have any innovations by itself, but it did influenced many programmers(the creator is good at marketing). It helped push forward the FP mindset into the users of other mainstream languages(js, python, java).

This suggests we clarify what is meant for a language to be "mostly dead". If we consider size compared to total market or trajectory we may ultimately conclude that a project for example Clojure is "mostly dead" compared to JavaScript or java.

However this isn't ultimately the most useful metric. Would you for example select a restaurant based on the reviews and the cuisine or to total annual revenue of its parent company. If your metric suggests you forego surf and turf at a local diner in order to eat a Whopper you may be asking the wrong questions.

For your consideration here is a better one. A language is alive when its ecosystem is likely to receive enough interest and talent to continue to develop enough to allow its users to continue to accomplish useful goals. Being embedded in 2 of the top platforms and being able to reuse those libraries is a factor. Relying on these host platforms means that it can remain alive indefinitely while being useful to only thousands instead of millions as long as it drives enough interest to pay the salaries of the dozens who develop the core and the hundreds that write useful tools.

https://clojure.org/news/2020/02/20/state-of-clojure-2020

I think the mostly dead classification implies a decline, vs a non-mainstream mindshare of all developers.

Isn't Clojure a relative newcomer for it to influence language design in general?

A stepping stone to more mainstream languages perhaps? I hardly saw a Clojure program so please elaborate.

Clojure is essentially a Lisp.

Is Clojure really “mostly dead”?

It has less market share than perl or delphi (make your own judgement). It was really hyped(rightfully so, a practical lisp for production use? fun! sign me in) then declined fast.

Like most(ly dead) languages, it still has its followers, in the case of clojure, mostly a cultish group (my impression from r/clojure and other forums).

Can you explain and support the idea that the number users using the language productively declined? The state of Clojure survey seems to have held steady at 2500 from 2015 to 2020 with 60% saying they used it for work in 2015 vs 69% saying they used it for work in 2020.

Going back to 2010 we see less than 500 respondents and only 27% using it for work. A charitable assumption is that it grew substantially between 2010 and 2015 and held steady between 2015 and 2020.

https://clojure.org/news/2020/02/20/state-of-clojure-2020

It suffered from the curse of parenthesis.