4 ms·

This post resonates with me. Without getting too hung up on the typesetter extinction, I think the general notion that the task of "coding" will change is almo

This post resonates with me. Without getting too hung up on the typesetter extinction, I think the general notion that the task of "coding" will change is almost a given. Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE. At a high level I agree with the general change vector the author proposes. I've been code doodling with some of these notions in my spare time for quite a while now. In particular, I think contexts: are nested and form a graph (not necessarily a tree) can exist in isolation outside of any other context (e.g. a double entendre) are some times shared (a conversation) transformations: *can* have conditional processing may not be deterministic (sometimes probabilistic feels better) I think other languages can (for all practical purposes) return lists I think some other key aspects are missing from the description, particularly: external (unresolved) references self references self replication On a few occasions I've almost written a similar blog post, but maybe this will spur that along. Many of these notions also seem to fit comfortably in LISP (from what I understand).

mechanical_fish 18y ago
Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE. That has nothing to do with changes in the task of coding. It has to do with changes in the relative popularity of various programming styles. As witnessed by this sentence of yours: Many of these notions also seem to fit comfortably in LISP That's probably true, but you're talking about a language which was invented in 1958 and implemented in the early 1960s. The Lisp hackers had the equivalent of IDEs and modern programming environments in the 1970s, if not before. They are not especially impressed by our modern programming tools. (And many of us actually prefer to do our programming using tools descended from theirs, like emacs.) Even the old Lisp hands who helped invent (e.g.) Java are not particularly impressed. As Guy Steele, co-author of the Java spec and former author of the Common Lisp spec, famously said of Java: "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." The outer surface of programming has changed a lot over the last fifty years, and Moore's Law, the buildout of our infrastructure, the increasing sophistication of computer users, and the general growth in the population of programmers has changed the nature of the problem space many times, but the essence of the task hasn't really changed all that much. You can learn surprisingly relevant things by reading papers and books from the 1960s.
- bsaunder 18y ago
  Oh, I'm right there with you on the IDE v editor issue (maybe vim though). My point is that the daily life of a (typical IDE) programmer in 2009 is very different than one of an emacs developer of the 60s/70s. I agree there has been a lot of useless reimplementation going on (make works just fine for me thanks). But on the whole I think we tend to think in higher level concepts (regardless of our editor choice). I've also noticed an increasing trend of migrating code to data (though I'm not sure the ones doing it realize this). In the LISP world they are one and the same (as I understand), in most modern programming languages, there's a pretty binary boundary between code and data that people are trying to work around all of the time by "evaling" code or introspection and various other meta-programming techniques. I believe it should be a continuous space. I think LISP supports this better than most languages. I agree there's definitely a back-to-the-future notion here. But I think the back swing is likely to have an alternate UI to it (in additional to the normal S-expression syntax for us die hard give-me-a-text-editor people).

mechanical_fish 18y ago

Even the early assembly coders of the 60s would be hard pressed to imagine the life of a modern coder working in an IDE. That has nothing to do with changes in the task of coding. It has to do with changes in the relative popularity of various programming styles. As witnessed by this sentence of yours: Many of these notions also seem to fit comfortably in LISP That's probably true, but you're talking about a language which was invented in 1958 and implemented in the early 1960s. The Lisp hackers had the equivalent of IDEs and modern programming environments in the 1970s, if not before. They are not especially impressed by our modern programming tools. (And many of us actually prefer to do our programming using tools descended from theirs, like emacs.) Even the old Lisp hands who helped invent (e.g.) Java are not particularly impressed. As Guy Steele, co-author of the Java spec and former author of the Common Lisp spec, famously said of Java: "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." The outer surface of programming has changed a lot over the last fifty years, and Moore's Law, the buildout of our infrastructure, the increasing sophistication of computer users, and the general growth in the population of programmers has changed the nature of the problem space many times, but the essence of the task hasn't really changed all that much. You can learn surprisingly relevant things by reading papers and books from the 1960s.

bsaunder 18y ago
Oh, I'm right there with you on the IDE v editor issue (maybe vim though). My point is that the daily life of a (typical IDE) programmer in 2009 is very different than one of an emacs developer of the 60s/70s. I agree there has been a lot of useless reimplementation going on (make works just fine for me thanks). But on the whole I think we tend to think in higher level concepts (regardless of our editor choice). I've also noticed an increasing trend of migrating code to data (though I'm not sure the ones doing it realize this). In the LISP world they are one and the same (as I understand), in most modern programming languages, there's a pretty binary boundary between code and data that people are trying to work around all of the time by "evaling" code or introspection and various other meta-programming techniques. I believe it should be a continuous space. I think LISP supports this better than most languages. I agree there's definitely a back-to-the-future notion here. But I think the back swing is likely to have an alternate UI to it (in additional to the normal S-expression syntax for us die hard give-me-a-text-editor people).