Too Much Code

Start by embracing your limits

2010-11-27T09:05:00.000-08:00

Nothing in human history has offered more promise but has seen as many failures as software. We’ve all seen moments of greatness, where a program seems like magic -- but such gems are surrounded by minefields of bugs and indecipherable interfaces.

The result of all this is we programmers are often a frustrated bunch. But should we be? After all, what makes us think that as a species we should have the aptitude to create great software? Our skill sets evolved in an environment that favored those who could hunt boar and find berries -- any capacity to succeed in the abstract world of software is pure, accidental side effect. Perhaps we should be awed by software’s successes rather than frustrated by its failures.

The good news is we can improve despite our limitations, and it starts with this: accept that we generally have no innate ability to create great systems, and design our practices around that. It seems like every major step forward in software has followed this pattern of embracing our limitations. For instance, we move to iterative development since we can’t anticipate all variables of a project. We aggressively unit test because we realize we’re prone to error. Libraries derived from practical experience frequently replace those built by expert groups. The list goes on.

This type of admission is humbling, but it can also be liberating. Here’s an example: In years past I would spend hours agonizing over an internal design decision for a system I was building. I figured if I got it right we could easily bolt on some new feature. Sometimes I was right, but often times I was not. My code often was littered with unnecessary structure that only made things more complicated.

Contrast that to today: I know I can’t anticipate future needs in most cases, so I just apply this simple heuristic:

When in doubt, do the simplest thing possible to solve the problem at hand
Plan on refactoring later.

The first step frees us from trying to anticipate all future needs -- but this is not quick and dirty cowboy coding. An essential element of code is to create an understandable and maintainable system. Don't try to code for future needs. Instead, structure code for present needs so it can be leveraged in the future.

So how do we do this? A couple things to keep in mind:

When in doubt, leave it out. (also known as “You Ain’t Gonna Need It”)
Unit-Testable designs tend to be reusable designs. Unit tests not only catch bugs that can result from refactoring, but they encourage modularity to enable that refactoring.
Don’t try to design an API independently of an application. You won’t understand your users’ needs well enough to create a good experience. Build the API as part of the application to make sure its needs are met, then factor out and generalize.
Group code together that tends to change for similar reasons. If your Widget class is responsible for rendering its UI and writing to the database and business logic, you can’t use it anywhere else without significant changes. High cohesion and loose coupling.

There are no hard-and-fast rules to building software, but we all need a compass to help guide us through the thousands of micro-decisions we make every time we write code. Hopefully this post can help build that compass.

Can "Agile in the Large" Succeed?

2010-10-18T19:03:00.000-07:00

Agile Development isn’t perfect, but it got something right. Right enough, at least, to gain enough momentum to become a buzzword -- and for consultants to latch on by selling “Agile” to big enterprises. The result is “Agile in the Large”.

Agile in the Large ranges from the Half-Arsed Agile Manifesto to Cargo Cult practices. Too often we simply bolt on a few agile practices without understanding how they provide value. Adding scrums and iteration reviews to your current process and expecting improvement is like building a runway in your back yard and expecting planes to land.

Whether it’s labelled agile or not, a cohesive development team works for a couple reasons. It creates a focused team fully aligned to a common goal. It avoids “Us and Them” mentalities, enabling everyone to adapt to meet the goal. It offers a self-correcting strategy for the thousands of micro-decisions when building software: It must be testable, “You Ain’t Gonna Need It”, and it creates quick feedback to make sure you’re solving the actual problem.

Agile in the Large is flawed because it often fails to achieve these basic ingredients. Take Scrum of Scrums, for example. It tries to coordinate and resolve technical dependencies between teams by having representatives from each team get together and talk through them. It’s better than nothing, but an emerging system has too much ambiguity: the interaction between components is still being defined, bugs can lead to finger pointing, and the important sense of ownership is lost. Everyone feels like cogs in a machine rather than someone solving an important problem for a real user. Our ability to adapt the microdecisions that build great software is lost.

In fact, Agile in the Large seems doomed from the beginning. Once you’re beyond some number of people in a single project, it’s impossible to create that sense of shared ownership and adaptability. Great software is created by small, dedicated teams.

So, what then? It seems the only way out is to make Agile in the Large more like Agile in the Small. A team should be working on one and only one project, and include everything necessary for that project to be successful. How we do that depends on where we are in a project’s maturity curve.

New vs. mature systems
New development is the most easily handled. Look at the problems at hand, and make sure the team is equipped to handle them end-to-end. This new project may have several components, but now is not the time to split those components into their own teams; keep a single team aligned to the user’s goals. After all, if a component isn’t aligned to some user’s goal, what is its value? Organize around components too early, and team cohesion is lost.

So we are off to a good start, but we need to adjust our strategy as a successful project matures. You may find parts of your system has value for other uses. This seems timeless: C first was a successful tool for building Unix, Ruby on Rails was an application before it was a framework, Amazon was an online book store before it was a cloud platform, and so on. In all of these cases a successful system was built, and then groups arise around the reusable pieces. Reusable technology will naturally arise from a successful project. Embrace that, but don’t force it.

Open source as a model for reuse
Later in a system’s life we find ourselves consuming many assets from a variety of teams. Now it’s easy to let coordination and communication friction kill our focused project. Fortunately, the open source world gives us the answer.

Quite simply, needed enhancements to common assets should be written and contributed by consuming teams. This offers several advantages over logging an enhancement request. For instance, we reduce deadline haggling and misaligned schedules. We also reduce the need for frequent status updates and opportunities for miscommunication between teams.

Of course, not all changes to open source projects come in the form of patches. There should still be a team around the asset in question, responsible for its architecture and fundamental direction. That team also operates as a gatekeeper, ensuring all patches are properly unit tested, documented, and don’t threaten the integrity of the system.

Changes must be handled on a case-by-case basis, but the primary mode of operation should follow the agile ideal: a single team with responsibility for a project end-to-end. This includes contributing to assets it consumes.

What if even the initial project is too big?
I’ll touch on one final question: what if even the initial scope of a project is beyond what a single team can accomplish? Find a smaller initial scope, get it working, and grow from there. Do this even if the initial scope means building placeholders that are discarded in the final result. The time saved and friction eliminated by creating a single, focused team will outweigh this. Think of it as scaffolding that eventually gets removed.

In the end, Agile in the Large only works if we make it more like Agile in the Small. Hopefully this article is a step in that direction.

Beware of the Flying Car

2010-10-16T20:17:00.001-07:00

