5 ms·

> 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".

> 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.)
  - alankay1 9y ago
    You need to have "things that can answer questions". I'd like to get the "right answer" when I ask a machine for someone's date of birth, and similarly I'd like to get the right answer when I ask for their age. It's quite reasonable that the syntax in English is the same. ? Alan's DOB ? Alan's age Here "?" is a whole computer. We don't know what it will do to answer these questions. One thing is for sure: we are talking to a -process- not a data structure! And we can also be sure that to answer the second it will have to do the first, it will have to ask another process for the current date and time, and it will have to do a computation to provide the correct answer. The form of the result could be something static, but possibly something more useful would to have the result also be a process that will always tell me "Alan's age" (in other words more like a spreadsheet cell (which is also not "data" but a process)). If you work through a variety of examples, you will (a) discover that questions are quite independent of the idea of data, and (b) that processes are the big idea -- its just that some of them change faster or slower than others. Add in a tidy mind, and you start wanting languages and computing to deal with processes, consistency, inter-relations, and a whole host of things that are far beyond data (yet can trivially simulate the idea in the few cases its useful). On the flip side, you don't want to let just anybody change my date of birth willy nilly with the equivalent of a stroke of a pen. And that goes for most answers to most questions. Changes need to be surrounded by processes that protect them, allow them to be rolled back, prevent them from being ambiguous, etc. This is quite easy stuff, but you have to start with the larger ideas, not with weak religious holdovers from the 50s (or even from the way extensional way math thinks via set theory).
    - shalabhc 9y ago
      Thank you for the elaboration! (And for anyone else reading this thread I found an old message along the same topic: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...) I'm thinking along these lines now: decompose systems along lines of 'meaning', not data structures (data structures add zero meaning and are a kind of 'premature materialization'), design messages first, late bind everything so you have the most options available for implementation details, etc. The other thing I'm thinking is why have only one way to implement the internal process of an object/process? There are often multiple ways to accomplish goals, so allow multiple alternative strategies for responding to the same message and let objects choose one eventually. Edit: wanted to add that IIUC, 'messages' doesn't imply an implementation strategy - i.e. they are messages in the world of 'meaning'. In the world of implementation, they may just disappear (inlined/fused) or not (physical messages across a network), depending on how the objects have materialize at a specific point in time.

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.)
- alankay1 9y ago
  You need to have "things that can answer questions". I'd like to get the "right answer" when I ask a machine for someone's date of birth, and similarly I'd like to get the right answer when I ask for their age. It's quite reasonable that the syntax in English is the same. ? Alan's DOB ? Alan's age Here "?" is a whole computer. We don't know what it will do to answer these questions. One thing is for sure: we are talking to a -process- not a data structure! And we can also be sure that to answer the second it will have to do the first, it will have to ask another process for the current date and time, and it will have to do a computation to provide the correct answer. The form of the result could be something static, but possibly something more useful would to have the result also be a process that will always tell me "Alan's age" (in other words more like a spreadsheet cell (which is also not "data" but a process)). If you work through a variety of examples, you will (a) discover that questions are quite independent of the idea of data, and (b) that processes are the big idea -- its just that some of them change faster or slower than others. Add in a tidy mind, and you start wanting languages and computing to deal with processes, consistency, inter-relations, and a whole host of things that are far beyond data (yet can trivially simulate the idea in the few cases its useful). On the flip side, you don't want to let just anybody change my date of birth willy nilly with the equivalent of a stroke of a pen. And that goes for most answers to most questions. Changes need to be surrounded by processes that protect them, allow them to be rolled back, prevent them from being ambiguous, etc. This is quite easy stuff, but you have to start with the larger ideas, not with weak religious holdovers from the 50s (or even from the way extensional way math thinks via set theory).
  - shalabhc 9y ago
    Thank you for the elaboration! (And for anyone else reading this thread I found an old message along the same topic: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...) I'm thinking along these lines now: decompose systems along lines of 'meaning', not data structures (data structures add zero meaning and are a kind of 'premature materialization'), design messages first, late bind everything so you have the most options available for implementation details, etc. The other thing I'm thinking is why have only one way to implement the internal process of an object/process? There are often multiple ways to accomplish goals, so allow multiple alternative strategies for responding to the same message and let objects choose one eventually. Edit: wanted to add that IIUC, 'messages' doesn't imply an implementation strategy - i.e. they are messages in the world of 'meaning'. In the world of implementation, they may just disappear (inlined/fused) or not (physical messages across a network), depending on how the objects have materialize at a specific point in time.