Hacker News
An Efficient Implementation of SELF (1989) [pdf]
cmrdporcupine
|next
[-]
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.
jecel
|root
|parent
|next
[-]
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
cmrdporcupine
|root
|parent
[-]
Or maybe I'm just recalling what you're talking about with post-cancellation changes.
jecel
|root
|parent
[-]
# 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.
wmf
|root
|parent
|next
|previous
[-]
igouy
|root
|parent
|next
[-]
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...
~
pjmlp
|root
|parent
|previous
[-]
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.
tannhaeuser
|root
|parent
[-]
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.
pjmlp
|root
|parent
|next
[-]
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.
igouy
|root
|parent
|next
|previous
[-]
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...
igouy
|root
|parent
|previous
[-]
And that has always been not true !
$ cat fact.st
Stdio stdout
nextPutAll: 100 factorial printString;
nextPut: Character lf.!
SmalltalkImage current snapshot: false andQuit: true!
$ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
smalltalk sources file
musicale
|root
|parent
|next
|previous
[-]
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.
jasonwatkinspdx
|next
|previous
[-]
musicale
|root
|parent
[-]
cmrdporcupine
|root
|parent
[-]
rileyphone
|root
|parent
|next
[-]
https://www.researchgate.net/profile/Mario-Wolczko/publicati...
cmrdporcupine
|root
|parent
[-]
DonHopkins
|root
|parent
[-]
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.
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...
cmrdporcupine
|root
|parent
[-]
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.
musicale
|root
|parent
|next
|previous
[-]
After understanding Self, I didn't find JavaScript's prototype system hard to understand.
cmrdporcupine
|root
|parent
[-]
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.
woolybully
|root
|parent
[-]
cmrdporcupine
|root
|parent
[-]
markhahn
|next
|previous
[-]
MangoToupe
|root
|parent
|next
[-]
pjmlp
|root
|parent
[-]
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.
MangoToupe
|root
|parent
[-]
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.
pjmlp
|root
|parent
[-]
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.
user____name
|next
|previous
[-]
DonHopkins
|next
|previous
[-]
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).
hayley-patton
|root
|parent
[-]
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.
hayley-patton
|root
|parent
[-]
> 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 ...