Every so often we developers are asked to build a flying car. Our users obviously need one to avoid traffic and get to meetings on time. So we set down the path to meet those needs.

The trouble is most of us have no idea how to build a flying car. Even so, this is the project so we better get started! Our first release of the flying car will be small, and carried around on a string. We show good progress to our user's needs and gain approval from our superiors. We will simply remove the string in a later release.

Hopefully most of us will recognize a Flying Car Project and take time to understand and address the users’ goals rather than sprinting toward a brick wall. The Flying Car is a means, not an end in itself -- and there are other, executable means to the desired end.

Of course, there will always be someone eager to go build that flying car. If that happens, try to steer them in the right direction. If all else fails, just don’t be standing underneath it when they cut the string.

And We're Back

2010-10-16T06:52:00.000-07:00

After an unbelievably long hiatus, I'm going to start blogging again. It's funny how becoming a parent makes everything else seem to go away for a while.

I don't expect I will ever post at a regular intervals here. I'll post when I feel like I can express something that gets closer to some truth about software -- at least to me. How often will that happen? Who knows?

The rebirth of this blog will come with a shift in material, at least for the near future. I've recently become more interested in the social aspect of building software. How should we organize ourselves to create great software? How should that change over time?

I am and always will be a programmer at heart. My shift in emphasis simply comes from the realization that our biggest challenges aren't technical. They're social.

The Guru Myth

2008-11-15T10:57:00.000-08:00

Anyone who has worked in software long enough has heard questions like this:

I'm getting exception XYZ. Do you know what the problem is?

The questioner didn't bother to include a stack trace, an error log, or any context leading to the problem. He or she seems to think you operate on a different plane, that solutions appear to you without analysis based on evidence. This person thinks you are a guru.

We expect such questions from those unfamiliar with software; to them systems can seem almost magical. What worries me is seeing this in the software community. Similar questions arise in program design, such as "I'm building inventory management. Should I use optimistic locking?" Ironically, the person asking the question is often better equipped to answer it than the question's recipient. The questioner presumably knows the context, knows the requirements, and can read about the advantages and disadvantages of different strategies. Yet this person expects an intelligent answer without supplying context. He or she expects magic.

It's time for the software industry to dispel this guru myth. "Gurus" are human; they apply logic and systematically analyze problems like the rest of us. Consider the best programmer you've ever met: At one point he or she knew less about software than you do now. If that person seems like a guru, it's because of years dedicated to learning and refining thought processes. A "guru" is simply a smart person with relentless curiosity.

Of course, there remains a huge variance in natural aptitude. Many hackers out there are smarter, more knowledgeable, and more productive than I may ever be. Even so, debunking the guru myth has a positive impact. For instance, when working with someone smarter than me I am sure to do the legwork, to provide enough context so that person can efficiently apply his or her skills. Removing the guru myth also means removing a perceived barrier to improvement. Instead of a barrier I see a continuum on which I can advance.

Finally, one of software's biggest obstacles is smart people who purposefully propagate the guru myth. This might be done out of ego, or as a strategy to increase one's value as perceived by a client or employer. Ironically this attitude makes a smart person less valuable, since they don't contribute to the growth of their peers. We don't need gurus. We need experts willing to develop other experts in their field. There is room for all of us.

Tearing Down the Software Factory

2008-03-09T09:58:00.000-07:00

Tom DeMarco said it well:

The idea of a software factory is a joke -- that we can build software by rote -- that's ridiculous. If the work is deterministic, we will do with it what we do with any other big piece of deterministic work. We'll let the computer do the deterministic portion, leaving the person who interacts with the computer -- the other half of the system -- to do the work whose roteness has decreased, not increased. Every time you automate something, what's left of the person's work is less deterministic, until eventually, when you automate enough, there's no deterministic element left for the person's work--no rote. ... Our work is not deterministic. It's far too inventive. We're knowledge workers, not factory workers.

Of course, similar thoughts have been articulated many times before, and was a theme of the previous post on this blog. The idea of a software factory contradicts our best understanding of the essence of software, yet industrial style command-and-control management of software continues. Why is this? One problem is we developers haven't effectively presented a convincing alternative. Remove command and control, and to some extent developers must manage themselves. From Watts Humphrey:

Since your manager’s performance depends on your performance, and since the performance of software groups has historically been so poor, managers do not trust software professionals to manage themselves. To overcome this problem, all we have to do is to convince management that we can manage ourselves and then perform that self management so well that management will continue to trust us.

The theme of trust and credibility runs throughout Humphrey's extensive writing on this topic. This is not new, but progress has been slow. The major obstacle is that managers rightly want concrete, objective data on which to base their decisions. This conflicts with the black box that software development so often becomes. We need better transparency. It is time to open up the black box of software engineering.

The black box of software
Opening the black box means programmers and managers must meet each other halfway. Managers must create and adapt to a new post-industrial management science, and programmers must produce data useful to that management science. This does not mean attempting to make programmers into assembly line workers. To the contrary, it means embracing the creative nature of software, and managing the output as a side effect of development.

How do we do this? Empirically manage everything that can be empirically managed, and complement it with the judgment of your best engineers. Many pieces of the puzzle already exist. Unit testing, code coverage reports, bug tracking, static code analysis, dependency management and others provide transparency into the state of a project. Such data is purely informational, but technically inclined managers can and should use it to ensure a project is on track. With context, problems like bloated dependencies, poor test coverage, or fixing related bugs many times are all signs of a project going astray. Modern software organizations must be able to detect and correct problems before they grow.

Unfortunately many managers today are not equipped to work with such data. This must change. Managers must build their skill sets for the post-industrial world.

Trust through transparency
Of course tools like code coverage and defect tracking only tell part of the story. Code is design, and no set of tools can define the quality or progress of design. Therefore we must complement these tools with the best judgment of our best engineers. But if managers don't trust the best engineers, this judgment is wasted.

So how do we solve this? Use transparency into software as a tool for building trust. Concrete data on the progress and quality of software gives managers greater confidence in engineers, even if the picture is incomplete. Trust begins to grow. Engineers should qualify empirical data and use it appropriately as a basis for design decisions. If we can provide managers a glimpse into software and prove we are making progress, they will be more willing to accept our opinions.

Some tension between managers and developers may be inevitable, but we can meet each other halfway. Our development practices should yield hard data for everything appropriate. In exchange managers must accept that code is design and trust the judgment of developers.

What we can learn from databases

2007-12-26T10:09:00.000-08:00

