3 ms·

Quite the contrary: Everything should be data. Even the lines of code. The values of variables and constants. We can't have AI if we can't rewrite the code. It

Quite the contrary: Everything should be data. Even the lines of code. The values of variables and constants. We can't have AI if we can't rewrite the code. It's super hard to rewrite 1's and 0's, but if our lines of code are the data, then all we need to do is update a row in a database to rewrite the program. We can automate this. Even now our code is data. We could automate a program to upload a new source code file to github and then redeploy ourselves to the appropriate nodes.

bunderbunder 8y ago
What Kay was getting at there is a bit difficult for me to follow, but I'm pretty sure that he meant something different than that. Something more specific and constrained. What you're describing sounds to me like a very LISP-y view of data. Alan Kay, by his own admission, wasn't very versed in the LISP tradition - based on what he's describing, at the time he was pretty deeply immersed in the more ALGOL-y side of the world, back in a time long before there was much cross-pollination between the two camps, and that would presumably have influenced his thinking. So, semi-wild conjecture: It seems to me like what he was really getting at is that he wanted to get rid of the heap. Or at least shove it deeply into "implementation detail" territory, the same way languages like Haskell try to banish any evidence of the existence of memory registers from the programmer's consciousness. In so many languages in the imperative tradition, the standard practice was to have most your data living out there, in this giant pile of shared memory, more or less available for anyone to see. I think that, even before the birth of C, most academics recognized that as a source of liability; a lot of ink was spilled dancing around possible solutions to that problem in the mid-late 20th century and beyond. What Kay is saying in TFA seems, to me, to place his thinking clearly in the middle of that whole scene.
- galaxyLogic 8y ago
  The way I see it is that the FP school is about the microcosm like quantum mechanics, deciding what are the best possible building blocks of programs, the functions, which are pure and referentially transparent and immutable. OO is looking at the macro level: What are the systems how they communicate in a way that preserves the referential integrity of the system as it evolves over time. OO is like cosmology, structure of things on a large scale. FP = Quantum Mechanics OO = Relativity
  - kazinator 8y ago
    OOP is not very good on large scales; in fact, it shines at medium scales. Even programs of a few thousand lines of code can greatly benefit from OOP. We don't know what works at scales that are so large that they are described with cosmological words.
- dlwdlw 8y ago
  Is this the opposite of global state management paradigms like Redux? Using the global state requires a lot of contortion on each user's end (bureaucratic hoops) for the safety of the global state. It technically empowers every individual user with the whole state but the combination of not having to think about messaging and just brute force contorting into the global state creates terrible code IMO.

bunderbunder 8y ago

What Kay was getting at there is a bit difficult for me to follow, but I'm pretty sure that he meant something different than that. Something more specific and constrained. What you're describing sounds to me like a very LISP-y view of data. Alan Kay, by his own admission, wasn't very versed in the LISP tradition - based on what he's describing, at the time he was pretty deeply immersed in the more ALGOL-y side of the world, back in a time long before there was much cross-pollination between the two camps, and that would presumably have influenced his thinking. So, semi-wild conjecture: It seems to me like what he was really getting at is that he wanted to get rid of the heap. Or at least shove it deeply into "implementation detail" territory, the same way languages like Haskell try to banish any evidence of the existence of memory registers from the programmer's consciousness. In so many languages in the imperative tradition, the standard practice was to have most your data living out there, in this giant pile of shared memory, more or less available for anyone to see. I think that, even before the birth of C, most academics recognized that as a source of liability; a lot of ink was spilled dancing around possible solutions to that problem in the mid-late 20th century and beyond. What Kay is saying in TFA seems, to me, to place his thinking clearly in the middle of that whole scene.

galaxyLogic 8y ago
The way I see it is that the FP school is about the microcosm like quantum mechanics, deciding what are the best possible building blocks of programs, the functions, which are pure and referentially transparent and immutable. OO is looking at the macro level: What are the systems how they communicate in a way that preserves the referential integrity of the system as it evolves over time. OO is like cosmology, structure of things on a large scale. FP = Quantum Mechanics OO = Relativity
- kazinator 8y ago
  OOP is not very good on large scales; in fact, it shines at medium scales. Even programs of a few thousand lines of code can greatly benefit from OOP. We don't know what works at scales that are so large that they are described with cosmological words.
dlwdlw 8y ago
Is this the opposite of global state management paradigms like Redux? Using the global state requires a lot of contortion on each user's end (bureaucratic hoops) for the safety of the global state. It technically empowers every individual user with the whole state but the combination of not having to think about messaging and just brute force contorting into the global state creates terrible code IMO.