Saturday, September 18, 2010

Structured Programming and Functional Languages

I am reading a book chapter titled "Origami Programming" by Jeremy Gibbons. I came across an interesting paragraph:

There are advantages in expressing programs as instances of common patterns, rather than from first principles -- the same advantages as for any kind of abstraction. Essentially, one can discover general properties of the abstraction once and for all, and infer those properties of the specific instances for free. These properties may be theorems, design idioms, implementations, optimizations, and so on.
Nicely put! He also mentions how functional programming are more flexible in accommodating such useful patterns: 
... In functional programming, in contrast to imperative programming, we can often express the new constructions as higher-order operations within the language, whereas the move from unstructured to structured programming entailed the development of new languages. 

On Design Patterns

I am mostly disappointed by this whole 'Design Patterns' business, and I wish there were better alternatives. And I hope I have good reasons for my disappointment.

The first issue I have is with the name (a minor issue, but I care a lot about names, they have a large impact on the effectiveness of communication). What part of these is about 'Design'? They are almost invariably invoked by programmers to organize their code. Shouldn't they be called 'Programming Patterns'?

Another problem is that I frequently doubt whether learning them is an economical approach to improve one's software engineering and coding skills. The way I see them,  many such patterns (introduced mostly with languages such as C++ and Java in mind) usually simulate a feature of some other programming language. For instance, the visitor pattern is the simulation of the ability to write functions over user defined data types in ML-based languages such as OCaml or Haskell. Another example is the use of the Builder pattern to avoid functions with long argument lists, most of which have reasonable default values. In a language with names parameters, such as Python, you do not even need to think in terms of this pattern. It seems to me it's more profitable for programmers to spend their time learning other languages and familiarize themselves with some specific features that is missing in their working language.


That said, there are a couple of things that I like about the Design Pattern culture. Most importantly, it has created a common vocabulary for programmers to talk about these patterns. Another nice thing is that it is easier to sell a pattern and convince people to use it if it has a name and is catalogued in some Design Pattern collection.  

There are negative sides too. Since patterns are not formally defined, and unlike language features are not compiler enforceable, it is easy to abuse them by not paying attention to the constraints of the patterns (often people who introduced the patterns didn't think about such constraints to begin with). This problem was later curbed by the introduction of a new subculture of 'anti-design-patterns'.  Another  disadvantage is that if you propose a pattern inspired by a language feature that is not yet added to commonly known databases of patterns, you are likely to face some resistance in accepting it.

It is unfortunate that there isn't a larger effort to introduce such patterns as language features instead of a collection of verbal metaphors and conventions. The Java language is a relatively good example of having attempted to do so, even though very slowly, in the past. I wished more languages would follow this trend and/or more advanced languages would get adopted by programmers.


Friday, September 10, 2010

Disappointment vs. Disaster

Paul Krugman makes the point that disappointment is better than disaster. Who are you going to vote for?

Followers