Great write-up. I like the perspective of a 30 year jump. In retrospect it feels like we are lobsters slowly boiling. When looked at from a distance, these o

Great write-up. I like the perspective of a 30 year jump. In retrospect it feels like we are lobsters slowly boiling. When looked at from a distance, these observations become much clearer. > It's time to be using all of those high-level languages that are so fun and expressive I think for most of us, programmer efficiency is more important than program efficiency. IMHO, in these cases, there's much to be gained from the scripting languages. For many programmers though, these seem to push some comfort zones too much. There are obviously some domains were performance is still king and the high-level languages won't cut it. > Highly optimizing compilers aren't worth the risk. For some they sure are. Probably would have been better stated with "not worth the cost" rather than risk. I don't see much risk here, more so cost (in the terms of effort and opportunity cost). I'd rather not worry about the details of bit twiddling on things if my current problem is plenty efficient on the small n's I'm dealing with. Compilation time can be a real cost as well. I have much faster code-test cycles in scripting environments. > Something is wrong if most programs don't run instantaneously. I think many people don't comprehend how true this is. Its truly mind boggling to consider how many instructions a second are run these days. What could your program possibly be doing with all of them in one second? Again, for some folks there are very good answers. For most of us, its loading and initializing layers upon layers of classes. I routinely see some stack traces dozens of lines deep. I'm sure each one is providing some useful abstraction of something, but.. really? We have a Java based application that was written without any external libraries, just straight up Java. It compiles down to a 120KB jar and provides significant real-time functionality with phone systems. Meanwhile some of our Java based web apps provide a 50MB war, but probably use every relevant Java library out there to help. > Design applications as small executables that communicate. Yes! I've gotten a lot of mileage out of this. Many would to well to read Eric Raymond's book: "The Art of Unix Programming". The only thing I'd like a better solution for is a nice mechanism to set-up and configure the deployment of said "small executables that communicate". I'd like programming to be as easy as building chain of commands in a Unix command line. Yet setting up a production environments with chains of commands seems a bit.. ugly. > Don't write temporary files to disk, ever. Once upon a time, those in the know would set-up RAM disks. These days with SSDs, it seems that's effectively what we are doing. Probably a negligible gain to use RAM over SSD. Only slight advantage of RAM over SSD I see is that things get cleaned up on a reboot (does anyone still reboot regularly?). > Everything is so complex that you need to isolate yourself from as many libraries and APIs as possible. I think this is behind the recent backlash against frameworks. Unfortunately, many raw languages still lack some basic utilities that make it just a bit painful to use without any libraries. Seems many people will be migrating towards unobtrusive libraries that add value in the places needed without requiring a cascading set of components and tight coupling with the application being coded. This is a good thing. > C still doesn't have a module system? I've got nothing here. In general, I've been migrating towards a more data driven approach rather than native code. I wish we'd start loading code modules the same way we would load a piece of data from a file or database. At the end of the day it's all the same. Obviously you need to be sure of the sources you are loading code from, but you should be protecting your data the same way. UPDATE: Minor editing for clarity. UPDATE2: And math.