They may even come to the conclusion that programming is a
shallow activity and that what truly matters is an
understanding of domain knowledge
THE HORROR ;)
In all seriousness, IMO we'd have much better programs if developers spent more time thinking about domain knowledge and less time believing that "programming" in isolation is the important part.
I came here to comment on this. Its probably actually true :)
As a software engineer, I find HtDP awesome. As a teacher, I found it lacking. I think the best way to teach programming is in the context of a domain of interest to the student. Problem is, you can't write an universally usable book like that.
We need both. Not enough domain knowledge and you end up with software that isn’t a great fit for what it’s trying to do, but without enough computer science and software engineering knowledge and we end up with all of these stupidly memory-and-cpu-hungry applications that are all the rage these days.
Clearly. If people want code written by people with a lot of domain knowledge but not a lot of software engineering experience, look at the code written by electronic engineers who just need to write a little software (typically for microcontrollers) to interact with the hardware, the true focus of their craft.
Some of the most horrendous, fragile, unmaintainable spaghetti code I've seen in my life was written by electronic engineers. And some of them were true masters of their crafts, it's not like they lacked the cognitive abilities to write good code, it's just that they didn't care at all, it just had to accomplish the function they needed. Meanwhile I'd see them spending a lot of time making sure things were routed nicely and PCBs looked nice.
Domain knowledge vs. programming "in isolation" is a false dichotomy. Indeed, the programmer's business is to think about the domain in terms of computer science in the programming language of choice. It is sometimes a very complicated translation process, and the complexities do not necessarily come from the domain per se but often from requirements concerning the target platform, efficiency, precision, user interface, etc. At the end of the day, that is what turns out to be the "important part," and those who fail to realize that early in the process are usually bound to suffer some unpleasant consequences.
The "important part" is that the code solves the end user's problem while creating the minimum possible amount of new problems for them. Everything else is an implementation detail. Everything else that we hold so dear about computer science is only important insofar as it solves someone's problem.
"The amateur, then, is learning about his problem, and any learning about programming he does may be a nice frill or may be a nasty impediment to him. The professional, conversely, is learning about his profession—programming—and the problem being programmed is only one incidental step in his process of development.
"The other side of this observation is that the professional never quite takes any problem as seriously as does the amateur. He has had bugs before, and he will have them again. This difference in attitude is a source of constant friction between the two types: the professional is very tired and a bit irritated by the unending stream of amateurs waving their printouts in his face and condemning the machine, the operator, the system, the keypuncher, the language, or the government. The amateur, on the other hand, can see that the professional does not even care that his means and standard deviations are not going to be ready in time for inclusion in the proceedings of the conference."
Gerald M. Weinberg, The Psychology of Computer Programming.
It's an old and long tired adage that the "pure" knowledge, especially mathematics, is only "important insofar as it solves someone's problem." This is wrong on at least two accounts. First, the pure mathematics, for example, like art, is interesting, valuable, and perfectly happy to exist for its own reasons and does not need any permission from anyone to do so; second, it has not been a secret that the pure knowledge routinely turns out to be tremendously useful at some point - even if centuries later.
It's not just about solving the end user's problem, it's about anticipating future problems and features. If all code was write-and-forget you'd be right, but in general you have to maintain and upgrade codebases over a rather long timespan. That's where "implementation details" matter a whole lot.
A central principle in HtDP is how to represent information (the domain) as data in a systematic way. The whole point of it's approach, as I understand it, is in fact to teach a domain-neutral approach, where what dictates data and function structure is the information's structure.
I find that, as a rule, general programming proficiency and (worse still) language proficiency are given too much weight compared to domain knowledge, but it’s most definitely possible to overshoot and end up thinking those core skills are unimportant.
Yes, but I think that extends well beyond coding to include half or more of the UG CS curriculum. The rose of object-oriented groupthink is most pronounced among CS graduates, to the general detriment of the software dev world.
I learned the downside to domain ignorance early in my career when a engineering manager confided to me, “It's eadier to teach an engineer to code, than teach a computer scientist engineering.” The same applies to biology, medicine, chemistry, culture, and many other domains where mastery of context is difficult yet essential.
And I've found those turn out to be the most interesting software jobs.
In all seriousness, IMO we'd have much better programs if developers spent more time thinking about domain knowledge and less time believing that "programming" in isolation is the important part.