While not perfect, relational databases are among the most successful software ever used. Their behavior is easily understood even under high concurrency. Sets of changes can be composed with almost no effort, with strong guarantees of consistency. The question is: would this be true if we built our databases the same way we build applications?

Transactions and read consistency would be the first to go. Users must then cooperatively synchronize on some external monitor; any failure to do so can result in invalid data. Next, system state and logic become intermixed. Gone are simple ways to inspect the state of the system, or create a well-defined state space with known transitions. In short, if databases were written like applications, they become vulnerable to all of the bugs we see in applications.

Suppose we turn the question on its head, and ask what characteristics of the database we can apply to the rest of software? Consider the following advantages:

The system itself guarantees a consistent view of data under concurrency, eliminating many types of race conditions
State changes are composable; updates are committed atomically, ensuring the database is never in an invalid state.
The state space is understandable. Because updates are composed to an atomic state change, countless permutations of state are eliminated

The key is this: we can confidently inspect, reason about, and change the state space of a database. The complexity of large models is mitigated by allowing only for valid, composable transitions. Imagine if we had such guarantees when building software in general. We could understand the state of an application at any time, and ensure all changes are valid and consistent. Our system would be much more understandable and predictable.

In fact, much language research is focused on this area. Software Transactional Memory in languages like Haskell is the most visible. The question is how such progress will reach the mainstream. History suggests an evolutionary model. Languages that gain adoption tend to have a good deal in common with an established language, lowering the barrier to entry. Because of this, I have yet to see a language with the above characteristics that I think will achieve widespread adoption. Hopefully that will change.

Understandable systems today
A couple of recent posts point out the burden of large code bases. I agree, as suggested by the title of this blog, but it's easy to confuse a symptom with the problem itself. So I phrase it differently: Unmanageable complexity is the enemy. Code size is often what the enemy smells like.

Developers can better manage complexity even without guarantees similar to what a database offers. Code should have a clear, easily understood state space, preferably applying related changes atomically. Such systems are easier to reason about and change because developers need not concern themselves with side effects of unrelated code; they can focus on the problem at hand. For those who haven't explored this, I'm indirectly describing the functional style of programming. This is the great hope for pure functional programming: it may spread predictability and a simple model to all development.

The Design Crisis

2007-10-18T19:07:00.000-07:00

Imagine waking up tomorrow and learning the construction industry has made the breakthrough of the century. Millions of cheap, incredibly fast robots can now fabricate materials out of thin air, have a near-zero power cost, and can repair themselves. And it gets better: given an unambiguous blueprint for a construction project, the robots can build it without human intervention, all at negligible cost.

One can imagine the impact to the construction industry, but what would happen upstream? How would the behavior of architects and designers change if construction costs are negligible? Today, physical and computer models are built and rigorously tested before investing in construction. Would we bother if the construction was essentially free? If a design collapses, no big deal...just find out what went wrong and have our magical robots build another one. More implications follow. With models obsolete, unfinished designs evolve by repeatedly building and improving upon an approximation of the end goal. A casual observer may have trouble distinguishing an unfinished design from a finished product.

Our ability to predict time lines will fade away as well. Construction costs are more easily calculated than design costs -- we know the approximate cost to install a girder, and how many girders we need. As predictable tasks shrink toward zero, the less predictable design time grows to dominate the project. Results are produced more quickly than before, but reliable time lines slip away.

Of course, the pressures of a competitive economy still apply. With construction costs eliminated, a company that can quickly complete a design gains a market edge. Pressure on getting design done fast becomes the central push of engineering firms. Inevitably, someone not deeply familiar with the design will see an unvalidated version, see the market advantage of releasing early, and say "This looks good enough."

Some life-or-death projects will be more diligent, but in many cases consumers learn to suffer through the incomplete design. Companies can always send out our magic robots to "patch" the broken buildings and vehicles they sell. All of this points to an amazing, counter-intuitive conclusion: our sole premise was a dramatic reduction in construction costs, and the result is quality got worse.

The Design Crisis
It shouldn't surprise us the above story has played out in software. If we accept that code is design -- a creative process rather than a mechanical one -- the software crisis is explained. Now we have a design crisis: the demand for quality, validated designs far exceeds our capacity to create them. The pressure to use incomplete design is strong.

Fortunately, this model also gives us some clues on how we can get better. Physical simulations equate to automated testing; software design isn't complete until it is validated with a brutal battery of such tests. To make such tests more effective we are finding ways to rein in the huge state space of large systems. Improved languages and design practices give us hope. Most importantly, there is one inescapable fact. Great designs are produced by great designers dedicating themselves to the mastery of their craft. Code is no different.

von Neumann's Long Farewell

2007-06-30T11:41:00.000-07:00

A big step in solving the software crisis is to accept that programming is not about computers. Yes, it used to be, and still is for brave souls working on operating systems or compilers. But in the long list of the world's software struggles, compilers rank pretty low.

It's easy to think programming is about computers because that's where we see problems. Of course, these are only symptoms of human error. Developers are constantly stretching to express behavior in terms friendly to a computer, making life harder so we can be easier on our machines. Such problems have been pointed out decades ago by the likes of Dijkstra, Backus [pdf], and Abelson and Sussman. Surely there is a way to describe our systems better than the terms of the von Neumann architecture.

For years we were limited by the capabilities of the machines, but this limitation has vanished for most of us. We've entered a new era, where improving the way we build software is as much a social problem as a technical one. Fortunately, there are signs of a growing social bedrock that could finally help us.

The Thirst for Abstraction
For a long time I didn't understand Guy Steele's comments on how Java can pull C++ developers about halfway to Lisp. Surely that fraction must be off; writing code in Java certainly feels a lot closer to C++ than Lisp. But independent of the Java language, the platform did a major service for the industry: it proved to the masses that we no longer need to express our designs directly in terms of the von Neumann architecture.

The abstraction offered by Java-like languages is small but significant. The conventional wisdom in software has long held that code must be expressed in terms of the machine to achieve passable performance. This myth is gone. Nearly every major software company is adopting some form of garbage collected, virtual machine-based language. We rely on the platform to map our higher-level expressions to efficient machine code.

This is a big step because accepting this level of abstraction opens the door to others. Why should we explicitly state data type information, when it can be inferred at compile or run time? Why not abandon primitives and arrays for objects and lists, since our platforms can now optimize away unneeded allocation? Why struggle with keeping track of many small state changes when major operations could change state atomically? Such abstractions make life easier for us, and previous successes suggest it will work. The result is a self-perpetuating thirst for abstraction. Expressing designs so humans can easily reason about and manipulate them is addicting.

