My previous blog entry on the bank account class, sparked some lively and interesting discussion. It also revealed two very distinct approach to object oriented programming, which I label the bottom-up approach and the top-down approach.

A technique which I use over and over again in C++ and Heron, which also can be used in Java, is inheriting from a template parameter. I am searching for a name for this pattern. One of the trouble spots for this pattern is lack of constructor inheritance in C++ and Java, but this can be worked around.

The December 2004 issue of the C/C++ Users Journal has just come out and contains an article I wrote "Constrained Value Types using Policies" which discusses how to use policies to define special cases of value type which must conform to specific ranges or sets of values.

The example of a bank account class is a canonical one in the object oriented programming (OOP) literature. Here are my thoughts on how the bank account problem should be approached.

Reposting a proposal for interfaces in C++.

Possibly my favourite feature of Heron, and what sets it apart from C++/Java/C# style languages is that primitives are defined in a library, not by the language. Why other languages don't do this is beyond me.

I designed the Heron programming language because, like many other programmers, I was dissatisfied with other languages. In this entry I list some the features that what I was looking for in a programming langauge.

The catch-22 of developing a programming language is that the onus is on the designer to promote the language unless they have some kind of corporate backing. This means that often you have to implement most of the functionality before people see the value in helping you create an implementation.

Programming with Contracts is a sofware development technique rapidly gaining in popularity but still somewhat misunderstood. I have been spending a lot of time lately writing about contracts and using them in the Heron standard library.