The Io Programming Language

A friend has been playing with the language Io. I spent an hour or so with him on it. Very interesting.

Io is small prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

The language has an interesting evaluation, reflection, and delegation model. Io has a syntax that does not always require an explicitly denoted receiver for a message. Someone just learning Io can scratch their head once or twice figuring out what's going on.

On the whole though Io is a very simple language with what looks like a simple CPython-like implementation. For programmers looking to understand the "prototypes and delegation" approach to object-oriented programming (as opposed to "classes and inheritance"), then Io seems to be a simple way to dive in deep.

Playing a bit with Io felt a lot like the pre-CLOS days of Lisp in the 1980s when there were a lot of experiments with object systems like ObjVLisp, OakLisp, Loops, etc.

Scaling to Thousands of CPUs

From Shahin Khan in the Register...

A major shift is coming. Over the next few years, your ordinary applications will be able to tap into systems with, say, 7,000 CPUs, 50 tera bytes of memory, and 20 peta bytes of storage. In 2005, Azul Systems will ship compute pools with as many as 1,200 CPUs per a single standard rack...

What would change about application design if you could do this? Well, think back to what applications were like when you had just 128K of memory in your PC and a 512KB hard drive. The difference between the capabilities and flexibility of applications in those days and now is the level of improvement that we are talking about.

It may take more than a few years to get to these numbers for most of us, but I think at that point the change will be even more dramatic. Unless once again the software industry (you know, the "agile" industry) once again is too slow to keep up with hardware innovation.

One reason why I'm getting back into Erlang after tinkering with it several years ago. I want to understand how to think in terms of processes being about as cheap to create as objects are in other languages. One neat thing about Erlang is the sequential aspects of the language are so spartan, the programmer is forced to think about processes.

A single Erlang node on a single CPU today can comfortably get into the tens of thousands of dynamic processes. What would your system look like running hundreds of thousands or a million dynamic processes and lot of activity is spent collaborating with other systems also running at that scale?

See "Apache vs. Yaws" (Yaws is an Erlang-based web server)...

Yaws is still functioning at over 80,000 parallel connections.

The Java community is discussing a new protected-private keyword. This reminds me of the saying about rearranging Titanic's deck chairs.