Io is an excellent language for learning how to use prototype-based languages. Like Lisp, the syntax is stunningly simple, but the semantics of the language lend plenty of power. The prototype languages encapsulate data and behavior like object-oriented programming languages. Inheritance is simpler. There are no classes or modules in Io. One object inherits behavior directly from its prototype.
Prototype languages are generally quite malleable. You can change any slot on any object. Io takes this flexibility to the max, allowing you to quickly create the syntax you want. Like Ruby, some of the trade-offs that make Io so dynamic tend to cap the performance, at least in a single thread. The strong, modern concurrency libraries often make Io a good language for parallel processing. Let’s look at where Io is excelling today.
Io’s footprint is small. Most of the production Io applications are embedded systems. This application makes sense, since the language is small, powerful, and quite flexible. The virtual machine is easy to port to different operating environments.
Io’s syntax is remarkably compact. You can learn Io very quickly. Once you understand the core syntax, everything else is learning the library structures. I found that I could work my way into metaprogramming quite quickly, within my first month of using the language. In Ruby, getting to the same point took a little longer. In Java, it took many months to get to the point where I could make any sense of metaprogramming at all.
Io’s duck typing and freedom allow you to change any slot in any object at any time. This free-wheeling nature means you can change the basic rules of the language to suit your application. It’s quite easy to add proxies at any place through changing the forward slot. You can also override key language constructs by changing their slots directly. You can even create your own syntax quickly.
Unlike Java and Ruby, the concurrency constructs are up-to-date and fresh. Actors, futures, and coroutines make it much easier to build multithreaded applications that are easier to test and have better performance. Io also gives considerable thought to mutable data and how to avoid it. Having these features baked into the core libraries made it easy to learn a robust concurrency model. Later, in other languages, we will build on these concepts. You’ll see actors in Scala, Erlang, and Haskell.
There’s much to like about Io and some suboptimal aspects as well. Freedom and flexibility come at a price. Also, since Io has the smallest community of any of the languages in this book, it’s a riskier choice for some projects. Let’s take a look at the problems associated with Io.
Io has very little syntax sugar. Simple syntax is a double-edged sword. On one side, the clean syntax makes Io, the language, easy to understand. But there’s a cost. Simple syntax often makes it hard to communicate difficult concepts concisely. Said another way, you may find it easy to understand how a given program uses the Io language and, at the same time, have a difficult time understanding what your program is doing.
For a point of contrast, consider Ruby. At first, you may find the Ruby code array[-1] baffling because you don’t understand the syntactic sugar: -1 is shorthand for the last element in the array. You would also need to learn that [] is a method to get the value at a specified index of an array. Once you understood those concepts, you’d be able to process more code at a glance. With Io, the trade-off is the opposite. You don’t have to learn very much to get started, but you do have to work a little harder to absorb concepts that might be otherwise communicated with sugar.
The balance of syntactic sugar is a difficult one. Add too much sugar, and it’s too difficult to learn a language and remember how to use it. Add too little, and you need to spend more time to express code and potentially more energy to debug it. In the end, syntax is a matter of preference. Matz prefers plenty of sugar. Steve doesn’t.
Right now, the Io community is very small. You cannot always find libraries in Io like you can with other languages. It’s also harder to find programmers. These issues are somewhat mitigated by having a good C interface (which talks to a variety of languages) and a syntax that is so easy to remember. Good JavaScript programmers could pick up Io quickly. But having a smaller community is a definite weakness and is the main thing that holds powerful, new languages back. Either Io will get a killer application that drives acceptance or it will remain a niche player.
Discussing performance in a vacuum of other issues such as concurrency and application design is not usually wise, but I should point out that Io has a number of features that will slow raw, single-threaded execution speed. This problem is somewhat mitigated by Io’s concurrency constructs, but you should still keep this limitation in mind.
In general, I liked learning Io. The simple syntax and small footprint intrigued me. I also think that, like Lisp, Io has a strong overriding philosophy of simplicity and flexibility. By staying with this philosophy uniformly in the language creation, Steve Dekorte has created something like the Lisp of the prototype languages. I think the language has a shot to grow. Like Ferris Bueller, it has a bright, but perilous, future.
| [5] |
Ferris Bueller’s Day Off. DVD. Directed by John Hughes. 1986; Hollywood, CA: Paramount, 1999. |
| [6] |
Try Googling for Io language instead. |