4 ms·

A clarifying comment here. When one thinks in terms of what I called objects ca 1966, one is talking about entities that from the outside are identical to what

A clarifying comment here. When one thinks in terms of what I called objects ca 1966, one is talking about entities that from the outside are identical to what we think of as computers (and this means not just sending messages and getting outputs, but that we don't get to look inside with our messages, and our messages don't get to command, unless whatever is going on in the interior of the computer has decided to allow. So from the outside, there are no imperatives, only requests and questions. Another way to look at this is that an object/computer is a kind of "server" (I worry to use this term because it also has "pop" meanings, but it's a good term.) This is sometimes called "total encapsulation". From this standpoint, we don't know what's inside. Could be just hardware. Could be variables and methods. Could be some form of ontology. Or mix and match. This is the meaning of computers on a network, especially large worldwide ones. The basic idea of "objects" is that what is absolutely needed for doing things at large scale, can be supplied in non-complex terms for also doing the small scale things that used to be done with data structures and procedures. Secondarily, some of the problems of data structures and procedures at any scale can be done away with by going to the "universal servers in systems" ideas. Similarly, what we have to do for critical "data structures" -- such as large scalings, "atomic transactions", versions, redundancy, distribution, backup, and "procedural fields" (such as the attribute "age") are all more easily and cleanly dealt with using the idea of "objects". One of the ways of looking at what happened in programming is that many if not most of the naive ways to deal with things when computers were really small did not scale up, but most programmers wanted to stay with the original methods, and they taught next gen programmers the original methods, and created large fragile bodies of legacy code that requires experts in the old methods to maintain, fix, extend ...

shalabhc 9y ago
> So from the outside, there are no imperatives, only requests and questions. This threw me off a bit as Smalltalk collections have imperative style messages for instance. > Could be some form of ontology. This remark helped me find some clarity. I want the computer to help me do cross ontological reasoning and mapping. For instance, if I want to compute geometry, how do I map the ontology of 'geometry' onto the ontology of 'smalltalk'? I 'think up' the mapping, but it would be great if the computer helps me here too. Mapping 'smalltalk' onto 'physical machines' is another ontological mapping. The 'mapping of ontologies' is itself an ontology. In large systems there are a lot of ontological 'views' and 'mappings' at play. I want to inspect and tweak each independently using the language on the ontology, and have the computers automatically map my requests to the physical layer in an efficient way. This is not possible in systems today because there an incredible amount of pre-translation that happens so a high level questions cannot be directly answered by the system - I have to track it down manually to a different level. Maybe the answer is to define the ontologies as object collections and have them talk to each other and figure it out. I want to tweak things after the system is up, of course, so I could send an appropriate message (e.g. 'change the bit representation of integers' or 'change the strategy used in mapping virtual objects to physical') and everything affected would be updated automatically (is this 'extreme late binding'?).
- alankay1 9y ago
  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
> Could be just hardware. Could be variables and methods. Could be some form of ontology. ... > more easily and cleanly dealt with using the idea of "objects". OK after this sitting in my mind for a bit longer something 'clicked'. What I'm thinking now is that there are many types of 'computer algebra' that can be designed. Data structures and procedures are only one such algebra - but they have taken over almost all of our mainstream thinking. So instead of designing systems with better suited algebra, we tend to map problems back to the DS+procedures algebra quickly. Smalltalk is well suited to represent any computer algebra (given the DS/procedure algebra is implemented in some 'objects', not the core language). > created large fragile bodies of legacy code that requires experts in the old methods to maintain, fix, extend If I understand correctly you are saying that better methods would involve objects and 'algebra' that perhaps don't involve data structures and procedures at all, even all the way down for some systems.
- alankay1 9y ago
  Mathematics is a plural for a reason. The idea is to invent ways to represent and infer that are not just effective but help thinking. I don't think Smalltalk is well suited to represent any algebra (the earliest version (-72) was closer, and the next phase of this would have been much closer as a "deep" extensible language. A data structure is something that allows fields to be "set" from the outside. This is not a good idea. My original approach was to try to tame this, but I then realized that you could replace "commands" with "requests" and imperatives with setting goals.
  - shalabhc 9y ago
    > and the next phase of this would have been much closer as a "deep" extensible language. Are these ideas (and the 'address space of objects') elaborated on somewhere? > A data structure is something that allows fields to be "set" from the outside. This is not a good idea. My original approach was to try to tame this, but I then realized that you could replace "commands" with "requests" and imperatives with setting goals. I agree with in principle - but I'm having trouble imagining computing completely without data structures though (and am reading 'Early History of Smalltalk' to see if it clicks.)

shalabhc 9y ago

> So from the outside, there are no imperatives, only requests and questions. This threw me off a bit as Smalltalk collections have imperative style messages for instance. > Could be some form of ontology. This remark helped me find some clarity. I want the computer to help me do cross ontological reasoning and mapping. For instance, if I want to compute geometry, how do I map the ontology of 'geometry' onto the ontology of 'smalltalk'? I 'think up' the mapping, but it would be great if the computer helps me here too. Mapping 'smalltalk' onto 'physical machines' is another ontological mapping. The 'mapping of ontologies' is itself an ontology. In large systems there are a lot of ontological 'views' and 'mappings' at play. I want to inspect and tweak each independently using the language on the ontology, and have the computers automatically map my requests to the physical layer in an efficient way. This is not possible in systems today because there an incredible amount of pre-translation that happens so a high level questions cannot be directly answered by the system - I have to track it down manually to a different level. Maybe the answer is to define the ontologies as object collections and have them talk to each other and figure it out. I want to tweak things after the system is up, of course, so I could send an appropriate message (e.g. 'change the bit representation of integers' or 'change the strategy used in mapping virtual objects to physical') and everything affected would be updated automatically (is this 'extreme late binding'?).

alankay1 9y ago
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

> Could be just hardware. Could be variables and methods. Could be some form of ontology. ... > more easily and cleanly dealt with using the idea of "objects". OK after this sitting in my mind for a bit longer something 'clicked'. What I'm thinking now is that there are many types of 'computer algebra' that can be designed. Data structures and procedures are only one such algebra - but they have taken over almost all of our mainstream thinking. So instead of designing systems with better suited algebra, we tend to map problems back to the DS+procedures algebra quickly. Smalltalk is well suited to represent any computer algebra (given the DS/procedure algebra is implemented in some 'objects', not the core language). > created large fragile bodies of legacy code that requires experts in the old methods to maintain, fix, extend If I understand correctly you are saying that better methods would involve objects and 'algebra' that perhaps don't involve data structures and procedures at all, even all the way down for some systems.

alankay1 9y ago
Mathematics is a plural for a reason. The idea is to invent ways to represent and infer that are not just effective but help thinking. I don't think Smalltalk is well suited to represent any algebra (the earliest version (-72) was closer, and the next phase of this would have been much closer as a "deep" extensible language. A data structure is something that allows fields to be "set" from the outside. This is not a good idea. My original approach was to try to tame this, but I then realized that you could replace "commands" with "requests" and imperatives with setting goals.
- shalabhc 9y ago
  > and the next phase of this would have been much closer as a "deep" extensible language. Are these ideas (and the 'address space of objects') elaborated on somewhere? > A data structure is something that allows fields to be "set" from the outside. This is not a good idea. My original approach was to try to tame this, but I then realized that you could replace "commands" with "requests" and imperatives with setting goals. I agree with in principle - but I'm having trouble imagining computing completely without data structures though (and am reading 'Early History of Smalltalk' to see if it clicks.)