von Neumann's Long Farewell
For many of us the shift away from the von Neumann architecture is painfully slow. Unfortunately the best ideas are often slow to be adopted. People are used to the way they've worked before, or averse to risk. So our transition toward better software is incremental -- but it is happening. Mainstream languages are offering higher-level concepts in their latest revisions. Adding concepts like closures, type inference, and applicative libraries does the software industry a service. It moves us toward a better way to write code. Hopefully some day we'll realize the low-level complexity we've dealt with isn't really necessary and abandon it altogether.

Why are we so polarized about Java?

2007-06-03T09:33:00.000-07:00

It seems impossible to constructively praise or criticize Java without eliciting strong reactions. It comes from both sides; some seem to love to hate Java, and parts of the Java community become defensive as a reaction.

For example, Paul Buchheit recently posted some insights into API design, referring to poor examples that happen to be written in Java. He immediately states he doesn't hate Java. The post is about APIs, not the language. Even so, he still had to update his post saying "It's not about Java, really", presumably because of some polarized reactions. This is unfortunate because it distracts us from Paul's excellent commentary.

I suspect the polarization starts from a trap I have fallen into myself. Like many involved in language discussions, I use Java professionally and other languages at night, so I run into examples analogous to the one described by Paul Buchheit. I sometimes get frustrated with poor APIs, and also with the Java language -- either directly or by association with poor APIs. I wonder, couldn't it use powerful constructs I use in other languages, or could the APIs just plain be simpler?

The problem is my frustration may linger when I discuss programming languages, and (knowingly or unknowingly) be reflected in my tone when discussing Java. The resulting post is more acidic, and less level handed than I would like. Those who disagree with my arguments are likely to pick up on that tone and may respond in kind. Before long we've spiraled into isolated camps, and meaningful discussion is hard to achieve. My last post had signs of this.

So, where did I go wrong? When discussing constructive criticism of Java and its APIs, we need to view Java with some perspective. We need to remember its history. So my first point is:

We are critical of Java in a context different from the one in which it was designed.

A key goal for Java was to replace C++, and this goal led to design decisions that are often targets for criticism today. In 1996 it wasn't clear we could create a sufficiently fast language without primitive types and arrays. It wasn't clear how much boilerplate code would be required by anonymous callback classes or checked exceptions. It wasn't clear that since the new syntax exactly specifies implementation, factory patterns would proliferate, and so on. So my second point:

Criticisms of Java should not imply any negatives about the designers of Java. Critics of Java are likely working in a problem space that differs from Java's original design goals, or incorporating new knowledge from the past decade.

There are certainly some that disagreed with the above decisions in 1996, but it was surely more debatable then, and different decisions may have slowed Java's proliferation -- which was opposed to its original design goals.

The key is we need to keep this background in mind whenever discussing Java. We can criticize Java and its APIs without insulting anyone. When being critical of Java, any frustrations should be tempered by knowing the landscape has changed. Similarly, apologists should recognize that criticism need not be viewed as an attack; it might be an attempt to make things better.

Why Java lost its mojo, and what Sun is doing about it

2007-05-30T21:44:00.000-07:00

It's old news to some, and hotly debated by others, but Java has lost its mojo. The Java community still has growth from large companies, but it hasn't been the darling language of hackers for a while (if it ever was). But don't think Sun isn't doing anything about it.

Java's popularity is a function of market position, the perception of one product compared to its competitors. When it first came out, Java was positioned against C++, to which it compares favorably. Yes, I miss operator overloading and a handful of other items, but these are outweighed by the fact that Java prevents entire classes of errors made by C++ developers. All of this was done before, but Sun was able to make it mainstream and practicable.

Now the Java vs. C++ battle is effectively over. Today Java's market position is measured against a variety of languages, most frequently C#, Python, and Ruby. For many of us, Java compares much less favorably to these than to C++. Proponents of these languages love to show problems solved in a handful of lines, with a Java-based solution including dozens of lines of boilerplate code. The poor Java developer is then pushed around and has his lunch money stolen.

Naturally, much of the Java community wants to do something about this. So closures and type inference have been proposed for Java 7, and the debate in the Java community begins. Some say "Hooray, Python programmers will stop making fun of me!" Others object "Don't we already have enough constructs to worry about in this language?" Throw in the glacier-like JCP, and we have no idea what the next release of Java will look like.

Can we fix Java?
I am sympathetic to both arguments. The language is getting big. If only we could get rid of artifacts like primitive types and arrays, we could remove clutter and make conceptual room for more advanced concepts. Even so, I still land firmly in the pro-closure camp. This is partially for selfish reasons; I got hooked on them while hacking in functional languages at night, and want to use them in my day job. My company uses Java because it is actually the right choice for us. No other platform offers that combination of portability, reliability, tooling, and performance. Too bad it's not with a better language.

With this in mind, the rumblings of the last few years make sense, and the future is clear. It's not about Java at all, it's about the JVM. And Sun is positioning the JVM to become a light, efficient virtual machine available everywhere. Consider everything that has happened:

JavaFX has been announced, creating a simple, declarative model to compete with the likes of Flex.
Sun has committed to releasing an update to Java 6 that will shrink the minimal JRE download to two megabytes.
Sun hired Charles Nutter to make JRuby a first-class language for the JVM. The 1.0 release nears.
Glassifish -- the open-source application server sponsored by Sun -- will run JRuby applications directly in v3, and be pluggable for new hosts. Java SE and EE need never enter the picture.
The JVM is now available under the GPL, which should increase availability on Linux.
The 2007 JavaOne conference included a Scala session for the first time

