3 ms·
I've heard this said about every new generation of programming techniques. It's true about every technique for which tooling isn't yet widely available, right
by ken 8y ago
I've heard this said about every new generation of programming techniques. It's true about every technique for which tooling isn't yet widely available, right up until somebody writes the necessary tools.
You could replace the subject of your comment with, say, "automatic garbage collection", and it would have been equally true ("that's just what your job entails!"), right up until GC made its way into the first mainstream languages, and it very quickly became a tool used by almost everybody.
- pjc50 8y agoGC is a much older technique than it looks, though: it's described in McCarthy's 1959 Lisp paper. https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/mccarthy-recursive-functions.pdf https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/... We spent about 3 decades arguing back and forth about performance until the wave of bytecode+GC languages took over and accepted those tradeoffs: Perl, Python, Java, Javascript. Holdouts remain in the high performance, embedded, and deterministic areas of software.
- infinite8s 8y agoCode as live objects is almost as old (Lisp, Smalltalk)
- otabdeveloper2 8y agoThe point is that the idea of drawing diagrams instead of writing code (and/or integrating documentation text right into the source code) is a really old idea. The idea is older than structured programming, older than the C programming language, older than the idea of object-orientation. It's probably even older than McCarthy's LISP. Safe to say that if it hadn't caught on during this time, then it never will.