Absolute Power Corrupting Absolutely Considered Harmful

by Justin Hutchings

Aspect Oriented Programming is the idea that not everything fits neatly in the object oriented model. Within the programming language community, there has been a large amount of debate on whether AOP needs power or if it needs bounds. This article briefly compares the idea of programming language power to that of authoritarian governments: while authoritarian governments have less overhead and smaller transaction costs, the likelihood of error increases.

Since Dijkstra’s 1968 letter to the editor about the GOTO statement, opponents (Flon et al) and proponents have come out for or against a number of potentially dangerous programming statements. Similarly in the study of political science, the quest to balance transaction costs (efficiency or bureaucracy) against conformity costs (ease of implementation) has led to a number of failed governments.

Democracy suffers from high transaction costs as a result of a broad bureaucracy; however, the bureaucracy often results in more fully discussed and thought out laws that are truly a balance of concerns and in turn a very low conformity cost, since everyone is reasonably happy with the outcome. Fascist governments suffer the opposite symptoms and benefit tremendously from the extremely low transaction costs of having only a dictator to make decisions; on the other hand, they suffer from very high levels of discontent from poor decisions that cause a great deal of pain to many users. How can programming languages balance the potential fascism of low transaction costs and high conformity costs while still allowing a language to be powerful and efficient?

The Dangers

Low transaction cost commands like GOTO or concepts like direct pointer manipulation are perfect examples of the double-edged sword that too much power can cause. Compilers are incredibly easy to write for these types of operations, since they map directly to the corresponding functions in the assembler and machine code. Given this relationship it is possible to write far more efficient code. These gains in efficiency have a very high conformity cost, though.

High conformity cost in the realm of programming typically results in less testable, less readable, less maintainable code. We use higher level languages in modern Computer Science to avoid many of these issues. Still, in an effort to provide programmers as much power as they desire, some of these low level commands remain, cancelling out some gains of the higher level language.

In order to drive forward progress in programming, languages need to make hard decisions that will have a good impact on large scale projects. Excessively powerful low level commands that remain exposed in high level languages become more dangerous the larger programs get. As programmatic complexity increases, keeping pace with Moore’s law, debugging and maintaining software will only get harder if the languages do not evolve as well.

The Complications

When should harmful commands be removed from a language then? I argue that they should be first be removed in new languages or if a language is strictly evolutionary, only major milestones. If the “do while” construct was determined to be less readable than a simple “while” and therefore harmful, it should not be removed from C#’s next iteration, rather, it should be removed on C##, or whatever that becomes. While this may not be possible on some languages that do not evolve into new programming languages, it is an important consideration. Languages need a good deal of continuity between intermediate versions in order to encourage developers to explore the state-of-the-art language tools. Deprecation on an active language either breaks backward compatibility or confuses users. When PHP5 deprecated many of PHP4’s underscore delineated functions in favor of the Java-style naming conventions and new functions, it caused a lot of confusion, despite solid documentation. Still, it is important that these low-level commands move gradually out of the languages so that more robust, sophisticated commands can come in and provide far better quality.

In terms of the relationship between removing excessively dangerous language tools and aspect oriented programming, the two come from a very similar school of thought. While it is possible to do many things with the tools we have today, or even the tools we had years ago, proper software engineering is key to the ongoing success of these larger and larger software projects. With proper software engineering and aspect oriented programming, the degree of modularity and maintainability of software increases dramatically. In order to keep this progress going, though, it is important that languages support better tools for doing things that otherwise programmers would be doing in a non-maintainable, low level way.

Born: Jan 14 , 2007; Cleaned: June 28, 2008
©2004-2008 10stripe.com