Monday, October 8, 2007

Design Patterns Indicate Programming Language Weakness?

Mark Dominus at The Universe of Discourse examines the role design patterns are playing in software design today and draws some conclusions about what their use and promotion indicates about the state of programming languages.

My reaction to his conclusions is mixed.

Dominus looks way back to how the "subroutine call" design pattern eventually got subsumed into programming languages, thereby removing the need for programmers to explicitly code saving parameters and the return address, in favor of simply "making a function call".

Similarly, one can do object oriented programming in C by following a widely used "Object-Oriented class" pattern, which has since been directly incorporated into other programming languages via "class definition" semantics.

He concludes that "[design] patterns should be used as signposts to the failures of the programming language. As in all programming, the identification of commonalities should be followed by an abstraction step in which the common parts are merged into a single solution."

There's definitely merit to this argument, as evidenced by his citing the incorporation of subroutine and class "patterns" into programming languages. Even more advanced patterns, such as MVC, he observes are starting to show up in programming systems such as as Ruby on Rails.

The aspect that gives me pause, though, is just how where does one draw the line when considering whether to "incorporate a design pattern" into a programming language?

Nowadays, it seems like a no-brainer to incorporate subroutines, classes, and concurrency as built-in programming language features.

But is MVC an appropriate pattern to build in? How far should you go building in direct support for distributed processing into a programming language?

Left unchecked, using design patterns as a guideline for programming language evolution will result in the accrual of more and more language features, with a concomitant increases in complexity, specialization, and learning curve.

Are we considering leaving the era of the "general purpose" programming language behind? And what does it mean to the underpinnings of our software technology if we do?

No comments: