Sponsored Link •
Heron-Centric: Ruminations of a Language Designer
A Weblog by Christopher Diggins
Christopher is the creator of the Heron programming language.
B. Scott Andersen
Vladimir Ritz Bossicard
James O. Coplien
Cees de Groot
David Heinemeier Hansson
Jakob Eg Larsen
Robert C. Martin
John D. Mitchell
Eric S. Raymond
Guido van van Rossum
Richard Hale Shaw
November 16, 2004, 14 comments
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.
November 12, 2004, 8 comments
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.
November 10, 2004, 2 comments
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.
November 4, 2004, 24 comments
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.
October 26, 2004, 5 comments
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.
October 24, 2004, 5 comments
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.
October 22, 2004, 10 comments
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.