4 ms·

Yes, "collections" and other such things in Smalltalk are "the Christian Scientists with appendicitis". Our implementations were definitely compromises between

Yes, "collections" and other such things in Smalltalk are "the Christian Scientists with appendicitis". Our implementations were definitely compromises between seeing how to be non-imperative vs already having the "devil's knowledge" of imperative programming. One of the notions we had about objects is that if we had to do something ugly because we didn't have a better idea, then we could at least hide it behind the encapsulation and the fact that message sending in the Smalltalks really is a request. Another way of looking at this is if an "object" has a "setter" that directly affects a variable inside then you don't have a real object! You've got a data structure however much in disguise. Another place where the "sweet theory" was not carried into reality was in dependencies of various kinds. Only some important dependencies were mitigated by the actual Smalltalks. Two things that helped us were that we did many on the fly changes to the system over 8-10 years -- about 80 system releases -- and including a new language every two years. This allowed to avoid getting completely gobbed up. The best and largest practical attempt at an ontology is in Doug Lenat's CYC. The history of this is interesting and required a number of quite different designs and implementations to gather understanding.

shalabhc 9y ago
> Yes, "collections" and other such things in Smalltalk are "the Christian Scientists with appendicitis". Interesting to hear this perspective - drives home the point that we shouldn't just stop at generic late bound data structures. > Only some important dependencies were mitigated by the actual Smalltalks. Dependency management in today's systems is just mind numbing. If only we had a better way to name and locate these.
- mmiller 9y ago
  One of the things I've realized is that using names for locating what's needed (I assume we're talking about the same idea) is part of the problem. At small scales it's fine. As systems get bigger, it becomes a problem. The internet went through this. When it started as the Arpanet, there was (if I remember correctly) one guy who kept the directory of names for each system on the network. The network started small, so this could work. As it grew into the thousands of nodes, this became less manageable, partly because there started to be duplicate requests for the same name for different nodes--naming conflicts, which is why DNS was created, and why ICANN was ultimately created, to settle who got to use which names. I doubt something like that, though, would scale properly for code, though many organizations have tried that, by having software architects in charge of assigning names to entities within programs. The problem then comes when companies/organizations try to link their systems together to work more or less cooperatively. I heard despondent software engineers talk about this 15 years ago, saying, "This is our generation's Vietnam." (They didn't lack for the ability to exaggerate, but the point was they could not "win" with this strategy.) They were hoping to build this idea of the semantic web, but different orgs. couldn't agree on what terms meant. They'd use the same terms, but they would mean different things, and they couldn't make naming things work across domains ("domains" in more than one dimension). So, we need something different for locating things. Names are fine for humans. We could even have names in code, but they wouldn't be used for computers to find things, just for us. If we need to disambiguate, we can find other features to help, but computing needs something, I think, that identifies things by semantic signifiers, so that even though we use the same names to talk about them, computers can disambiguate by what they actually need by function. It wouldn't get rid of all redundancy, because humans being humans, economics and competition are going to promote some of that, but it would help create a lot more cooperation between systems.
  - shalabhc 9y ago
    > One of the things I've realized is that using names for locating what's needed (I assume we're talking about the same idea) is part of the problem. I don't think naming itself a problem if you have a fully decentralized system. E.g., each agent (org or person) can manage their namespace any way they choose in a single global virtual namespace. I'm imagining something like ipfs/keybasefs/upspin, but for objects, not files, and with some immutability and availability guarantees. But yes, there should probably be other ways to find these things, using some kind of semantic lookup/negotiation.
    - alankay1 9y ago
      What he means is that names are a local convention, and scaling soon obliterates the conventions. Then you need to go to descriptions that use a much smaller set of agreed on things (and you can use the "ambassador" idea from the 70s as well).
      - scroot 9y ago
        A few year ago when I was doing some historical research about DNS, I came across quite a few interesting papers that all discussed "agents" in a way that seemed based on some shared knowledge/assumptions people had at the time. In particular, these would be agents for locating things in the "future internetwork". There's a paper by Postel and Mockapetris that comes to mind. Is this an example of "ambassadors"?
      - shalabhc 9y ago
        Ah I see, we're taking about interoperability, not just naming. This is related to my original interest in language structure words and ontologies. The idea there is that the set of 'relationships' between things is small and universal (X 'contains' Y, A 'is an abstraction of' B) and perhaps can be used to discover and 'hook up' two object worlds that are from different domains.
  - alankay1 9y ago
    Yes, this got very clear in a hurry even in the ARPAnet days, and later at Parc. (This is part of the Licklider "communicating with aliens" problem.) Note that you could do a little of this in Linda, and quite a bit more in a "2nd order Linda". I've also explained the idea of "processes as 'ambassadors'" in various talks (including a recent one to the "Starship Congress").

shalabhc 9y ago

> Yes, "collections" and other such things in Smalltalk are "the Christian Scientists with appendicitis". Interesting to hear this perspective - drives home the point that we shouldn't just stop at generic late bound data structures. > Only some important dependencies were mitigated by the actual Smalltalks. Dependency management in today's systems is just mind numbing. If only we had a better way to name and locate these.

mmiller 9y ago
One of the things I've realized is that using names for locating what's needed (I assume we're talking about the same idea) is part of the problem. At small scales it's fine. As systems get bigger, it becomes a problem. The internet went through this. When it started as the Arpanet, there was (if I remember correctly) one guy who kept the directory of names for each system on the network. The network started small, so this could work. As it grew into the thousands of nodes, this became less manageable, partly because there started to be duplicate requests for the same name for different nodes--naming conflicts, which is why DNS was created, and why ICANN was ultimately created, to settle who got to use which names. I doubt something like that, though, would scale properly for code, though many organizations have tried that, by having software architects in charge of assigning names to entities within programs. The problem then comes when companies/organizations try to link their systems together to work more or less cooperatively. I heard despondent software engineers talk about this 15 years ago, saying, "This is our generation's Vietnam." (They didn't lack for the ability to exaggerate, but the point was they could not "win" with this strategy.) They were hoping to build this idea of the semantic web, but different orgs. couldn't agree on what terms meant. They'd use the same terms, but they would mean different things, and they couldn't make naming things work across domains ("domains" in more than one dimension). So, we need something different for locating things. Names are fine for humans. We could even have names in code, but they wouldn't be used for computers to find things, just for us. If we need to disambiguate, we can find other features to help, but computing needs something, I think, that identifies things by semantic signifiers, so that even though we use the same names to talk about them, computers can disambiguate by what they actually need by function. It wouldn't get rid of all redundancy, because humans being humans, economics and competition are going to promote some of that, but it would help create a lot more cooperation between systems.
- shalabhc 9y ago
  > One of the things I've realized is that using names for locating what's needed (I assume we're talking about the same idea) is part of the problem. I don't think naming itself a problem if you have a fully decentralized system. E.g., each agent (org or person) can manage their namespace any way they choose in a single global virtual namespace. I'm imagining something like ipfs/keybasefs/upspin, but for objects, not files, and with some immutability and availability guarantees. But yes, there should probably be other ways to find these things, using some kind of semantic lookup/negotiation.
  - alankay1 9y ago
    What he means is that names are a local convention, and scaling soon obliterates the conventions. Then you need to go to descriptions that use a much smaller set of agreed on things (and you can use the "ambassador" idea from the 70s as well).
    - scroot 9y ago
      A few year ago when I was doing some historical research about DNS, I came across quite a few interesting papers that all discussed "agents" in a way that seemed based on some shared knowledge/assumptions people had at the time. In particular, these would be agents for locating things in the "future internetwork". There's a paper by Postel and Mockapetris that comes to mind. Is this an example of "ambassadors"?
    - shalabhc 9y ago
      Ah I see, we're taking about interoperability, not just naming. This is related to my original interest in language structure words and ontologies. The idea there is that the set of 'relationships' between things is small and universal (X 'contains' Y, A 'is an abstraction of' B) and perhaps can be used to discover and 'hook up' two object worlds that are from different domains.
- alankay1 9y ago
  Yes, this got very clear in a hurry even in the ARPAnet days, and later at Parc. (This is part of the Licklider "communicating with aliens" problem.) Note that you could do a little of this in Linda, and quite a bit more in a "2nd order Linda". I've also explained the idea of "processes as 'ambassadors'" in various talks (including a recent one to the "Starship Congress").