What does this tell us? The JRE is becoming the new POSIX. And the Java language is becoming less and less relevant. (Can't find where I first saw this idea posted...please send link if you have it.)

But what about the mean time?
The reality is Java-the-language will be around for some time to come, at least until a clear successor is established. Sun and other members of the JCP have an opportunity to define the language's legacy. As Guy Steele famously said, Java "managed to drag a lot of them [C++ programmers] about halfway to Lisp." Now Java can drag programmers one step closer to Lisp, and set the stage for the next generation of languages.

Of course, I'm referring to closures. Users of functional languages will attest how working with such constructs changes how you think. By adding closures to Java, we do more than provide a powerful tool for those of us already familiar with the construct. We introduce a large community to a better way of solving many problems. We'll see if it sticks, but I can't think of a better way to spread a thought model many believe to be superior.

Update: I actually don't think Java sucks. It meets the early goal as a straightforward replacement for C++ very well. I do believe we can create a language that is better than Java based on what we've learned over the last decade.

The Imaginary Concurrency Debate

2007-04-08T13:57:00.000-07:00

It's finally being accepted: the shared memory, critical region model for concurrent programming is broken. Even good programmers slip up and introduce race conditions, and bad programmers don't even understand the semantics. (You mean I have to lock an object just to read its values?)

The question is: how do we fix it? Two proposals have drawn attention: The Actor/Message model and Software-Transactional Memory (STM). The former eliminates shared state entirely, using messaging primitives for communication between threads, which may or may not be in the same process or physical machine. The latter preserves shared memory, but each thread has a consistent view of shared state during an operation and makes updates atomically, much like a database transaction. We'll refer to these as the Erlang model and the Haskell model (pdf), respectively, referring to the programming languages that most visibly use these synchronization techniques.

A debate between these models has quietly arisen. Proponents of the shared-nothing model point out the scalability and simplicity of Erlang. Proponents of STM point out the composability of guaranteeing updates to two components can be made atomically. Incredibly, it seems like this entire debate is ill-formed, and can be resolved with some simple generalization.

First we realize nearly all non-trivial applications use both a form of messaging and shared resources. A simple web application accepts messages from clients and shares state in a database. Therefore, any widely used programming environment must offer first-class support for transacted resources and messaging.

Now, suppose we view transacted memory simply as a hidden optimization of a transacted resource. In Erlang I can send messages to an Erlang process in the same physical address space or on a different machine -- the former is simply a runtime optimization and not the concern of the developer. STM is just a local optimization of a transacted resource; with abstraction we can also host the resource remotely like a database or distributed cache.

In fact, the Erlang and Haskell models are closer than they first appear. The STM proposal for Haskell has almost nothing to suggest a TVar must be locally hosted. There are Erlang libraries allowing use of an RDBMS. Both of these could be implementations of a general "transacted resource" API or Monad. Similar parallels can be made for the messaging model. Of course the languages have other significant differences, but these concepts are not so far apart.

So where does this leave us in the concurrency debate? I think we can draw some conclusions:

Today's concurrency primitives can be abandoned, replaced by messaging and transacted resources
Messaging and shared resources are complementary constructs used in most applications
Shared memory is to transacted resources what in-process messaging is to general messaging: a hidden optimization
Applications should use messages, transactions, or an appropriate combination depending on their needs

Now we need to ask why no widespread language has yet to replace critical region primitives with messaging and transacted memory. I think this is largely because such languages are hard to design. Notice how I'm generalizing STM and transacted databases to the same concept, but they have very different usage patterns in practice. It will be a challenge to design something this general yet simple enough so people will actually want to use it. But I'm an optimist.

One final note: both of these models are more easily implemented using a functional programming style. Something as simple as immutable objects makes both local messaging and transactions much simpler and more efficient. It's funny how good practices pay off in ways we don't expect.

Imperfect Approximation of Perfect Code

2007-02-26T21:40:00.000-08:00

It needs to be said: the quality of a programming language is not inversely proportional to the number of bytes needed for a Sudoku solver. Not that there's anything wrong with comparing Sudoku solvers; they can contrast certain aspects of languages, and differing solution styles can help readers think differently about code. But this only gets us so far.

The problem is the public language debate rarely ranges to topics that span more than a couple dozen lines of code. Anything bigger is difficult to manage in a single discussion. Therefore we need a model to debate the higher-order concerns of programming languages. Fortunately, I'm shameless, and will shamelessly steal such a model from Donald Norman's excellent Design of Everyday Things.

The idea I'm referring to is Norman's modeling of human interaction with software and physical tools as a series of imperfect approximations to approach a perfect goal. A system should assume all user input is imperfect, but guide the user to her goal. A user should have feedback indicating progress toward the goal. Mistakes should be easily reversible and never take her far astray.

Let's apply this to programming languages and practices. The biggest step forward in recent years has been the adoption of test-driven development. This fits nicely -- a solid safety net of unit tests allows developers to move towards the perfect goal. It also brings to mind a humorous recent post by Jt Gleason. One of the reasons programming is harder than bridge building is even small defects can cause us to jump radically away from our goal.

So, what can improved languages and practices do to help? They can guarantee no programmer mistake will cause us to jump to across an ocean, to use Gleason's metaphor. Programming will never be truly analogous to bridge building, but if bugs can be localized -- like how a bad bolt is localized for a bridge -- we might make progress. We can't eliminate bugs, but we can bound them and trend towards perfection. This reminds me of a Piet Hein poem reportedly displayed in Donald Knuth's home:

The road to wisdom? Well, it's plain
And simple to express:
Err
and err
and err again
but less
and less
and less.

With all this in mind, I recently saw something that just might be a glimpse of the future. Giles Bowkett posted a screencast showing modification of code in a Seaside-based web application as it was running. Sure, we've been able to hot-swap code for a while, but that's usually a painful process requiring specific launch configuration and use of an external debugger. Imagine if every menu in every program had an "edit" button available to experts, allowing them to adjust code on the fly. The code-build-test-debug loop would become instantaneous, applications could be grown in the context of existing pieces, and good design and languages can prevent local bugs from creeping elsewhere. This is our series of approximations toward a perfect goal.

Of course, the above ideal might be unachievable for many applications. Even so, it still might be possible to build an imperfect approximation.

Part 4: The Killer App

2007-02-11T09:57:00.000-08:00

Technologies get adopted when there is a compelling reason. People bought PCs for the killer app; game consoles sold for the killer game. Programming languages take off because they have a killer feature. Philip Wadler pointed this out nine years ago:

Instead, experience shows that users will be drawn to a language if it lets them conveniently do something that otherwise is difficult to achieve. Like other new technologies, functional languages must seek their killer app.

Java was adopted largely because it was easy for C++ developers to pick up, and offered killer features like cross-platform development and garbage collection. So what is the killer feature of the next language? I'll take a shot: the complete and final eradication of undefined behavior.

No Behavior Left Undefined
"Undefined behavior" is the biggest euphemism in software engineering. It even beats out "non-trivial problem". It's why your code works great on your laptop, but every one of your users runs a DeathStation 9000. Amazingly, most mainstream languages still have areas where behavior is undefined and unpredictable.

Fortunately, modern languages have made great strides as compared to, say, C++. However, we still have a long way to go. The big problem these days is race conditions caused by improperly synchronized code. And it looks like concurrent programming will only become more common.

What makes undefined behavior particularly evil is not that it might fail; it's that it might succeed. We want incorrect code to consistently fail. This way every time we find a bug we can isolate it with a unit test and ensure it never happens again. But undefined behavior shoots a hole in this: we can have incorrect code that passes every possible unit test. The result is bugs showing up in the worst possible place, production.

Consider the practical implications of working in a language without undefined behavior. If we can create a reliable unit test for any bug we find, we can guarantee that bug never recurs. Good development practices can cause defect counts to trend towards zero. It also makes development itself easier by strengthening our firewall against complexity. Although we'll never eliminate buggy code, hopefully we can create enough stability to prevent bugs from spiraling out of control, which has led to the death of many projects.

Where is our new language?
The first three posts and this one describe an ideal for a new programming language. Many details were intentionally left out to focus on the essence, so many language styles might work. Now I have a question for you: what current or upcoming language best meets these ideals? Much of this exists in part in Haskell, Erlang, Ruby, Scala, F# or others, but I know of no language meeting them all. I hope that will change soon.

Thanks to everyone who made it through these posts. I do want to hear your thoughts.

Part 3: Building a Firewall Against Complexity

2007-02-08T17:59:00.000-08:00

In the first two posts in this sequence, I argued a few key points:

A language must be usable by mediocre developers to achieve widespread use.
A language that prevents quick and dirty application development will not be widely adopted.
Widespread adoption is important so good programmers can use better languages in their day jobs.
Haskell shows important innovation in language design, but has major hurdles to widespread adoption.

Assuming the above, we have a big problem: how do we make the essential innovation in Haskell available to the broader industry? We need to first define the essence of Haskell's contribution, and then look for ways to package that essence for widespread use.

I will use a simple model of software problems to define Haskell's essential contribution. Complexity kills, but Haskell helps contain it. We were in trouble the moment systems got too big for a single human to understand, and we kept digging the hole deeper. This needs to stop.

So far the best answer to complexity has been good design abstraction. And there have been successes -- I usually don't think about the virtual memory system when writing code, for instance. But as Joel Spolsky pointed out, "All non-trivial abstractions, to some degree, are leaky." I don't usually think about virtual memory, but if I have locality of reference problems and huge numbers of page faults, the abstraction leaks. Suddenly I have to think about everything my program does, everything its libraries do, all existing abstraction leaks, and the virtual memory system. Soon there isn't room in my limited mind to keep track of everything. The result is almost inevitable: a system gets more complex, details are missed, and defects creep in.

To make matters worse, the difficulty of understanding a system grows exponentially with size. Every variable added must be tracked with every other variable. I see two possible solutions to this:

Stop building such complex software.
Find ways to build airtight firewalls around complexity. Stop the leaks.

History suggests option one is not likely. Great programmers can solve complex problems with simple code, but this is not the broader trend. Even if it was, this answer is unsatisfying; it's really just avoiding the problem.

The second solution might have potential. Imagine if we had abstractions that didn't leak, even if they could only be used in special conditions, or applied to certain problems. There will always be complexity, but by bounding it with airtight abstractions we limit the number of variables involved. Heck, if we do a great job, it's possible even we humans will be able to understand the systems we build.

This is where we reach the essential contribution of Haskell (or any pure functional language): it builds a firewall around the rest of the system's complexity. You only have to think about the part you're working, and you can make that small enough to be understandable. Because functions can't have side effects, you don't have to worry about locking a resource or dealing with inconsistent state. Your universe is defined by a function's arguments.

So far, so good...but we still need to package our firewall against complexity to be more easily adopted and used. Notice large parts of functional languages are not included in the essential contribution. For instance, a chunk of code could be written in any style, as long as its side effects are encapsulated. Here we break away from the pure functional model. If local destructive updates, statements, for loops, or other imperative constructs make coding easier, we can allow them. The key is not allowing these local decisions escape; our firewall against complexity must hold. A similar point came up in a recent discussion on Channel 9. Erik Meijer described it as "local impurity, but global purity".

This is a key element for our hypothetical new language: allow developers to code in their style of choice, provided it does not compromise the system's guarantees. The merits of different styles are open to debate, but surely no one style is the best for all programs. Ultimately, our hypothetical language might really be a set of languages, all keeping the same guarantee of isolation. The key is we can build a language with stronger guarantees than any commonly used language, but make it easy for most developers to adopt.

Can we live without state?
System state is the biggest source of complexity for imperative programs. It's also the biggest reason imperative code is considered easier for quick and dirty solutions. You want to change state? Go for it. Just be sure you synchronize with other threads, and your state change is consistent with the rest of the system, and you leave the system in a consistent state in case of error, and...well, hope others changing the state follow the same rules.

All of these problems go away with functional languages. But I can't shake the idea that a language restricting all access to state simply won't get adopted. Haskell elegantly solves this solution with the Monad; you write code in isolation, and simply describe the side effects to be evaluated as needed. Sounds good, until you run into problems like the one described here. In that case, the developer discovered a deep function needed some additional piece of information, and had to refactor large amounts of code to get it there. This drawback may well be justified by the advantages of isolated coding. Then again, our goal is to get a better language adopted, and most businesses will reject one that makes writing quick and dirty code harder, even if there is a net gain.

I really hope I'm wrong about this one. (And I'm sure many will try to convince me that I am.) I suspect, though, that languages must make accessing state information easy to gain widespread adoption. Is there a way we can do this while holding on to our firewall against complexity? Maybe. There are some tempting ideas that might solve this. Possibilities include Software Transactional Memory (STM), or messaging-based models like Erlang. The answer to which is better must come from experimentation, although STM elegantly solves some problems others do not, as Tim Sweeny described (pdf). Assuming an adopted system must be able to easily change state, we can still use STM to attain many advantages of the functional style:

