Object by Nature

Lei

2009-03-15T11:30:00.000-07:00

Today I created a new project on Google Code for my new programming language, The Lei programming language. Lei introduces some of the more interesting concepts and structures that were developed for the Hula programming language in what will grow to be a practical implementation.

Functions And Objects – The State Connection

2008-12-17T10:08:00.000-08:00

I'm sure that many of you will disagree with me when I say this, and that's the beauty of opinion: there's always more than one.

If you've read by blog you'll know that I've been leaning towards object-oriented programming of late. With that in mind I'll try to leave my own personal bias out ;).

The universe in which we operate is inherently stateful. This is reflected in the languages that we use to write computer programs. This is simultaneously, the reason that functional programming and object-oriented programming exist… and the reason most people feel they're irreconcilably distinct.

I don't believe this to be the case.

In my not so humble opinion functional and object-oriented programming are as two sides of the same coin, trying to solve the same fundamental problems in opposing ways. While functional programming languages eschew state object-oriented programming languages attempt to make it manageable.

A language without side-effects (and the resulting state) would be pretty useless. In the end both object-oriented programming and functional programming languages are trying to manage the unavoidable!

The difference is in the how.

In object-oriented languages state is encapsulated using objects. In functional languages other approaches are used. Monads can be used to isolate such stateful regions of programs in Haskell.

So how are functional and object-oriented languages that different? There must be larger differences.

Perhaps the biggest difference is in the accepted feature set, but even this isn't as big a difference as it first appears. Many of the features assigned to functional programming have also been present in other paradigms for decades, and are not strictly indicative of the paradigm. Others are not limited to functional programming and may be applied in other paradigms.

Of course, the same can be said about any paradigm, including object-oriented programming.

Note: what many people see as adoption of functional programming through mainstream object-oriented languages is really just the reintroduction of features that were present in some of the first object-oriented languages. Thanks to the increased interest in functional programming! :)

To be clear, I'm not saying that functional programming has nothing to offer. The point of this post was to show that the differences are largely ideological. The disagreement about how state and side-effects should be managed is not a reason for us to fight as intensely as we have been recently.

We should help as much as much as we can. After all, we're going in the same direction.

On the other-hand, maybe I'm wrong?!

If you have any comments, corrections or contributions please feel free to shout.

Newspeak Keynote At Smalltalk Solution 2008

2008-11-23T08:24:00.000-08:00

If you can't tell Gilad Bracha is a hero of mine! In this excellent keynote from Smalltalk Solutions 2008 he introduces the Newspeak programming language. For those interested in following along the slides can be found here.

Objects As Software Services

2008-08-20T06:49:00.000-07:00

This wonderful talk by Gilad Bracha (an idol of mine) is truly eye opening, and like much of Brachas work this may be applicable to Hula at some point in the future!

If you haven't already check out his work on the Newspeak programming language I'd highly recommend it.

Hula – The Unfinished Presentation (Version 2)

2008-07-17T14:51:00.000-07:00

The second revision of the presentation is available here. I've added a few details on meta-programming, reflection and program organization in Hula, with some references and general improvements. There's still a lot to come but if you have anything specific you want covering just let me know.

If you have any comments, corrections or contributions please feel free to shout.

Methods to Patterns

2008-07-12T09:26:00.000-07:00

Explaining patterns is difficult. I suspect that the best way to explain them would be to describe their developed. In this article I’ll touch on the relationship between methods and patterns in the Hula programming language.

In most object-oriented languages the behaviour of an object is referred to as a method. A method can be thought of as a function. What makes a method distinct is how it relates to an object. A method is related to an object through a process known as dispatch. During dispatch the relevant definition is selected using the types of the arguments at hand.

Single Dispatch

Just about all object-oriented languages use single dispatch. In these languages a single argument is used in selecting the relevant definition. This makes writing methods that associate multiple objects a bit tedious.

Pseudo-syntax:

object method(...)

Multiple Dispatch

The more versatile multiple dispatch may be preferable, but is often dismissed as not being object-oriented enough, mainly because of the perceived syntactic requirements of object oriented languages. With multiple dispatch each argument is treated identically; that is, every argument is used in selecting the relevant definition.

Pseudo-syntax:

method(object ...)

Refined Dispatch

With standard dispatch the name of the method is usually specified using an identifier. This separation of identifiers and arguments presents some unfortunate restrictions.

Hula uses a unique refined multiple dispatch, which enables multiple dispatch on discrete objects. During a refined dispatch the identity of the arguments (not the type) is used to select the relevant definition. This allows objects to completely replace identifiers in the language, and is perhaps an order of magnitude more expressive!

Pseudo-syntax: 

(method object ...)

or

(object method ...)

etc.

The resulting anonymous properties or behaviours above are referred to as patterns :).

As always if you have any comments, corrections or contributions please feel free to shout.

Hula – The Unfinished Presentation (Version 1)

