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.
