Monday, November 05, 2007
discipline and punish
The real problem, I think, is that the timeless, traditional understanding of programming is pretty much completely backwards. Everybody is taught that programming is a kind of writing where the goal is to use a special "language" to tell a computer what to do. From the beginning we are led to believe in this idealistic notion that programming is just a matter of developing clearly defined solutions to clearly defined problems in the form of homework questions. But what if it's not? What if, in fact, the complete opposite were true and the real goal of programming is to tell a computer what not to do? Rather than seeing programming as a kind of creative endeavor in which the programmer is thought to express a "solution" what if the real goal of programming is to simplify problems so much that a computer can understand them. In practice these two models -- the "programmer as a solution creator" versus "the programmer as a problem simplifier" -- would not be that different. But occasionally which model is adopted will have major consequences on a project. (Ironically, solution creators tend to produce hopelessly overcomplicated problems while problem simplifiers tend to produce slightly less useful solutions.)
. . .Programming languages, compilers, reliable networking protocols, ACID, unit testing, modularization, encapsulation, loose coupling, and yes, abstractions, -- all these fancy tools and principles a programmer must rely on are hacks -- kludges, really -- needed to reduce the number of ways in which his program can fail catastrophically.
Links to this post:
Comments: Post a Comment