2008-07-08T16:10:00.000-07:00

I've been working away trying to distill the contents of my various notebooks into something suitable for a presentation. I have a lot of notes so it's not finished yet but if you'd like to read it the pdf document is available here. I'm think this could take a while, but anyway, enjoy part one :).

If you have any comments, corrections or contributions please feel free to shout.

Hula - Another Programming Language? (Project Accepted)

2008-05-12T14:33:00.000-07:00

The project was accepted last week. I'm intending is to start over the summer, but there'll be more posts here once the exam period is over. I've mostly written the second part of The Fragile Object Problem at this point :).

Hula - Another Programming Language? (Project Request)

2008-04-05T20:23:00.000-07:00

I submitted this project request a few days ago, for the final year of my degree program. It includes a nice summary of Hula so I’ve posted it here. Enjoy!

Proposal

This project will examine the design outlined below and compare it with existing alternatives. A prototype of the Hula programming language will be produced based on this research and used to explore the practical benefits of these decisions.

The final document will detail why another language is desirable, why that language should be Hula, and how the observations embodied therein apply to future language developments.

Summary

Hula is a unique programming language that brings a number of elegant ideas together. These include prototypes, selective inheritance and multiple dispatch. Although it can be described as being object oriented, in practice this may be a stretch because Hula is quite different from other object oriented languages.

Hula extends the notion of multiple dispatch to include properties. To accomplish this Hula uses a refined multiple dispatch. This is applied at the object level and allows multiple dispatch to exist within a classless object oriented system. In this context objects contain nothing and exist only to provide identity.

This makes other identifiers redundant. For this reason properties and behaviours are anonymous in Hula. The languages dispatch mechanism is expected to resolve these appropriately, by analysing each objects identity. This can be very expressive: o name, a plus b plus c, a unless b and even select * from t are conceptually valid.

These anonymous properties and behaviours are referred to as patterns. The objects that compose them are termed subjects.

Hula uses a composite inheritance model, which compliments the refined multiple dispatch eluded to above. In contrast to standard inherence, composite inheritance removes dependency between related objects. This allows them to change independently of one another and enables the selective inheritance of properties and behaviours.

If you have any comments, corrections or contributions please feel free to shout.

The Fragile Object Problem (Part 1)

2008-02-15T16:15:00.000-08:00

It’s assumed that languages like Self, which lack classes by design, can not suffer from [supposedly] class related issues. Some of these issues have little to do with classes and so should be considered.

The effect of strong coupling between classes and their ancestors is referred to as “The Fragile Base-class Problem”. As you may expect, systems that suffer from this problem tend to be very sensitive to change.

This problem in particular is quoted as being an inherent benefit of classless object-oriented languages, but has nothing to do with classes and everything to do with inheritance.

Delegation, as found in almost all of these languages is a form of dynamic inheritance. It allows the parent (or parents) of an object to be changed as the program is executed.

On a side-note, even though this method of inheritance is often referred to as prototype-based inheritance it can also be used with classes.

While delegation has many advantages over static inheritance, the problem persists. It does so because delegation follows the same basic principles as standard inheritance. There are no classes but objects are still arranged hierarchically.

Consequently, changes made to one object automatically effect other objects.

This is where classless languages get a chance to shine. Due to the ease of refactoring in these languages, the effect of unwanted coupling like this can be dramatically reduced. At a cost.

At this point it’s worth considering why we organize programs into hierarchies to begin with. There are many good reasons for doing this. If I were to pick just two they would probably have to be: management of complexity and propagation of change.

When objects are placed into a hierarchy we can assume some interesting properties about them.

One of these being that objects in a hierarchy will exhibit all of the behaviors of those located above them. This allows us to reuse knowledge we already have about an object when trying to understand another.

Standard inheritance and delegation provide a convenient way of propagating changes.

The true nature of inheritance may be the subject of academic dispute, but for the purpose of this article I’ll consider inheritance as the mechanism by which one object derives its behavior from another in a given instant.

Both of these are highly desirably qualities for a system of inheritance to have, but they’re not without their disadvantages.

Since the description of an object is spread out above it, the former makes it harder to understand an object individually. You need to understand each object above the one you’re interested in!

The latter introduces a wondrously strange dependancy between an object and its ancestors. Any changes made to an object, no matter how small, will alter all of its descendants.

I feel that it’s a combination of these two qualities which leads to what I would like to (more appropriately) call “The Fragile Object Problem”.

Part two will continue along the same lines as part one. In particular I hope to present how the problem is being addressed in the design of Hula, a new classless object-oriented programming language.

If you have any comments, corrections or contributions please feel free to shout.

Welcome

2007-07-22T00:41:00.000-07:00

This blog will detail some of the ideas behind the design of of Hula, a revolutionary programming language. I'll also include some of my thoughts on existing programming languages, for fun :).

With that in mind, feel free to leave any questions or comments.