Java :-) Breakage does happen, but it's rare, though the incident rate can go up if you don't know what you're doing (some people routinely use APIs wrongly, read Internet recipes rather than the docs that come with the Java libs, and are caught flat-footed when internals change - I guess you don't have that problem because you know your system well enough to avoid this kind of pitfall).
I have never programmed in Java. I have watched others do so, and I interfaced some C++ code as a library to a Java app once. But I don’t live much in the typical commercial software world. I am a physicist (astrophysicist) and the closest I came to commercial software on / off were early versions of extended C compilers that I wrote, image analysis systems for MacDonald’s (!!?), and mostly the international war machine. My area has mostly been signal and image processing. I have never used a database in anger either, even though I have authored OODBMS systems. I wouldn’t really know how to wrap an app around a database, or even why you would do such a thing. That probably sounds really odd to anyone younger than about 40-50 years old. I have never written a web page. I don’t understand the fascination with HTML or XML or SGML or whatever you call it. Elaborated S-expressions that don’t seem to follow their own syntax rules.
I think Lisp-style macros are too powerful. You can get excellent results as long as everybody involved knows all the relevant macros and their semantics perfectly well, and for one-man teams like yourself this can work very well. If you need to work with average programmers, this fails. In such an environment, you need to be able to read other peoples' code, and if they can define macros, you don't really know anymore what's happening.
Too powerful for whom? Again, I’m lucky to be master of my own domain. I don’t have to share code with anyone. For me, the biggest errors come from incorrect algorithm choice, not coding, not typing, not library API incompatibilities. Coding I can do with my eyes closed, except for all the typos… but then even with eyes open those still happen. My very first year in computing, 1969, was the most frustrating year in my entire life. Everything I did was called wrong by the computer. Almost drove me to the point of tears. But then one day I woke up and I was one with the machine. Been that way for now, 47 years.
Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. There might be macros involved, there might be metaprogramming involved, or some kind of multiple dispatch with nonobvious defaulting rules, or a gazillion of other things that you have to be aware of. It's not a problem if you know your system from the inside out, but it doesn't scale well to tasks that need to be done by a team.
Isn’t that always the case, and always will be the case? Nobody can be certain how some library or application was written. You might have some pretty strong hints and hunches, but how can you be sure? Seems like the best bet is to treat everything as untrusted black boxes. Erlang probably offers the best security model against dependencies. If you look at any major element of code in production, it was probably written in a hurry under near unreasonable demands because hardware engineering overran their budgets and took some of yours, and the programmer may or may not have well understood his tools and language, or even if he did, he might have been daydreaming of being on the beach with his girlfriend instead of in this meat locker with the rest of you guys… My experience has been that hardware companies produce the most gawd-awful code you can imagine. Software shops vary… take M$ for instance - the bane of my existence. Looks like code gets pushed out the door and they rely on the audience to test it. Apple looks to me like a room full of really bright young minds, with no adult supervision. I guess if I could offer any advice to other younger programmers, it would be to push yourself to become a polyglot to expand your mental horizons of what is possible, and a historian to understand what went before you and why, so that you don’t keep repeating the same stupid mistakes we did. I could not be a production programmer. I’m definitely too much of a cowboy and a lone wolf. Teams are anathema to me. I need deep periods of isolation to think. People who manage to perform in production coding environments must have very different personalities from me. - DM