I'm sorry Erik, but you haven't understood very much of what I've been trying to say. Rather than defending you might want to be sure you understand. There are probably many reasons why good software developers can have wildly differing opinions about how to build software. I believe that one of the major factors is the context of our individual experience. Just as in the parable of the Blind Men and an Elephant, we humans have a tendency to claim absolute truth based upon our own limited, subjective experiences and ignore other people's limited, subjective experiences which may be equally valid. In today's software development world, it is not unusual for a software engineer or designer to spend months or even years touching only one small part of the elephant. So, it's terribly easy to start thinking of the elephant as only a snake or spear. Computing and software technologies are changing so fast that this narrow perspective does not serve us well and the hard-earned lessons of yesterday are too often forgotten and disappear from our common knowledge base - leading to an almost continuous cycle of reinventing the wheel.
"Cranking out code by the pound, is not my aspirations for the future. And this is not simply a frivolous concern. We humans are not mere machines: Push a button and we start going. No, our moods and enjoyment affects our ability to do good work. If you hate what you are doing, you likely aren't doing a very good job either."
Where in anything I've said do you get the idea that I am advocating "cranking out code by the pound"? I’m still building software because doing that well is still one hell of a lot of fun. Your focus on programming languages versus tools ignores the fact that languages are themselves only tools. For almost 50 years (longer than you have been alive) my focus has always been to implement the most useful software solutions to real human problems by the most effective, durable, and economical means I can. To accomplish that one first has to fully understand the problem, construct a mental model of the solution, test that mental model against the problem, iterate that model until it doesn't break, and then and only then design the software components with which to implement the model. Simplicity and elegance should guide that design and reliability, verifiability, and economy should inform decision making. The choice of a programming language can influence those factors, as will the choice of existing, tested code libraries. Ultimately, if it will cost more to build, test, and deploy the solution than the problem is worth to the funder, it is unlikely that the solution will be implemented.
Learning and understanding the mathematically verifiable software architectural models that apply to a problem space are critical tools for designing solutions. Knowing the right models to use, or synthesizing parts of existing models into new models, or understanding how to validate a new model are all skills of the serious professional (as opposed to the talented amateur). Coding is how one communicates a design to a computer.
There are no perfect software solutions. Everything in software is a compromise. Choosing the right compromises is a crucial skill. That is the essence of the material with which we work. If you care to understand what I'm driving at, you might find reading the following articles worthwhile:
