2 ms·

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

by mej10 10y ago

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 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!

blihp 10y ago
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.
panic 10y ago
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.
- robohamburger 10y ago
  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.
  - blihp 10y ago
    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 https://news.ycombinator.com/item?id=11948686
robohamburger 10y ago
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 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 https://en.wikipedia.org/wiki/Intentional_programming
- brutuscat 10y ago
  Yes, I agree. And it also reminds me of https://en.wikipedia.org/wiki/Smart_contract 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/ 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.
infinite8s 10y ago
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/ http://worrydream.com/EarlyHistoryOfSmalltalk/.

by mej10 10y ago

blihp 10y ago

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.

panic 10y ago

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.

robohamburger 10y ago
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.
- blihp 10y ago
  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 https://news.ycombinator.com/item?id=11948686

robohamburger 10y ago

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 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 https://en.wikipedia.org/wiki/Intentional_programming

brutuscat 10y ago
Yes, I agree. And it also reminds me of https://en.wikipedia.org/wiki/Smart_contract 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/ 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.

infinite8s 10y ago

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/ http://worrydream.com/EarlyHistoryOfSmalltalk/.