No race conditions or deadlock. STM can make code seem like it's running in a single-threaded environment. This is our firewall against concurrency complexity.
No inconsistent state. If any error occurs, the transaction is simply rolled back. As a result, the state space of the system is dramatically reduced, and all possible states are logically consistent.
External side effects (like database updates) should happen in the same transaction as memory updates, again ensuring consistent state.

A new language could allow only special annotated functions to use STM, clearly indicating which functions are logically pure. This is analogous to implicitly passing a Haskell Monad to every pertinent function. Yes, we are sacrificing functional purity. However, we keep our firewall, and build a language that just might find a widespread audience. Also, we need not sacrifice other great features of functional languages to get there. For instance, a function may do destructive updates internally but always return an immutable object, lending itself to memoization.

In summary, we have two new requirements for our hypothetical language:

Developers should be able to choose their style of programming, but still have strong guarantees of isolation from the rest of the system.

The system should limit the number of variables the developer must track while writing code.

In my next post, I will add more requirements in this spirit, and hopefully draw these thoughts to a close.

Part 2: Languages and the Lesser-Skilled Developer

2007-02-05T17:28:00.000-08:00

My last post ended with an assertion: we need a language with the best of Haskell in a more accessible form. This leads to an old debate. After all, building good software requires tremendous skill. How can we make progress if we tailor it to the weakest practitioners? Bjarne Stroustrup made this point well:

