Sounds like he is bemoaning the technical debt problem, writ large. While you can't resolve this from the gate level on up overnight, you can create your own "technical oases" that are largely free(er) of technical debt than the crud they float upon.
Ya that is a good way to sum it up, thanks for the brevity. I'm finding that even my thinking has been clouded with complexity, which leads to my large rambling posts. I'm trying to imagine a world where everything is more elegant from the ground up, which is perhaps possible now that we have hindsight, and then apply that to my own work.
I really disagree with a lot of his solutions, and I think his argument is muddled and unclear, and I hate the idea of moving toward languages like PHP that cover for programming errors (that often mask logical errors you want the compiler to check) but I see where he's coming from.
My complaint is that a lot of the measures he proposes (self-modifying code? seriously?) are going to make the problem a lot worse.
Across the industry as a whole, 80 to 90 percent of software engineer time is spent cleaning up crap (sometimes one's own, but this is at least educational) that wasn't done right in the first place and, yeah, it's frustrating. You need to have an unusual degree of autonomy (effectively your own boss or at least CTO) to be able to create such "oases".
Ya I'm beginning to feel out of the loop compared to my peers. But I've been down so deep in some things that I'm profoundly aware of how flawed they are. I need smarter tools and was looking to things like self modifying code as a way to help programmers explore problem spaces and then maybe we could freeze the solutions when they perform properly. I definitely agree that maintaining code is fully 90% of this job.
You obviously know a lot about computing, certainly more than I do on the whole, but I'd recommend leveling up on PL design.
Self-modifying assembly code, in the bad old days, was not uncommon (as a performance optimization). It is, however, utterly unmaintainable.
I would recommend the book Types and Programming Languages. Also, you should spend a year in a strongly and statically typed language. Start with Ocaml or Haskell because they are "purer", then move to Scala if you want. This will give you some ideas on what infrastructural choices make feasible the development of software that isn't complete garbage.
Good advice. Regardless of language, I tend to write a lot of code in a functional manner, which throws off my business partner because he writes macro-style code (where the code is ever-evolving and is practically a media file). So he's about 10 times as prolific and I have a hard time demonstrating why my approach might be better until years down the road. On that note I bought O'Reilly's "Erlang Programming" by Cesarini & Thompson, but haven't read much yet. I'm hoping to find a purer language that can give me some leverage to do what I want with concurrency in the near future. Thanks for the advice on which order to go with.
Oh sorry, basically treating code as any other media file. "Game Scripting Mastery" by Varanese and LaMothe goes into a lot of detail about creating your own language and compiling it to I-code and then running the scripts in the game, the same way you would load images or sounds. My partner writes very expressive code with creative macros (he independently discovered iterators by defining a macro like SPRITE to mean sprite[count]). That might seem a little strange to a computer scientist, but look at what he did. He didn't have to explain how references or lists or anything else worked. If you understand arrays and #defines, then you can use iterators too. And he does things like that to me all of the time, writing one liners to replace my pages of "proper" code. The only problem is that he does it in c++ instead of javascript/python/lua so our games are in this constantly evolving state, so my top priority is adding a scripting library to our engine. Then again, that introduces the need to bind all of these functions and data. It will probably be a win though because we tend to work on large games.
