A lire sur: http://www.techrepublic.com/blog/programming-and-development/why-programmers-should-study-the-art-of-programming/4160
To the average programmer in the trenches, debating the theory of computation is like discussing the chemical properties of saltpeter
while in a gunfight: it may all be correct, but it doesn’t apply
directly to the problem in front of them. Why waste time imagining the
outcome of a deathmatch between Haskell Curry and Alan Kay
when we’ve got a deadline to slap a new web UI over our legacy
application? Why should we care whether we’re using a monad or an
exception to return an error state? What the heck does “orthogonal”
mean? Don’t give me a research paper, just give me code that works. And
so runs the “get it done yesterday” logic.
From many a project manager’s point of view, programmers who dabble in computing theory pose an even greater danger than wasting time: they threaten to poison the project with new ways of doing things. This attitude is not entirely unjustified. Every new idea that promises to revolutionize software development seems to do quite a bit of damage to the industry before the hype wears off and it finds its proper place within the programmer’s arsenal of available tools. Converts to these theories try to squeeze every problem into the new mold whether it fits or not. Just as an appalling misapplication of the Theory of Evolution provided a justification for Nazi genocide, so has the misapplication of Object Orientation, for example, led to all manner of programming ugliness in the name of purism (may Godwin have mercy on my soul).
The history of programming is dotted by false starts and pendulum swings. I remember in the wake of Dijkstra’s famous Go To Statement Considered Harmful, myriads of programmers created all sorts of grotesque code contortions in order to avoid using a GOTO, even where one was badly needed. The slavish obedience to this and other rules of Structured Programming became so detrimental that once when the objection “It isn’t structured” was raised to an idea before the ANSI subcomittee on which I served, I replied “I don’t believe in Structured Programming.” The silent shock on every face made me expect to be instantly removed from membership. I might have, too, if my friend and mentor Ken Lidster hadn’t spoken up and explained that what I meant was that I objected to a legalistic interpretation of Structured Programming principles. He was right, though at the time I felt that he had watered down my bold assertion.
Nevertheless, the pursuit of programming theory does do us some good. If it weren’t for all the brainpower that’s been applied towards improving the practice of software development, we’d all be punching machine instructions on paper tape or Visual Basic on Windows. Thank goodness someone said, “There has to be a better way!” Thank goodness someone keeps on saying it.
Programming language developers aren’t the only ones whose work improves under this consideration. Despite the risk of fanaticism, journeyman programmers can also enhance their contributions (and hopefully, their careers as well) by exercising their skills in areas that lie beyond their strictly defined responsibilities. Especially where it lies just beyond their horizon, the question “How can we improve software development as a discipline?” may yield a significant payoff. The danger lies in half-learning and poor self-evaluation. As Alexander Pope famously said in his Essay on Criticism:
Note: This post originally published on April 24, 2011.
Takeaway: Chip
Camden encourages programmers to cultivate a broad and deep
understanding of the trade by accumulating a knowledge of its history
and keeping an eye on recent developments.
From many a project manager’s point of view, programmers who dabble in computing theory pose an even greater danger than wasting time: they threaten to poison the project with new ways of doing things. This attitude is not entirely unjustified. Every new idea that promises to revolutionize software development seems to do quite a bit of damage to the industry before the hype wears off and it finds its proper place within the programmer’s arsenal of available tools. Converts to these theories try to squeeze every problem into the new mold whether it fits or not. Just as an appalling misapplication of the Theory of Evolution provided a justification for Nazi genocide, so has the misapplication of Object Orientation, for example, led to all manner of programming ugliness in the name of purism (may Godwin have mercy on my soul).
The history of programming is dotted by false starts and pendulum swings. I remember in the wake of Dijkstra’s famous Go To Statement Considered Harmful, myriads of programmers created all sorts of grotesque code contortions in order to avoid using a GOTO, even where one was badly needed. The slavish obedience to this and other rules of Structured Programming became so detrimental that once when the objection “It isn’t structured” was raised to an idea before the ANSI subcomittee on which I served, I replied “I don’t believe in Structured Programming.” The silent shock on every face made me expect to be instantly removed from membership. I might have, too, if my friend and mentor Ken Lidster hadn’t spoken up and explained that what I meant was that I objected to a legalistic interpretation of Structured Programming principles. He was right, though at the time I felt that he had watered down my bold assertion.
Nevertheless, the pursuit of programming theory does do us some good. If it weren’t for all the brainpower that’s been applied towards improving the practice of software development, we’d all be punching machine instructions on paper tape or Visual Basic on Windows. Thank goodness someone said, “There has to be a better way!” Thank goodness someone keeps on saying it.
Programming language developers aren’t the only ones whose work improves under this consideration. Despite the risk of fanaticism, journeyman programmers can also enhance their contributions (and hopefully, their careers as well) by exercising their skills in areas that lie beyond their strictly defined responsibilities. Especially where it lies just beyond their horizon, the question “How can we improve software development as a discipline?” may yield a significant payoff. The danger lies in half-learning and poor self-evaluation. As Alexander Pope famously said in his Essay on Criticism:
A little learning is a dangerous thing;The professional programmer should drink deeply. By cultivating a broad and deep understanding of our trade, accumulating a knowledge of its history, and keeping an eye on recent developments, he or she will develop the wisdom to distinguish hype from substance and to apply each tool to the purpose for which it is best suited.
Drink deep, or taste not the Pierian spring.
Note: This post originally published on April 24, 2011.
Aucun commentaire:
Enregistrer un commentaire