Lambda the Ultimate

I haven't seen where everyone on the web is discussing Io, but I did notice why's post Io Has A Very Clean Mirror, also discussed on reddit.

The Good:
The language itself is very interesting. For dynamism it's probably close to unmatched. Arguably has macros, even though it lacks a LISP or concatenative syntax, literally everything is modifiable at runtime, uses a bit of strange style of OOP not seen very often (prototype based, differential inheritance). As a language, it's very interesting to at least take a peak at.

The Bad:
The implementation is not the greatest in the world, it typically runs slower than other "scripting" languages, particularly for things like math intensive applications. For dynamic things, not many languages can match it, though. The language's designers and contributers are rather strongly opinionated (who isn't). Often sacrificing efficiency and safety for flexibility and unconstrained dynamism. The GC is claimed to be incremental, though as stated before here, the implementation isn't really incremental. Another thing, is the implementation is rather unstable, which can be a stumbling block for a lot of things.

All in all, I think it's worth a peak, but maybe not much more than that.

it typically runs slower than other "scripting" languages, particularly for things like math intensive applications.

Their microbenches imply greater than Python efficiency with vectors. Their other microbenches imply the same trend. I'd like to see how Io stacks up in the great language shootout to have a more objective measure. It's dynamism is impressive however, even though the dynamism leaks authority like a sieve.

I'm not sure what you mean by "leaks authority." Could you explain?

I thought someone might ask. Take blocks for instance. A block provides the Call object which responds to the 'sender' message, which, if I understand correctly, returns the locals of the calling context. That's a gross violation of both referential transparency, which ultimately impedes compositionality, and capability security, which compromises integrity.

[Edit: to clarify, that 'feature' is certainly a powerful, and potentially useful facility, I just don't think it's a good idea for large-scale software.]

The dynamism of Io is arguably about as strong as you'll find. (How much of this is actually needed is another question.) If this is your number one concern, look no further.

Io does have a number of problems though.

1. Implementation quality is a concern, as previously mentioned. It's less than stable and very slow. That said, the model is fundamentally an expensive one, so it isn't clear how much the speed can be improved.

2. Io has Smalltalk-style blocks. However, due to the extreme reflective nature of the language, they're too expensive to use. Creating a block often results in a huge amount of memory being retained. Accordingly, much Io code (including the standard library) avoids the use of blocks. Methods like 'map' that would normally take a block instead take an expression. The 'map' method then evaluates the expression in the context of the caller. I find this quite clunky and prone to error. It is also less flexible in a lot of cases, and as a result, you find yourself manually passing message objects and associated context objects around in which to evaluate them.

3. Scoping in Io is resolved by traversing a directed graph. This is very slow, but also very confusing. Take this simple example:

Foo := Object clone
Bar := Object clone
Foo do(
   x := 5
   Bar do(
      y := 10
      z := x
   )
)

The above code will actually throw an exception because 'x' is not visible to Bar. This has been an ongoing problem for Io, and despite several attempts to resolve it, no satisfactory solution has been found. Some sort of 'lexicalDo' is needed to replace the current 'do' mechanism. Io's delegation can be very tricky in practice.

4. Bugs are very difficult to track down. The high amount of runtime code manipulation makes things difficult. Stack traces aren't useful. Methods incorrectly supplied with too many arguments simply ignore them. Et cetera.

5. It isn't at all clear which methods mutate the receiver and which return a new object. You might inspect the List object and notice it has a sort method, but short of trying it or checking the reference, there's no way to tell if it will return a new list or mutate the list receiving the message. This is aggravated by some seemingly odd choices as to which methods mutate and which don't.

6. There is currently no module system. Issues related to the delegation mechanism may make this difficult to solve for the same reason creating a 'lexicalDo' method is tricky.

Io is an interesting language. That said, unless you're obsessed with dynamic behavior and insist that everything in your life must be a first-class object, you'll have a hard time ignoring the fundamental problems.

Despite all this, I still like Io: It's simply a lot of fun. I'd not personally use it for anything serious, but it is my hope that some of these issues will be resolved in the future. Io has the potential to be a very nice alternative to languages like Python, Ruby, and Lua.

Have a look at this neat example for adding something like a 'const' keyword to Io. I think that it's amazing that you can do this in Io at the language level rather than in the interpreter itself. You could use similar techniques to do method in-lining, partial-evalutation, JIT'ing, lazily evaluated macros, etc.

Constant = Object clone do (
  type = "Constant"

  init = method(msg,
    self msg = msg

    self activate = method(
      thisMessage setName(msg asString)
      msg
    )
  )
)

const = method(_obj, Constant clone(_obj));

// Let's try it out:

// Make PI a regular number

PI = 3.1415926

// Make b a method that uses it
b = method(PI+PI)

write(b,"\n") // -> 6.283185
// Inspect b's "source" code
write(getSlot("b") code,"\n") // -> block(PI +(PI))

// Make PI a constant

PI = const(3.1415926)

write(b,"\n") // -> 6.283185
write(getSlot("b") code,"\n") // -> block(3.141593 +(3.141593))

// Still works but when we look at the code of 'b' we see that
// the PI's have been replaced with PI's value!!!

From: http://tech.groups.yahoo.com/group/iolanguage/message/953

There is no doubt that Io is very flexible, but is such dynamism effective, or even desired, in large-scale software engineering or mission-critical software?

I have heard that while dynamic languages allow programs to be developed interactively (and thus shorten the development time), it's hard to change such programs, because every time you change something you can not be sure that something else is not broken until you run all the tests from the beginning...which means that for large-scale projects, such an approach might not be effective.

I've done a moderate investigation into Io, having co-authored IoPEG (which isn't fully finished). As part of that, I kept a few notes on things that were interesting to me while learning it:

* Things that surprised me
* Random nuggets of info

Two things that I liked best about Io:

1) Explicit access to and enumeration of 'local' variables, as slots in an object that can be passed along or accessed in the calling scope.

2) The ability to inspect the 'syntax tree' before evaluating it. Among many other things, this let me write a debug function where I can do:
p( any valid io code here )
and have it create the string:
"any valid io code here: {the result of calling the code}"

In many other scripting languages I frequently write redundant/non-DRY debug code like:

output( "People.length: " .. People.length ) -- Lua
p( "People.length: #{People.length}"         # Ruby

Io is the first scripting language that has let me skip that (without having to do something silly like pass the code to evaluate as a string and then eval that).