"Graphical programming environments are usable when they are useless, but unusable when they would be useful," said Jeffrey Snover, another Microsoft distinguished engineer and creator of Microsoft's PowerShell scripting tool for Windows. "When there are five things on the screen, you can burp that out [in text]. But when there are 500 things, [graphical programming] is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smokin' dope."
Managed code, such as Microsoft's .Net was not left out either:
Managed code runs inside a virtual machine. That makes it easier and faster to write, and more secure, say proponents. Managed code also lets developers "perform above their level of competence," Snover said.
"Managed code is like antilock brakes," he added. "You used to have to be a good driver on ice or you would die. Now you don't have to pump your brakes anymore."
You can see where this is going. The most insightful quote is what I'd like to focus on for this post:
Herb Sutter, lead designer of Microsoft's C++/CLI : "I think we have maybe five to 10 years left [with Moore's Law]," he said. "Optimizations will get very, very sexy again, when people realize how we pay for abstractions."
In what way do we pay for the abstractions provided by managed code and is it worth the price? Are abstractions good and how do we know when to use them?
When I start teaching people in my office about .Net many of them come from a Java or C++ background with some basic understanding of object oriented programming. Learning when to generalize something into a class or function is almost considered a black art.
Let's say you are writing a order processing system. There are Orders, Customers, and Items all needing to be tracked and processed in this application. This suggests a simple class structure, one for an order that has a customer and a collection of items. I haven't told you the kind of items that we are selling though. What if I told you it was a combination of commodity items, like light bulbs, and lot items, like diabetic test strips, where the number sold from each lot and to whom must be tracked. Now you have to decided to I try to cram all of that logic into a single Item class, or do I make an inherited class structure, perhaps Item as a parent with LotItem. The crucial reason I would decide on here is can one person understand what the class does if I stuff all the logic for both item types into it. In other words, is it maintainable? This is an example of "Rand's Razor" applied to the abstractions in programming.
The requirements of cognition determine the objective criteria of conceptualization. They can be summed up best in the form of an epistemological “razor”: concepts are not to be multiplied beyond necessity—the corollary of which is: nor are they to be integrated in disregard of necessity.
Applied to the class example, I don't want to generate classes beyond necessity or to have too few when I need more. In programming the requirements are maintainability, testing, performance, and others depending on the problem you are working on.
The problem of performance in higher abstraction languages are often more then offset by the power they give programmers to solve complex problems. I designed a inventory management system right out of college as one of my first large scale C# programming projects. I could not have done it in C++. Part of the reason is that the abstractions allowed me to focus on modeling the problem, which was very difficult in itself, rather then all the implementation details, memory management, persistance and communications plumbing needed to get all the pieces to talk together.
Every concept is formed for a reason. Every abstraction in programming should be as well. When those reasons don't match your problem, you must select less abstract tools, but this just means you will be creating your own abstractions specialized for your problem.
No comments:
Post a Comment