The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.

Stroupstrup is right, of course. Too many developers are undereducated; we should demand greater skill. However, this doesn't change the fact that language adoption for a given shop has as much to do with politics as technical merit. Businesses have a perceived need to hire armies of developers to quickly write bad code and bad software. We'll be asking "WTF?" for a long time to come.

The problem is highly skilled developers are often forced to use the languages accessible to their less competent colleagues. Browse the forums at Reddit and you'll find lots of developers coding C# or Java by day and Haskell or Lisp by night. In short, a language must be usable by lesser-skilled developers so high-skilled developers have more opportunities to use it. Ruby is a great example of this in action -- building a quick and dirty web application is trivial, but the language still offers powerful constructs such as closures.

Battling the Hack
Anyone who has written software for a couple years has come across the Nasty Hack -- what should have been a simple piece of code made horribly complex, requiring an alignment of planets to work. Languages such as Haskell have the laudable goal of preventing nasty hacks by restricting what can be done in a given context. Sadly, good design often takes second place to deadlines -- and a language that has the appearance of slowing development won't get far, even if it offers a net gain.

Even a language that prevents some classes of nasty hacks will allow others. No language will free us from bad code altogether. Even worse, languages that free us from large classes of bad code have trouble getting adopted because businesses indirectly want to hack. This has depressing implications: the nasty hack is here to stay, and languages attempting to eliminate it will struggle to find widespread adoption. Our only hope is a fundamental cultural change in the way most organizations build software.

There is nothing I want to see more than this cultural shift. Maybe some day the market will get so sick of bad software it will force change. Consumers might realize great software is possible, as shown by a few innovative companies. Other companies might finally delay entry to a market, knowing a buggy solution will be rejected. The lesser-skilled developer might be forced to improve or leave the field.

However, while attempting to change the culture we still need to innovate under the current constraints. This means it must be easy to write quick and dirty code in a widely adopted language. So I submit a requirement for our new language:

A language should encourage good code -- but make quick and dirty code possible.

Today languages like Ruby and Python are probably the closest to the mark. Inexperienced developers can quickly get code working, and more advanced developers have access to powerful features drawn from the functional world. However, both of these languages have shortcomings when compared to Haskell. Incorrect code can lead to unpredictable behavior, and poorly designed code can lead to a state space too big for any human to understand. Specifically, they do not offer a tractable solution to concurrency and composability (pdf).

In my next post I will attempt to outline a language concept drawing from the best of Ruby, Haskell, and other sources.

(Edit: fix typo)

Part 1: Programming and the Metaphorical Mind

2007-02-03T13:03:00.000-08:00

Hello, World
This is the first of a set of posts on what we need from a new programming language. Everything I discuss exists in some language -- at least in part -- but no language yet has them all. This content is a mixture of my experience and many borrowed ideas, which I will do my best to cite. My goal is to represent the language needs of some segment of developers.

The Metaphorical Mind
I'll start simply: a language must be designed and taught with its users in mind. There is a psychology to programming which may explain why some languages get adopted and better ones don't. To model this psychology, I borrow the idea of the "Metaphorical Mind", as described in Steven Pinker's excellent How the Mind Works. In Pinker's words, "The human mind, we see, is not equipped with an evolutionarily frivolous faculty for doing Western science, mathematics, chess, or other diversions." Our minds evolved to work with the physical world, and we reason with abstract ideas using physical metaphors. Pinker cites Ray Jackendoff for examples:

The messenger went from Paris to Istanbul.
The inheritance finally went to Fred.
The light went from green to red.
The meeting went from 3:00 to 4:00.

(emphasis in original)

The first sentence shows physical movement; the others use the same terms but have nothing moving. Beyond movement, spatial metaphors permeate our thoughts and language. "The meeting is at 3:00", for instance. In fact, it's hard to describe almost anything without physical metaphors.

Many examples exist in software. Imperative programmers deal with pointers, objects, stacks, messages, events and so on. Our secondary storage uses folders, files and paths.

In fact, there is an alarming predictability on language adoption: languages that strengthen the physical metaphor -- or at least solve problems without weakening it -- have found widespread use. Languages with weaker physical metaphors remain with a small base. Compare the adoption rates of object-oriented languages to their functional counterparts.

This might be an indictment of functional languages, since they are typical expressed in abstract mathematics rather than physical analogs. That is unfair. Functional languages can be built and explained in straightforward physical terms -- they just aren't. Take, for instance, Haskell's Monad. I've written only small programs in Haskell, but for my purposes it's much easier to think of a Monad as a "to-do list". (Some use the term "action". I know it's an over-simplification, but that's the point.) The bulk of the language is a means to construct to-do lists in isolation. Put in these terms, Haskell can be simpler than many languages -- the functional purity eliminates all kinds of moving parts imperative programmers have to worry about.

This is a good step, but widespread adoption means more than renaming of concepts. Unfortunately, programmers who find and learn functional languages are not representative of the population. I'm afraid we would lose a broader audience in the first hour of learning Haskell, as soon as they got to this:

fibs = 1: 1: zipWith (+) fibs (tail fibs)

Beautiful, isn't it? One line of code for Fibonacci numbers, what amounts to built-in memoization, the ability to get and manipulate any sequence, and so on. But it also has only the weakest of ties to a physical analog. Non-trivial examples are much harder to understand. Sadly, an incredibly powerful tool for some is simply too abstract for others to use effectively.

Because of this and other examples, I doubt Haskell will ever be widely used despite all of its advantages. But this is okay -- we need powerful tools for the hands of experts. What I want to see is a more accessible language borrowing the best ideas from Haskell and others. I wish I could use Monads every day, and am willing to sacrifice some of Haskell's other power to achieve this.

This raises an important question: shouldn't we raise our expectations of developers rather than take away powerful features? A valid point, which I will tackle this in my next post. For now, the central thesis of these posts should start to emerge: we need a language with the best parts of Haskell and others in a more accessible form.

The Software Engineer's New Clothes

2006-12-26T13:09:00.000-08:00

