Hacker News Reader

Comment by blihp | Hacker News Reader

Squeak[1]/Smalltalk? (i.e. have you worked with what he would consider a 'real' message-oriented OO language?)

I played around with Squeak many years ago, but might appreciate it more now.

What recently spurred more confusion on this topic was Alan Kay's discussion with Rich Hickey during the AMA the other day. https://news.ycombinator.com/item?id=11945722

I found it really hard to understand what Alan Kay is actually talking about. Saying things like

> This is why "the objects of the future" have to be ambassadors that can negotiate with other objects they've never seen.

This seems like something that (based on my limited knowledge) isn't possible with Smalltalk (in any but the most trivial of cases), and so I don't really consider it an example of what he is talking about. Or, at least, all of the things that I know of that you can do with this you could just as easily implement in languages without the same dynamism as Smalltalk.

My conclusion after reading all of that is that Kay is talking about a system so completely unlike anything we have that there aren't even really examples of what it would look like.

I am really trying to understand what Kay is talking about, so any pointers would be interesting!

You are correct, Smalltalk as-is can't currently do that. I believe he was referring to a future language / evolution / system that he would like to see, not something that currently exists. These are the sorts of things I think he's expressing his frustration about when he says things like Smalltalk getting long in the tooth etc. in that it was never intended to the be-all, end-all of languages... just one stop along a path.

But don't let this discourage you from looking into Squeak. I played around with Squeak in the 90's but couldn't see past things like the weird mouse button mappings and color scheme. Fortunately I came back to it again and found some of the glaring UI issues (by modern standards) had been smoothed over. It also probably didn't hurt that I was a little older and better able to stick with it until I could finally see better the second go at it what the original vision was. Also, there is the work from his STEPS project which used Squeak as a platform that was used to prototype some of the next-generation ideas he talks about.

If you want to understand better the next generation concepts, definitely look at the VPRI writings (esp. the STEPS annual reports) linked to in a previous post. To bridge the gap from here to there (i.e. to get to a tangible system that you can actually use that does any of this) I think you're probably going to want to learn Smalltalk as a starting point.

Here's my understanding of the general idea (let me know if I got something wrong!). Say you have a bunch of computers with different software and hardware. You come up with a cool new image format called "PJEG". To get the images to show up on all the computers, you typically do the following:

    * Publish a PJEG spec
    * Define a .pjeg extension and let everyone know that means it's
      a PJEG file
    * Write a PJEG encoder/viewer for each kind of computer
    * Distribute these programs to the computers
    * Configure the computers to open .pjeg files using the programs
      you distributed
    * Modify other programs (image editors, web browsers) so they
      can recognize, encode and view PJEG files as well
    * etc...

This approach doesn't scale very well. I think the alternative Alan is suggesting is that you'd include an interpretable description of the file format in the file itself in a sort of meta-format. Once you have an interpreter for these meta-format descriptions, all you'd have to do is:

    * Include an interpretable PJEG encoder/viewer with every PJEG file

And that's all! Any program able to read the meta-format could use this file without any extra software. This obviates file type metadata and reduces the amount of distribution you need to do, making the whole thing way more scalable. The practical problems with this solution (larger file size, slow encoding and decoding) can be solved in various ways:

    * The larger file size can be mitigated by format negotiation
      (if I already know about the format, you don't have to tell
      me about it)
    * Optimized encoders and decoders can be written to replace the
      slower interpreted ones included with the file

Having the interpreted format description makes it easier to validate the optimized version, too (you can generate a bunch of random examples and make sure they decode/encode the same way). And this doesn't have to just be for files, you can use the same technique for arbitrary "data types" in your program as well.

An interesting idea but wouldn't this require a universal interpreter and format to decode to?

Seems a like certain things on the web already. Just the bounds on what the "file" is are a bit messy.

Not necessarily. That was one of the points Alan made in his AMA when suggesting 'send processes rather than messages'[1] That thread used the example of how to find things and then what to do when you find them.

[1] https://news.ycombinator.com/item?id=11948686

This would require that any new image format only did things that were foreseen by the creators of the metalanguage. If the metalanguage is Turing complete then it's just an interpreter. Python, for example, could be your metalanguage. Then I would argue that we already have this.

Great example. I'll add that the "compile everything to Javascript" ecosystem shows that it's easily possible. Arguably, it's already being done for web stuff just not below a certain level of the stack. There were related fields that did this stuff called agent-oriented programming and meta protocols.

https://en.wikipedia.org/wiki/Agent-oriented_programming

https://en.wikipedia.org/wiki/Obliq

https://en.wikipedia.org/wiki/Meta-object_protocol

https://en.wikipedia.org/wiki/OMeta

In agent-oriented programming, one could send the code and data packaged together to the remote site. It could do any necessary computation there through the platform's interface to prevent lots of data being transfered. It might also do typical RPC's on remote sites. As it was interpreted, it could in theory even modify itself to use a different communication or storage method.

For meta-objects, that was just ways to create other objects. Starts with stuff like CLOS and Smalltalk that's really about clever ways to specify systems. Also allows self-modifying or improving code. Later versions, applicable here, allowed one to specify protocols or interfaces that meta-tools would turn into libraries for one's programs. Some even had interpreters built-in so apps could negotiate arbitrary protocols during runtime. Such tech gets us closer to the idea of focusing on a higher level and how things communicate rather than their state and coding specific procedures for sharing it.

Probably totally wrong but here is what I took away:

It kind of reminds me of bounded contexts like the ones from http://martinfowler.com/bliki/BoundedContext.html

When being complex information systems you ended with subtle drifting in what something actually means from person to person or over time.

More directly in regards to having ambassadors working with unseen objects:

Seems like you would need some shared "language" the objects speak otherwise communication is impossible. Maybe a better way of describing intent or information? Like some kind of logical or declarative model + messages.

Also come to think of it reminds me of: https://en.wikipedia.org/wiki/Intentional_programming

Yes, I agree.

And it also reminds me of https://en.wikipedia.org/wiki/Smart_contract and one can see how different block-chains need different interpreters to understand what computation are needed in order to "execute" the message.

About intential programming, see DCI http://www.fulloo.info/

>The essence of object orientation is that networks of collaborating objects work together to achieve a common goal. > The common sense of object oriented programming should reflect this essence with code that specifies how the objects collaborate. Our industry has, unfortunately, chosen differently and code is commonly written in terms of classes. > A class tells us everything about the properties of the individual objects that are its instances. It does not tell us anything about how these instances work together to achieve the system behavior.

Regarding Smalltalk, I don't think Alan Kay has ever felt it was a pinnacle of language design (or even a complete implementation of his ideas). He has said in several talks that while Smalltalk was a PARC project it saw many re-imaginings, but once it went out into the world it basically was frozen and hasn't changed since 1976. Here's a good history of Smalltalk - http://worrydream.com/EarlyHistoryOfSmalltalk/.

Reply on news.ycombinator.com