Is it time to go stackless?

As a follow-up on Guy Steele's post on tail recursion referenced on my last one and Cook's paper, there's another interesting post by Gilad Bracha that made me wonder: is it time to go stackless?

The stack, as an optimization for call convention is deeply rooted into greatly extended instruction sets. But now, with the amounts of RAM and CPU power available and the really cheap short-lived object allocation time in modern VMs, I think we could afford it, at least for high level languages.

Back in my Python days, I remember Stackless Python, an implementation of this programming language with support for continuations, generators and coroutines.

And this would be only the beginning...

Tail calls in OOLs

Yesterday's paper is also related to a very interesting post by Guy L. Steele Jr. on the need of tail calls on object-oriented languages. A rather polemic issue with strong proponents (such as Guy) and detractors, like Guido Van Rossum, Python's creator.

I'm sure more interesting contributions will follow.

Readings on Dec 6th 2009

Today's reading has been "On Understanding Data Abstraction, Revisited" by William R. Cook. It has really been an eye-opener on the differences between abstract data types and objects, and it have helped me  understand the implication of the different approaches taken by different programming languages.

Highly recommended.

Functional dependencies

Regarding papers, yesterday's read was Type Classes with Functional Dependencies by Mark P. Jones.

Quite interesting.

Living on the edge...

As predicted by Murphy's Law, if you need some feature (or a critical bug solved) from a third-party library or framework, it'll be planned for the next version.

I faced this truth again a few weeks ago. I was looking at Guice for some specific dependency injection needs... and type converters where planned for 2.0...

A Domain Driven Design snippet

This post in my reading list reminded me of Domain Driven Design (see the book). I've always liked the idea of strong Domain Models that lead to better encapsulation and more information hiding.

What's the problem, then?. For many (even CRUD) applications much business logic involves non-trivial repository access. So, you need your bussiness objects have a reference to the repository. This should not be a problem for your favorite dependency injection engine.

At this point your favorite ORM tool chimes in, taking control of the lifecyle of your domain objects... Well, there are some AOP-based solutions, but I don't see them as long-term general solution yet.

The Properties Pattern

Last monday Steve published another lengthy post on what he called The Universal Design Pattern. As I read through it, it reminded me of my personal walk through some of the issues described there. It was in the JDK 1.1 days, when the JavaBeans specification had just come out. The JavaBeans event system identified the properties as strings, which led me to try what Steve calls the Properties Pattern in a never-finished project that I used a test-bed int the late 90's: a Java port of a Monopoly-like game I wrote in C++ back in 1994 . It was an interesting experiment, and I had to deal with many of the issues described in Steve's post. Anyway working with string-based properties in a language like Java is quite uncomfortable to say the least.

However, this does not mean that you need a dynamic or a prototype-based language to enjoy the advantages of this approach. In the end, each property has some pieces of metadata that could encapsulated into... a type. You just have to add an API that makes it convenient to deal with this kind of properties. Frameworks such as Guice have really raised the bar on what can be done getting the most out of the Java type system and the levels of type-safety that can be achieved.