The problem with experts is they're too smart. The problem with the rest of us is we don't have the expertise to reign in the experts.

Consider the following conversation:

Mortal Developer: This system seems complicated. Can we do without the WhackAMole feature?
Expert: No, some clients might need WhackAMole to interact with their legacy abacus.

Now our poor mortal developer is stumped. After all, this is the expert we're talking to here -- and if he says we need WhackAMole you better get whacking.

What our developer missed is this: complexity alone is enough to reject a design. After all, you're a smart engineer with years of programming experience. Even if you're not an expert, if a system is hard for you to comprehend, it's probably too complicated. Sadly, there seems to be an "Emperor's New Clothes" phenomenon in software -- no one wants to admit something is hard to understand.

This shouldn't be surprising -- objecting to complexity might be viewed as looking stupid in an industry where intelligence is the highest virtue. Unfortunately this can do a lot of harm. Imagine if the J2EE specification had involved a developer without expertise, but with veto power. Surely the result would have been a lot simpler. This lesson may have been learned for newer versions, but once added this complexity cannot be completely removed.

For anyone that might be struggling with this right now, some humble advice:

Follow Alan Kay's axiom: "Simple things should be simple, complex things should be possible." -- If something complicated must be in the system, it still should not affect the simple things.

View the project as a constant battle against complexity -- A single complex module may seem unimportant, but it quickly compounds.

Understand a project end-to-end -- the project should be easily broken down into problems that are known to be solvable. (Avoid Southpark's 1. Collect Underpants. 2. ??? 3. Profit!!!).

A strong-willed engineer or executive can will a group down the wrong path -- it's an engineer's duty to object and prevent spiraling complexity

The clever hack should be a last resort -- a hack that is hard to come up with is much harder to debug or support

All of this boils down to Keep It Simple, Stupid. It turns out keeping things simple is pretty hard.

Update: This isn't to suggest that all experts fall into this trap, but there is certainly evidence suggesting that some do.

End of software's dark age?

2006-11-26T15:24:00.000-08:00

Software has held more promise and yet met with more failure than any other technology. Meanwhile the hardware guys have been merrily creating more and more CPU cycles for us to swamp.

A lot has been written about why software sucks. Fred Brooks famously predicted there would be no silver bullet improvement in software productive over the next ten years. That was twenty years ago, but there are signs that the dark age of software might be slowly and quietly coming to an end.

Brooks was right about the lack of a silver bullet, of course. But since then we've learned that we've been trying to kill the wrong monster. Building a program was compared to the reliable timeline and quality of building a bridge or skyscraper, and we were mystified on how to get there. This is the wrong monster; instead we need to view code as design and adopt our practices to match. Coding is a creative process with much more in common with design than with any industrial process -- Jack Reeves got it right.

Notice successful development methodologies jibe with viewing code as design. We unit test because a design isn't complete until validated with a simulation. We work in iterations because a change in one part of the design affects others. We document in the source code itself because that is the definitive source of design.

The code-is-design perspective also predicts many supposed mysteries: huge productivity variance, a high number of defects, and failures of rote process are all expected in unvalidated, untested design.

Mysteries and Problems
Fortunately we've taken an important step: software development was once a mystery in search of a silver bullet; now it is a problem with real progress. Noam Chomsky pointed out the first step to understanding the natural world is to turn mysteries into problems. We're seeing the same with software engineering.

Given the premise of code being design, here are some steps to take us in the right direction:

1. Boil out the remaining accidents. We can still have race conditions or leak resources in many programming languages. Newer languages should make these mistakes impossible. We can also learn from existing languages. For instance, the messaging model in Erlang prevents many types of timing problems. Functional languages may eliminate the many types of bugs which arise from side effects. The essence of a design should not be concerned with timing or unexpected side effects, so whenever possible this should be solved in the language itself.

2. Make validation of designs easy. How about the following requirement for a new programming language:

It must be straightforward to write a unit test to reproduce any possible bug.

Since designs must be validated with computer simulation, we must make those simulations easy. Huge strides have been made with various unit testing frameworks, but there are still shortcomings. Proofs of correctness are impractical for most systems, but the ability to easily assert a system doesn't have a particular bug is the next best thing. Furthermore, any bug discovered at any time should be added to the test suite to make sure it never occurs again. This ensures the defect rate of a system trends towards zero.

3. Design and code should merge into a single artifact. We still need design at a higher level than current programming languages, but this design needs to be an asset rather than a burden that gets out of synch with the code.

We are already seeing this: documentation has been merged with source code and tools convert code to UML diagrams and vice versa. But there is a lot of room for improvement. Code in object-oriented languages often includes many unessential objects that are just noise from a high-level view. These should be eliminated from the language, or at least filtered from the high-level design.

There are surely many other examples that I'm overlooking, and functional languages do hold promise. What's important is we now have an idea of why software sucks, and an inkling of what the solution might be.

The real reason we need strongly-typed languages

2006-11-14T20:49:00.000-08:00

There aren't many hard-and-fast facts about software, but here's one:

The more code you have, the more bugs you have.

More formally, lines of code is a strong predictor of defects. So, any language that allows you to do the same work with less code must be a Good Thing. This is why Python is better than Java is better than C++ is better than assembly, right?

Well, almost. The standard counter argument is strongly-typed languages catch mistakes at compile time that slip to run time for dynamic languages. I don't buy this argument, because even though it will catch some mistakes, there are so many other errors to be made you still need to unit test the code. And good unit tests will catch the same errors of strongly-typed languages. Okay, so a lot of people don't write good unit tests, but until they do they're beyond our help anyway. As Bruce Eckel said, "if it's not tested, it's broken".

So why am I a proponent of strongly-typed languages for many (but not all) problem sets? Because they give us one thing dynamic languages by definition never will: unambiguous, guaranteed documentation. Building large software systems means interfacing with subsystems written by others, and they must be documented. Strongly-typed languages have an important part of that documentation built in: they precisely define the input and output types of each procedure call. An API in a dynamic language needs the same documentation anyway, so why provide the chance for error? Even for well-documented libraries, the reduced amount of code in the dynamic language is balanced by increased documentation.

In fact, I'd like to see languages with even stronger guarantees. A Nice addition to Java would be to define references that can never be null. Many times I've used an API and asked, "do I need to check for null?" The answer to my question should be part of the API itself.

Of course, specific dynamic languages may have other advantages over their strongly-typed counterparts. Also, some programs may not need the detailed level of documentation offered by strong typing. Even so, type definitions are a key part of the documentation needed for a large system.