If only it had been made open source 25, 30 years ago when I was really excited about this stuff. I have no idea why they kept it locked up inside Sun for so long.
They hesitated a bit on continuing to release it as open source when they moved from Stanford to Sun (I should actually say Sun's lawyers hesitated) but then went ahead and released Self 2.0 sources (Self 1.0 and 1.1 had been open source). This continued with Self 3.0 and Self 4.0 and then the project was cancelled the first time as Sun decided to focus exclusively on Java. David Ungar was able to continue making small changes but neither the sources nor the binaries were released to the public.
Around 2000 Sun decided to restart the Self project with a embedded Self-in-Self called Klein and released Dave's improvements (including the PowerPC Mac port) while an outside group had done a port to x86 Linux.
I think it was 2006 when Sun cancelled the project again and Dave moved to IBM research.
So all the sources have been available since 1990, but with the delay I mentioned in the case of Self 4.1
Interesting, I seem to recall it just not being available in the mid-90s when I looked? Or was it under a restrictive not-really-open source license of some kind?
Or maybe I'm just recalling what you're talking about with post-cancellation changes.
The problem with Self in the 1990s wasn't the lack of sources (I just checked the 1994 Self 4.0 sources and the license looks like the typical BSD one) but the fact that the binaries only ran on Sparc workstations and not the computers people actually had. I might as well post the whole text of the license:
# Sun-$Revision: 21.2 $
Copyright 1995 Sun Microsystems, Inc. and Stanford University.
All Rights Reserved. RESTRICTED RIGHTS LEGEND: Use,
duplication, or disclosure by the government is subject
to restrictions as set forth in subparagraph (c) (1) (ii)
of the Rights in Technical Data and Computer Software
Clause at DFARS 252.227-7013 (Oct. 1988) and FAR
52.227-19(c) (June 1987).
Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, CA 94043 USA
LICENSE:
You may use the software internally, modify it, make
copies and distribute the software to third parties,
including redistribution for profit, provided each copy
of the software you make contains the copyright notice
set forth above, the disclaimer below, and the authorship
attribution below.
DISCLAIMER:
Sun Microsystems, Inc. makes no representations about the
suitability of this software for any purpose. It is
provided to you "AS IS", without express or implied
warranties of any kind. Sun Microsystems, Inc. disclaims
all implied warranties of merchantability, fitness for a
particular purpose and non-infringement of third party
rights. Sun Microsystems, Inc.'s liability for claims
relating to the software shall be limited to the amount,
if any of the fees paid by you for the software. In no
event will Sun Microsystems, Inc. be liable for any
special, indirect, incidental, consequential or punitive
damages in connection with or arising out of this license
(including loss of profits, use, data, or other economic
advantage), however it arises, whether for breach of
warranty or in tort, even if Sun Microsystems, Inc. has
been advised of the possibility of such damage.
AUTHORSHIP:
This software has been derived from the Self system, which
resulted from the combined efforts of:
Bay-Wei Chang, Craig Chambers, David Ungar, Elgin Lee,
John Maloney, Lars Bak, Mario Wolczko, Ole Agesen,
Ole Lehrmann Madsen, Randall B. Smith, and Urs Hoelzle.
The whole Smalltalk ecosystem was super-expensive and proprietary. I can't really blame them because open source playbooks weren't understood at that time but it sure was a mistake.
March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."
September 1991 — "Smalltalk/V code is portable between the Windows and the OS/2 versions. And the resulting application carries no runtime charges. All for just $499.95."
(Advert on the last page of "The Smalltalk Report")
September 1991 — "Digitalk, Inc. announced new versions of Smalltalk/V DOS and Smalltalk/V Mac that include royalty-free runtime. Smalltalk/V Windows and Smalltalk/V PM are already royalty free. … Prior to this new policy, there was a per-copy charge for runtime applications."
If Java had not been a think, Smalltalk would be doing just fine.
It was the already quite established in big corporations, all IBM IDEs in the Visual Age series were written in Smalltalk, it was the language used alongside C++ on the famous GoF book.
When Java came to be, IBM dropped all their Smalltalk investment and pivoted 100% into Java, Eclipse was the rewrite of Visual Age into Java.
And the fact that companies like Cincom are still in business shows the extent Smalltalk was being used in the 1990's.
Actually around 2000 before Eclipse (aka WSAD in IBM speak ;) they retargeted Visual Age for Java.
I've never done anything with Smalltalk, and what I know doesn't make me comfortable. For example, Visual Age stored all your code in an opaque "repository" (not a file-based one like cvs, svn, git). And a colleague of mine told me there are no source code files, just the running project that you share around and tinker with all the time.
Exactly because of that in Visual Age for C++ v4 (the version is relevant), you could have a Smalltalk like experience for C++, similar to Energize C++, something that has taken decades to get back and we aren't there yet, even with VC++ hot reload and Live++.
Image based source control has been a solved problem for Smalltalk since the 1990's.
It is also a good example of how the "Python is too dynamic for a JIT" reasoning doesn't play that well, as it surely isn't more dynamic than Smalltalk, SELF and Lisp images and development environments.
I appreciate Sun creating things like Java and improving the performance of the JVM (adopting ideas from this Self runtime etc.) I don't know whether it made any money for them, but it certainly helped the rest of the computing field / industry.
Regarding Self's limited adoption, I think JavaScript showed that a Self-like system could be effective and popular if it used C-like syntax rather than Smalltalk-like syntax and shipped in every web browser.
JavaScript owes a lot to Self, not only in its runtime but also its prototype-based object design (though perhaps that's something of a liability since class-based object systems turned out to be more popular.)
Yes but it's really good for building better object systems, especially with newer features like proxies. In the SELF days they implemented Smalltalk with prototypes and found that it was faster than normal Smalltalk implementations.
I recently ran across an interesting postmortem critique of PataPata by its author Paul Fernhout, which was a Python implementation of some ideas from Squeak and Self, in which he discusses some inherent problems with prototype based object systems.
>The PataPata project is/was an experiment focusing on taking ideas from Squeak and Self and moving them to Python, as well as trying to go beyond the ideas in a Pythonic and educational constructivist way.
>It also aspires to help people build microworlds and other learning tools for the Python platform, using a prototype-based programming approach.
>It is intended to mainly support "unschooling", "free schooling", and "informal" education.
>It has been previously discussed on the Python edusig list, although it now has its own mailing list on SourceForge here.
>The biggest issue is that I learned that the seductive idea of prototypes may not be as powerful as its execution (especially as an add-on to an existing language). Consider what I wrote to someone else: "I've been repeatedly confronted with the fact that prototype languages are powerful and elegant but ultimately, like Forth, end up losing something related to documenting programmer intent. Documenting intent is one of the most important part of programming, and that is something that Smalltalk's formal class structure enforces for most code over Self, just like C's named variables document intent which gets lost manipulating Forth's data stack. Plus, it is hard for any great language feature to offset issues like lack of community or lack of comprehensive libraries."
>And after at person suggested you usually need to name things before you can share them, I replied: "And I agree on the issue of "naming" something in order to share it. Which gets back to the issue I mentioned of "documenting intent". With the PataPata system I made for Python, there was a choice point where I decided that prototypes used by other prototypes as parents needed to be named (a difference from Self). And I liked that choice. But then, what am I really gaining over Smalltalk (except not having a class side, which is nice, but is it worth the extra trouble and confusion?)"
>So, this leaves me questioning the whole move to prototypes. That person also pointed out previous work on "Exemplar based Smalltalk", so that is something I should look into further, perhaps as a compromise with Prototypes when I understand such previous work better.
[...]
I found some interesting email between Alan Kay and Guido van Rossum, in my archive of the OLPC educational software discussion group, where he hoped that the python community would make something like eToys. This is from a year after the last revision of PataPata's description, and I don't know if Alan was aware of PataPata. But I think "Snap!" (formerly BYOB) is the modern embodiment of what Alan was hoping for, based on JavaScript instead of Python. Python was (as Alan put it) "the general integrative base of XO", the focus and implementation language of the OLCP project.
On Mar 9, 2007, at 17:26 , Guido van Rossum wrote:
Thanks Alan. I'm quite satisfied with this response and I agree with
the priorities!
On 3/9/07, Alan Kay <alan.kay@squeakland.org> wrote:
Guido knows that I've been advocating that the Python folks should do Etoys
or a very Etoys like environment in Python (and that the rest of the OLPC be
given an objectification and media and scripting integration that is Etoys
like).
However, there are simply zillions of things left to be done everywhere for
OLPC so the first round of SW on the XO will be more of a gathering of
"suggestive" features and abilities (of which Etoys is just one). That seems
fine to me.
Viewpoints Research (our little non-profit) doesn't have any "ego or
identity" staked around whether the children's authoring environment is
Python based or Squeak based. I have said many times that, if the general
integrative base of XO is to be Python, then the Etoys-like authoring should
be based in Python also.
However, I will personally fight to the death to make sure that there is a
children's authoring environment that allows even young children to do
simulation style programming with very rich media objects.
For now, that is Etoys. It could be a suitable object-oriented Logo with
media objects (this is essentially what Etoys is). It could be some better
design (let's do one). The base could be Javascript (if implemented on top
of an integrated environment of sufficient power), Python (ditto), Ruby
(ditto), etc. Whatever it is, it has to be above high thresholds, not a hack
or a gesture.
Besides the programming the children use to learn important ideas in math
and science, they also need to be able to see how their own computer world
is structured by being able to "pop the hood" on practically everything they
use. Perhaps it is OK for high school children to see the current code (but
I don't think so). I think there needs to be a wrapping on the entire set of
facilities that uses the same conventions that 9 year olds do their own
programming in. Again, if it is to be Python, then it needs to be crafted a
bit for younger children. E.g. Etoys allows easy unlimited parallel tasking,
and this is very important for children's programming. Etc.
There are many good things that can be done here. We live in a computing
world in which there is a tremendous amount of identification between many
programmers and the tools they use -- so strong that it resembles religious
fervor. From my view, ALL of the system have such flaws that we are better
off being critical of all of them and try to use the best ideas from
everywhere.
If "Children First!" is really the goal here, then we must spend most of
our energies trying to make the childrens' environments more conducive to
creative learning of powerful ideas.
Cheers,
Alan
On 21 June 2007 Alan Kay Wrote:
Well, objects need some machinery behind them. The machinery could be Squeak, or it could be Python, or JS, or ...
As I've mentioned in the past, on the OLPC, one of the ways that integration could have been done (and still could be done) would be to use something like X windows without frames to allow compositing of graphical front-ends of media objects.
A composited collection would be what Etoys calls a "project", etc. From this point of view everything is like a widget but could be made from different stuff,
From the object perspective all the graphical properties of the objects/"windows" are the same, but the back-end drivers for the phenomena could be rather different. This is "windows without windows", which is kind of what the OLPC really needs.
Also, since Squeak allows plugins, all of this could be done in Squeak, but I don't think that is the point here. I would rather see a richer better architecture using the chosen paradigm (e.g. Python) than do any "language wars".
But I will just gently say again that "Sugar can and should be a lot more integrated in its approach to dealing with many different kinds of media objects. They really need to be combined freely and not be bound to applications but should all be able to populate any "document" or "project".) Etoys uses one way to do this.
Cheers,
Alan
On 21 June 2007 Alan Kay Wrote:
Hi Eben --
Yes.
Etoys has external formats for its "documents", so they can be stored on servers, fetched, passed around, etc. We have tried 3 different approaches over the years (and all work currently). One of the approaches uses the Open Doc standard (where the scripts are in there as non-standard data). The format we are using now is a form of s-expressions (could be XML, but XML is really too verbose for the XO and for slow networks).
And, as I mentioned in the previous email, when on an XO itself, all the media objects could be integrated as collections of frame-less X-windows (or some similar but simpler mechanism).
Etoys (and, better, an improvement in Etoys that has more age range) could be done in Python by writing a parser for one of the file formats and making the Etoys graphical environment and control in Python. This would completely unify these ideas on the XO -- but something more like the integrated architecture for many kinds of media objects would still have to be created.
In other words, Etoys per se are not nearly as important as the ideas and access to authoring power for children that they implement.
In any case, we are gradually working on the next version of an Etoys like environment that deals much more richly with more of the important issues for children's authoring than we do now.
Cheers,
Alan
----
Here's a lot more about this stuff, and what we were doing with NeWS, HyperLook, and SimCity:
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
Kind of always wished Alan Kay had spent some time playing with LambdaMOO back in the day. I know he was aware of it, but I think if he had really dug into it he would have dug it.
In a system like that, prototype OO makes so much sense. Objects are embodied "things" in the world. You can literally walk up to a "prototype" and touch it, move it, etc and dynamically inspect it (much like you'd do in Self, but in a form which is more narrative). And when you make things, you are building them on the basis of the other things, so.
Kay, Ingalls', etc work was really focused on getting pictures on the screen, and "objects" also made a lot of sense there.
I think the subsequent uses of object-orientation... everywhere else... and their conflation everywhere with (static) types ... has been problematic. I don't like the mixture of the C++/Java static early binding system with class hierarchies. At all.
I find JavaScript itself to be a pretty usable language (maybe somewhere between Python (easier) and Java (harder) or C++ (harder still)), but the browser DOM environment is a pain to deal with.
After understanding Self, I didn't find JavaScript's prototype system hard to understand.
From that, and my experience with both Self and with other prototype OO languages (like LambdaMOO & offshoots), I just find the JS implementation to be ... uncomfortable.
Plus from the earliest days people just seemed to be embarassed by the prototype thing. They shouldn't have been.
Yes I remember liking the idea with that one. And thinking that its "clone families" were a bit like implicit structural typing in a way. And that perhaps there was a way one could do a kind of static typing & type inference with something based around similar ideas. (e.g. this method takes as an arg anything which structurally matches xxxx, which we could deduce via clone families, etc.)
How do you figure? It certainly doesn't use message passing. Boxing of primitives and use of interfaces/protocols strikes me as a rather shallow similarity.
First of all you read the point of view of Java authors on the linked post.
Second, yes interfaces are based on protocols.
You can do dispatching via Proxy classes, reflection, or invokedynamic that came later as performance improvement.
Then you have the classloaders for a similar purpose as Objective-C plugins.
Java Remote Invocation, RMI, works similarly to PDO, Portable Distributed Objects.
Sun collaborated with NeXT on OpenSTEP before Java came to be.
Another inspiration was Distributed Objects Everywhere framework, born as Objective-C, later rewriten in Java and rebranded as the first edition of Java EE.
Likewise Web Objects went from Objective-C, to dual Objective-C/Java shortly before NeXT was acquired.
DonHopkins 35 days ago | parent | context | favorite | on: Help us raise $200k to free JavaScript from Oracle
SelfishScript. JavaScript credits Self as inspiration, but misses all the important things about Self.
JavaScript copied:
The name "Java", cynically chosen for marketing misdirection, not technical truth.
The word "prototype" from Self, but turned it into a quirky pseudo-class system. Instead of living objects delegating naturally, with multiple inheritance dynamically changeable at runtime, JavaScript glued on a weird constructor-function pattern that always confuses people, with constructors you have to call with new but can also uselessly call as normal functional foot-guns.
JavaScript missed:
The fluid, live object experience (JavaScript dev environments were never designed around exploration like Self’s Morphic).
The elegance of uniformity (JavaScript bolted on primitives, type coercions, and special cases everywhere).
The idea that the environment mattered as much as the language. Netscape didn’t ship with the kind of rich, reflective tools that made Self shine.
And most important of all: Self's simplicity! The original Self paper (Ungar & Smith, 1987, “Self: The Power of Simplicity”) was all about stripping away everything unnecessary until only a uniform, minimal object model remained. The title wasn’t ornamental, it was the thesis.
Simplicity. Uniformity. Minimal semantics. A clean consistent model you can hold in your head. Less semantic baggage frustrating JIT compiler optimization. Dynamic de-optimization (or pessimization as I like to call it).
Self proved that expressive power comes from radical simplicity.
JavaScript showed that market dominance comes from compromise (worse is better, the selfish gene).
JavaScript should be called SelfishScript because it claimed Self’s legacy but betrayed its central insight: that simplicity is not just aesthetic, it’s the whole design philosophy.
senderpath [Dave Ungar] 33 days ago [–]
Yes, indeed! It's a design philosophy, and one that the market does not always reward. I suspect that for many, it is either not salient, or unimportant. Design is subjective, and multi-dimensional.
Thank you, Don for seeing and writing about this dimension.
DonHopkins on Nov 9, 2022 | parent | context | favorite | on: The influence of Self
I wrote this in a discussion with Tom Lord in 2006 (a couple years before Lars Bak developed V8 at Google), after I ran into Dave when he was interviewing at Laszlo Systems, and he showed a demo of his latest Self system:
>I just ran into Dave Ungar (of Self fame), and mentioned how ironic it was that JavaScript pointed to Self as its inspirational prototype (vis-a-vis JavaScript's prototype based object system), but JavaScript totally missed the boat on efficient compile-ability, which is the most interesting thing about Self. (I mean, anybody can make a prototype oop system that runs slow, but it takes a fucking genius to come up all the brilliant stuff in Self, like the aggressive inlining compiler (it has no byte code interpreter, just a bad-ass compiler), incremental compilation, polymorphic inline cache, coupled with dynamic de-optimization to make it debuggable). He gave a cool Self demo of writing a straightforward factorial function, then editing the source to the system's multiplication operator, so it would return a different result if you multiplied something by 1,000,000. Then he showed how it affected the factorial function, as well as the rest of the system, which incrementally recompiled itself as needed. All that and perfect debuggability, too! About JavaScript, he retorted that it was actually possible to efficiently compile JavaScript if you were really devious enough. Too bad the art of designing languages so you don't have to be devious in order to compile them, was lost of so many popular bad language designers (PHP, JavaScript, Perl, etc).
> but JavaScript totally missed the boat on efficient compile-ability, which is the most interesting thing about Self
That's making much use of hindsight though: the creators of Self didn't think it would run fast, until it did [0]. The HOPL paper on Self [1] spends many words recounting the challenge of making Self fast.
[0] This is arguably a stronger claim than what appears in HOPL; I think it's from a talk by Dave Ungar, I'd have to check.
> And at the time, we thought it was impossible to make this language run efficiently, because it did all these things that were more abstract than languages of the time ...
There is a lot to be learned from reading historical CS texts. It helps us see how developers worked under constraint of historical hardware and it also helps us find commonalities to modern problems. There is a lot to be said about software engineering challenges that are a problem today and a problem decades ago. This creates a clearer picture of blind spots in the industry and reading outdated texts can be a fruitful endeavor despite seeming counterintuitive. I have a small collection of CS books that I have purchased from a used bookstore and I always walk away with new insights when I read them even if the information is outdated.
Thank you for your tone. I agree! Had Starting Forth, Thinking Forth, and Elizabeth D Rather books at one time. Reread TCL the Misunderstood (Antirez), every few years for the memoizing bit. Etc.
To the critics of parent, the reason we add dates and people make such posts is so HN users can know if it is something they read or something new or just something new to them. So when OP forgets the date, we make a post with the date so OP or the mods can edit the title.
I will read it, closely, but was all hopped-up expecting some new implementation, as I am down the Smalltalk rabbit hole lately, including watching lots of old videos. And perusing https://selflanguage.org
It's the convention on HN to add the year of an article at the end of a title in parens. Users often cue us to do this by posting the year in the comments. They aren't being dismissive—it's just an obscure little custom!
These days the entire runtime is open source and easy to get
Decent readable C++, too. With a modern CMake build, the whole bit.
https://github.com/russellallen/self
If only it had been made open source 25, 30 years ago when I was really excited about this stuff. I have no idea why they kept it locked up inside Sun for so long.
They hesitated a bit on continuing to release it as open source when they moved from Stanford to Sun (I should actually say Sun's lawyers hesitated) but then went ahead and released Self 2.0 sources (Self 1.0 and 1.1 had been open source). This continued with Self 3.0 and Self 4.0 and then the project was cancelled the first time as Sun decided to focus exclusively on Java. David Ungar was able to continue making small changes but neither the sources nor the binaries were released to the public.
Around 2000 Sun decided to restart the Self project with a embedded Self-in-Self called Klein and released Dave's improvements (including the PowerPC Mac port) while an outside group had done a port to x86 Linux.
I think it was 2006 when Sun cancelled the project again and Dave moved to IBM research.
So all the sources have been available since 1990, but with the delay I mentioned in the case of Self 4.1
Interesting, I seem to recall it just not being available in the mid-90s when I looked? Or was it under a restrictive not-really-open source license of some kind?
Or maybe I'm just recalling what you're talking about with post-cancellation changes.
The problem with Self in the 1990s wasn't the lack of sources (I just checked the 1994 Self 4.0 sources and the license looks like the typical BSD one) but the fact that the binaries only ran on Sparc workstations and not the computers people actually had. I might as well post the whole text of the license:
# Sun-$Revision: 21.2 $
Copyright 1995 Sun Microsystems, Inc. and Stanford University.
All Rights Reserved. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 (Oct. 1988) and FAR 52.227-19(c) (June 1987).
Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, CA 94043 USA
LICENSE:
You may use the software internally, modify it, make copies and distribute the software to third parties, including redistribution for profit, provided each copy of the software you make contains the copyright notice set forth above, the disclaimer below, and the authorship attribution below.
DISCLAIMER:
Sun Microsystems, Inc. makes no representations about the suitability of this software for any purpose. It is provided to you "AS IS", without express or implied warranties of any kind. Sun Microsystems, Inc. disclaims all implied warranties of merchantability, fitness for a particular purpose and non-infringement of third party rights. Sun Microsystems, Inc.'s liability for claims relating to the software shall be limited to the amount, if any of the fees paid by you for the software. In no event will Sun Microsystems, Inc. be liable for any special, indirect, incidental, consequential or punitive damages in connection with or arising out of this license (including loss of profits, use, data, or other economic advantage), however it arises, whether for breach of warranty or in tort, even if Sun Microsystems, Inc. has been advised of the possibility of such damage.
AUTHORSHIP:
This software has been derived from the Self system, which resulted from the combined efforts of:
Bay-Wei Chang, Craig Chambers, David Ungar, Elgin Lee, John Maloney, Lars Bak, Mario Wolczko, Ole Agesen, Ole Lehrmann Madsen, Randall B. Smith, and Urs Hoelzle.
The whole Smalltalk ecosystem was super-expensive and proprietary. I can't really blame them because open source playbooks weren't understood at that time but it sure was a mistake.
March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."
https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&dq=d...
September 1991 — "Smalltalk/V code is portable between the Windows and the OS/2 versions. And the resulting application carries no runtime charges. All for just $499.95."
(Advert on the last page of "The Smalltalk Report")
https://rmod-files.lille.inria.fr/Archives/TheSmalltalkRepor...
September 1991 — "Digitalk, Inc. announced new versions of Smalltalk/V DOS and Smalltalk/V Mac that include royalty-free runtime. Smalltalk/V Windows and Smalltalk/V PM are already royalty free. … Prior to this new policy, there was a per-copy charge for runtime applications."
"The Smalltalk Report" p25
https://rmod-files.lille.inria.fr/Archives/TheSmalltalkRepor...
"The Rise and Fall of Commercial Smalltalk"https://wirfs-brock.com/allen/posts/914
If Java had not been a think, Smalltalk would be doing just fine.
It was the already quite established in big corporations, all IBM IDEs in the Visual Age series were written in Smalltalk, it was the language used alongside C++ on the famous GoF book.
When Java came to be, IBM dropped all their Smalltalk investment and pivoted 100% into Java, Eclipse was the rewrite of Visual Age into Java.
And the fact that companies like Cincom are still in business shows the extent Smalltalk was being used in the 1990's.
Actually around 2000 before Eclipse (aka WSAD in IBM speak ;) they retargeted Visual Age for Java.
I've never done anything with Smalltalk, and what I know doesn't make me comfortable. For example, Visual Age stored all your code in an opaque "repository" (not a file-based one like cvs, svn, git). And a colleague of mine told me there are no source code files, just the running project that you share around and tinker with all the time.
Exactly because of that in Visual Age for C++ v4 (the version is relevant), you could have a Smalltalk like experience for C++, similar to Energize C++, something that has taken decades to get back and we aren't there yet, even with VC++ hot reload and Live++.
Image based source control has been a solved problem for Smalltalk since the 1990's.
It is also a good example of how the "Python is too dynamic for a JIT" reasoning doesn't play that well, as it surely isn't more dynamic than Smalltalk, SELF and Lisp images and development environments.
> all your code in an opaque "repository"
Without the scare quotes we'd call that a database.
"Product Revew, Object Technology's ENVY Developer"
https://www.google.com/books/edition/Mastering_ENVY_Develope...
Mastering ENVY/Developer"
https://www.google.com/books/edition/Mastering_ENVY_Develope...
> And a colleague of mine told me there are no source code files …
And that has always been not true !
GoogleI appreciate Sun creating things like Java and improving the performance of the JVM (adopting ideas from this Self runtime etc.) I don't know whether it made any money for them, but it certainly helped the rest of the computing field / industry.
Regarding Self's limited adoption, I think JavaScript showed that a Self-like system could be effective and popular if it used C-like syntax rather than Smalltalk-like syntax and shipped in every web browser.
NewtonScript showed that first, unfortunately Newton was a device ahead of its time.
https://newtonscript.org/
Strongtalk, the real thing closest to v8, is still closed.
Closest to Java, and Hotspot code is available, as is Strongtalk source code.
https://www.strongtalk.org/
This is a classic paper and descendents of its ideas show up in modern JITs for highly dynamic languages.
JavaScript owes a lot to Self, not only in its runtime but also its prototype-based object design (though perhaps that's something of a liability since class-based object systems turned out to be more popular.)
JavaScript's form of prototype OO is remarkably awful and confusing.
Yes but it's really good for building better object systems, especially with newer features like proxies. In the SELF days they implemented Smalltalk with prototypes and found that it was faster than normal Smalltalk implementations.
https://www.researchgate.net/profile/Mario-Wolczko/publicati...
Personally don't consider class based OO to be better.
I recently ran across an interesting postmortem critique of PataPata by its author Paul Fernhout, which was a Python implementation of some ideas from Squeak and Self, in which he discusses some inherent problems with prototype based object systems.
https://patapata.sourceforge.net/
>The PataPata project is/was an experiment focusing on taking ideas from Squeak and Self and moving them to Python, as well as trying to go beyond the ideas in a Pythonic and educational constructivist way.
>It also aspires to help people build microworlds and other learning tools for the Python platform, using a prototype-based programming approach.
>It is intended to mainly support "unschooling", "free schooling", and "informal" education.
>It has been previously discussed on the Python edusig list, although it now has its own mailing list on SourceForge here.
https://patapata.sourceforge.net/critique.html
>The biggest issue is that I learned that the seductive idea of prototypes may not be as powerful as its execution (especially as an add-on to an existing language). Consider what I wrote to someone else: "I've been repeatedly confronted with the fact that prototype languages are powerful and elegant but ultimately, like Forth, end up losing something related to documenting programmer intent. Documenting intent is one of the most important part of programming, and that is something that Smalltalk's formal class structure enforces for most code over Self, just like C's named variables document intent which gets lost manipulating Forth's data stack. Plus, it is hard for any great language feature to offset issues like lack of community or lack of comprehensive libraries."
>And after at person suggested you usually need to name things before you can share them, I replied: "And I agree on the issue of "naming" something in order to share it. Which gets back to the issue I mentioned of "documenting intent". With the PataPata system I made for Python, there was a choice point where I decided that prototypes used by other prototypes as parents needed to be named (a difference from Self). And I liked that choice. But then, what am I really gaining over Smalltalk (except not having a class side, which is nice, but is it worth the extra trouble and confusion?)"
>So, this leaves me questioning the whole move to prototypes. That person also pointed out previous work on "Exemplar based Smalltalk", so that is something I should look into further, perhaps as a compromise with Prototypes when I understand such previous work better.
[...]
I found some interesting email between Alan Kay and Guido van Rossum, in my archive of the OLPC educational software discussion group, where he hoped that the python community would make something like eToys. This is from a year after the last revision of PataPata's description, and I don't know if Alan was aware of PataPata. But I think "Snap!" (formerly BYOB) is the modern embodiment of what Alan was hoping for, based on JavaScript instead of Python. Python was (as Alan put it) "the general integrative base of XO", the focus and implementation language of the OLCP project.
https://snap.berkeley.edu
On Mar 9, 2007, at 17:26 , Guido van Rossum wrote:
Thanks Alan. I'm quite satisfied with this response and I agree with the priorities!
On 3/9/07, Alan Kay <alan.kay@squeakland.org> wrote:
Guido knows that I've been advocating that the Python folks should do Etoys or a very Etoys like environment in Python (and that the rest of the OLPC be given an objectification and media and scripting integration that is Etoys like).
However, there are simply zillions of things left to be done everywhere for OLPC so the first round of SW on the XO will be more of a gathering of "suggestive" features and abilities (of which Etoys is just one). That seems fine to me.
Viewpoints Research (our little non-profit) doesn't have any "ego or identity" staked around whether the children's authoring environment is Python based or Squeak based. I have said many times that, if the general integrative base of XO is to be Python, then the Etoys-like authoring should be based in Python also.
However, I will personally fight to the death to make sure that there is a children's authoring environment that allows even young children to do simulation style programming with very rich media objects.
For now, that is Etoys. It could be a suitable object-oriented Logo with media objects (this is essentially what Etoys is). It could be some better design (let's do one). The base could be Javascript (if implemented on top of an integrated environment of sufficient power), Python (ditto), Ruby (ditto), etc. Whatever it is, it has to be above high thresholds, not a hack or a gesture.
Besides the programming the children use to learn important ideas in math and science, they also need to be able to see how their own computer world is structured by being able to "pop the hood" on practically everything they use. Perhaps it is OK for high school children to see the current code (but I don't think so). I think there needs to be a wrapping on the entire set of facilities that uses the same conventions that 9 year olds do their own programming in. Again, if it is to be Python, then it needs to be crafted a bit for younger children. E.g. Etoys allows easy unlimited parallel tasking, and this is very important for children's programming. Etc.
There are many good things that can be done here. We live in a computing world in which there is a tremendous amount of identification between many programmers and the tools they use -- so strong that it resembles religious fervor. From my view, ALL of the system have such flaws that we are better off being critical of all of them and try to use the best ideas from everywhere.
If "Children First!" is really the goal here, then we must spend most of our energies trying to make the childrens' environments more conducive to creative learning of powerful ideas.
Cheers,
Alan
On 21 June 2007 Alan Kay Wrote:
Well, objects need some machinery behind them. The machinery could be Squeak, or it could be Python, or JS, or ...
As I've mentioned in the past, on the OLPC, one of the ways that integration could have been done (and still could be done) would be to use something like X windows without frames to allow compositing of graphical front-ends of media objects.
A composited collection would be what Etoys calls a "project", etc. From this point of view everything is like a widget but could be made from different stuff,
From the object perspective all the graphical properties of the objects/"windows" are the same, but the back-end drivers for the phenomena could be rather different. This is "windows without windows", which is kind of what the OLPC really needs.
Also, since Squeak allows plugins, all of this could be done in Squeak, but I don't think that is the point here. I would rather see a richer better architecture using the chosen paradigm (e.g. Python) than do any "language wars".
But I will just gently say again that "Sugar can and should be a lot more integrated in its approach to dealing with many different kinds of media objects. They really need to be combined freely and not be bound to applications but should all be able to populate any "document" or "project".) Etoys uses one way to do this.
Cheers,
Alan
On 21 June 2007 Alan Kay Wrote:
Hi Eben --
Yes.
Etoys has external formats for its "documents", so they can be stored on servers, fetched, passed around, etc. We have tried 3 different approaches over the years (and all work currently). One of the approaches uses the Open Doc standard (where the scripts are in there as non-standard data). The format we are using now is a form of s-expressions (could be XML, but XML is really too verbose for the XO and for slow networks).
And, as I mentioned in the previous email, when on an XO itself, all the media objects could be integrated as collections of frame-less X-windows (or some similar but simpler mechanism).
Etoys (and, better, an improvement in Etoys that has more age range) could be done in Python by writing a parser for one of the file formats and making the Etoys graphical environment and control in Python. This would completely unify these ideas on the XO -- but something more like the integrated architecture for many kinds of media objects would still have to be created.
In other words, Etoys per se are not nearly as important as the ideas and access to authoring power for children that they implement.
In any case, we are gradually working on the next version of an Etoys like environment that deals much more richly with more of the important issues for children's authoring than we do now.
Cheers,
Alan
----
Here's a lot more about this stuff, and what we were doing with NeWS, HyperLook, and SimCity:
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
Kind of always wished Alan Kay had spent some time playing with LambdaMOO back in the day. I know he was aware of it, but I think if he had really dug into it he would have dug it.
In a system like that, prototype OO makes so much sense. Objects are embodied "things" in the world. You can literally walk up to a "prototype" and touch it, move it, etc and dynamically inspect it (much like you'd do in Self, but in a form which is more narrative). And when you make things, you are building them on the basis of the other things, so.
Kay, Ingalls', etc work was really focused on getting pictures on the screen, and "objects" also made a lot of sense there.
I think the subsequent uses of object-orientation... everywhere else... and their conflation everywhere with (static) types ... has been problematic. I don't like the mixture of the C++/Java static early binding system with class hierarchies. At all.
I find JavaScript itself to be a pretty usable language (maybe somewhere between Python (easier) and Java (harder) or C++ (harder still)), but the browser DOM environment is a pain to deal with.
After understanding Self, I didn't find JavaScript's prototype system hard to understand.
I've got a book here on my shelf which is a summary book of all sorts of approaches in prototype OO programming:
https://www.goodreads.com/book/show/180324.Prototype_Based_P...
From that, and my experience with both Self and with other prototype OO languages (like LambdaMOO & offshoots), I just find the JS implementation to be ... uncomfortable.
Plus from the earliest days people just seemed to be embarassed by the prototype thing. They shouldn't have been.
Taivalsaari’s Kevo is a marvelous language.
Yes I remember liking the idea with that one. And thinking that its "clone families" were a bit like implicit structural typing in a way. And that perhaps there was a way one could do a kind of static typing & type inference with something based around similar ideas. (e.g. this method takes as an arg anything which structurally matches xxxx, which we could deduce via clone families, etc.)
I guess you are on the "liability" side, possibly.
It makes a lot more sense in languages like lua.
Java, and all living JITs, are hollow parodies of the Self environment.
Sure, if you want Java to be like Self. If you want Java to be closer to C++ it's a lot more reasonable.
Java is closer to Objective-C semantics, and by extension Smalltalk.
The C++ syntax was more of a way to help adoption, however the way the runtime works, and the language feature, are from those other influences.
https://cs.gmu.edu/~sean/stuff/java-objc.html
Even basic stuff like META-INF and jars, those are basically NeXTSTEP bundles.
> Java is closer to Objective-C semantics
How do you figure? It certainly doesn't use message passing. Boxing of primitives and use of interfaces/protocols strikes me as a rather shallow similarity.
First of all you read the point of view of Java authors on the linked post.
Second, yes interfaces are based on protocols.
You can do dispatching via Proxy classes, reflection, or invokedynamic that came later as performance improvement.
Then you have the classloaders for a similar purpose as Objective-C plugins.
Java Remote Invocation, RMI, works similarly to PDO, Portable Distributed Objects.
Sun collaborated with NeXT on OpenSTEP before Java came to be.
Another inspiration was Distributed Objects Everywhere framework, born as Objective-C, later rewriten in Java and rebranded as the first edition of Java EE.
Likewise Web Objects went from Objective-C, to dual Objective-C/Java shortly before NeXT was acquired.
Or toit, which unsurprisingly has Lars Bak involved. A man with history touching all self, Jvm and v8 codebases.
I wouldn't be surprised if toit primaries, Kasper or Florian also have experience in these technological intersections.
Are there any languages that combine the prototype inheritance with the actor model? They seem sort of orthogonal on the surface level.
One of my all time favorite and most influential papers! ("You're soaking in jit!")
But I always thought "dynamic deoptimization" should have been called "pessimization".
https://news.ycombinator.com/item?id=33527561
DonHopkins on Nov 9, 2022 | next [–]
A Conversation with Bjarne Stroustrup, Carl Hewitt, and Dave Ungar
https://web.archive.org/web/20150428011217/http://channel9.m...
https://donhopkins.com/home/movies/BjarneCarlDaveLangNEXT_mi...
They have a fascinating (and polite, respectful) argument about shared memory, message passing, locks, synchronization, and lock free message passing!
https://news.ycombinator.com/item?id=45315685
DonHopkins 35 days ago | parent | context | favorite | on: Help us raise $200k to free JavaScript from Oracle
SelfishScript. JavaScript credits Self as inspiration, but misses all the important things about Self.
JavaScript copied:
The name "Java", cynically chosen for marketing misdirection, not technical truth.
The word "prototype" from Self, but turned it into a quirky pseudo-class system. Instead of living objects delegating naturally, with multiple inheritance dynamically changeable at runtime, JavaScript glued on a weird constructor-function pattern that always confuses people, with constructors you have to call with new but can also uselessly call as normal functional foot-guns.
JavaScript missed:
The fluid, live object experience (JavaScript dev environments were never designed around exploration like Self’s Morphic).
The elegance of uniformity (JavaScript bolted on primitives, type coercions, and special cases everywhere).
The idea that the environment mattered as much as the language. Netscape didn’t ship with the kind of rich, reflective tools that made Self shine.
And most important of all: Self's simplicity! The original Self paper (Ungar & Smith, 1987, “Self: The Power of Simplicity”) was all about stripping away everything unnecessary until only a uniform, minimal object model remained. The title wasn’t ornamental, it was the thesis.
Simplicity. Uniformity. Minimal semantics. A clean consistent model you can hold in your head. Less semantic baggage frustrating JIT compiler optimization. Dynamic de-optimization (or pessimization as I like to call it).
Self proved that expressive power comes from radical simplicity.
JavaScript showed that market dominance comes from compromise (worse is better, the selfish gene).
JavaScript should be called SelfishScript because it claimed Self’s legacy but betrayed its central insight: that simplicity is not just aesthetic, it’s the whole design philosophy.
senderpath [Dave Ungar] 33 days ago [–]
Yes, indeed! It's a design philosophy, and one that the market does not always reward. I suspect that for many, it is either not salient, or unimportant. Design is subjective, and multi-dimensional.
Thank you, Don for seeing and writing about this dimension.
https://news.ycombinator.com/item?id=33527618
DonHopkins on Nov 9, 2022 | parent | context | favorite | on: The influence of Self
I wrote this in a discussion with Tom Lord in 2006 (a couple years before Lars Bak developed V8 at Google), after I ran into Dave when he was interviewing at Laszlo Systems, and he showed a demo of his latest Self system:
>I just ran into Dave Ungar (of Self fame), and mentioned how ironic it was that JavaScript pointed to Self as its inspirational prototype (vis-a-vis JavaScript's prototype based object system), but JavaScript totally missed the boat on efficient compile-ability, which is the most interesting thing about Self. (I mean, anybody can make a prototype oop system that runs slow, but it takes a fucking genius to come up all the brilliant stuff in Self, like the aggressive inlining compiler (it has no byte code interpreter, just a bad-ass compiler), incremental compilation, polymorphic inline cache, coupled with dynamic de-optimization to make it debuggable). He gave a cool Self demo of writing a straightforward factorial function, then editing the source to the system's multiplication operator, so it would return a different result if you multiplied something by 1,000,000. Then he showed how it affected the factorial function, as well as the rest of the system, which incrementally recompiled itself as needed. All that and perfect debuggability, too! About JavaScript, he retorted that it was actually possible to efficiently compile JavaScript if you were really devious enough. Too bad the art of designing languages so you don't have to be devious in order to compile them, was lost of so many popular bad language designers (PHP, JavaScript, Perl, etc).
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
> but JavaScript totally missed the boat on efficient compile-ability, which is the most interesting thing about Self
That's making much use of hindsight though: the creators of Self didn't think it would run fast, until it did [0]. The HOPL paper on Self [1] spends many words recounting the challenge of making Self fast.
[0] This is arguably a stronger claim than what appears in HOPL; I think it's from a talk by Dave Ungar, I'd have to check.
[1] https://dl.acm.org/doi/10.1145/1238844.1238853
[0] is Self and Self: Whys and Wherefores <https://youtu.be/3ka4KY7TMTU?si=Js_oG3MneCxBtEql&t=2378>
> And at the time, we thought it was impossible to make this language run efficiently, because it did all these things that were more abstract than languages of the time ...
(1989)
There is a lot to be learned from reading historical CS texts. It helps us see how developers worked under constraint of historical hardware and it also helps us find commonalities to modern problems. There is a lot to be said about software engineering challenges that are a problem today and a problem decades ago. This creates a clearer picture of blind spots in the industry and reading outdated texts can be a fruitful endeavor despite seeming counterintuitive. I have a small collection of CS books that I have purchased from a used bookstore and I always walk away with new insights when I read them even if the information is outdated.
Thank you for your tone. I agree! Had Starting Forth, Thinking Forth, and Elizabeth D Rather books at one time. Reread TCL the Misunderstood (Antirez), every few years for the memoizing bit. Etc.
To the critics of parent, the reason we add dates and people make such posts is so HN users can know if it is something they read or something new or just something new to them. So when OP forgets the date, we make a post with the date so OP or the mods can edit the title.
nothing better to add?
I will read it, closely, but was all hopped-up expecting some new implementation, as I am down the Smalltalk rabbit hole lately, including watching lots of old videos. And perusing https://selflanguage.org
It's the convention on HN to add the year of an article at the end of a title in parens. Users often cue us to do this by posting the year in the comments. They aren't being dismissive—it's just an obscure little custom!