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.

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.

Worlds

Via Lambda the Ultimate I found "Worlds: Controlling the scope of side-effects". With Alan Kay as one of the authors you can assume it's worth reading. And what is really worth visiting is the environment the prototype implementation is built on.

It has really reminded me of Software Transactional Memory and there are several comments in the same line. I've read some of the work by Simon Peyton Jones on the subject, mainly related to Haskell, and I consider it an interesting approach that could simplify many tasks contributing to an increase in quality in many types of applications. 

And as this paper shows,  you don't need a pure functional programming language to play with this kind of concepts, but I really think a type system that, at least, make the existance (or not) of side-effects explicit is really helpful.

Types and Programming Languages

Putting my money where my mouth is, in my last order to amazon (dollar is still cheap) I got Pierce's Types and Programming Languages, after having it in my wish list for a long time.

I expect it to be a long read, as it is pretty long and dense. In any case, even though it is quite academical, I'm sure it'll be eye-opening. Stay tuned.

On Types and Programming Languages

Programming languages and type systems are two fascinating subjects inside computer science, and there are plenty of sites devoted to them. They are great fields of research for academics (and the industry) and source of endless debate in the open source world and the blogosphere.

This week, static vs dynamic typing has been brought again to the front page by this (lengthy as usual) post by Steve Yegge. If you go through the transcript of this pretty interesting presentation you'll see that in the end,  he really focuses on dynamic just-in-time compilation techniques, which are also available for statically typed languages (provided they are run through some kind of vm, such as the hotspot java virtual machine). Anyway, after (or in reaction to) this post a great amount of content in the subject has flourished.

As a debate in itself, it is really interesting because it's a good way to  get introduced to new advances in both camps (and to discover the past, there many things that sound new but were invented decades ago). And in my opinion, it's endless in nature, as the only absolute truth may be that there is no language (nor type system) that fits best in all situations.

So in the end, in many cases is just a matter of personal preference. And even though I really get the value (and in many cases even the need) of dynamically-typed languages I have some personal bias towards static typing (I'm nearer to Cédric's position).

Ironically, I've found myself limited many times by the type system of the programming language at hand (mostly Java) but that has only increased my interest in learning the possibilities provided by languages with more expressive type systems (ML family, Haskell, Scala...).