I find it interesting that one of the expectations on Ioke is that it will be faster than Io. I need to make this really, obviously clear. Ioke is not even close to the speed of Io. Ruby is a blazing arrow compared to Ioke. I know this, and I’ve made a clear design decision to not take performance into consideration at all right now.
There are several ways to think about this. I’m creating Ioke for several reason. One of them is to see how far you can push expressability in a language. Can you take the blub hierarchy another level? To be able to do this, it’s impossible to be concerned with speed.
I realize that if Ioke someday becomes a successful language, performance will be more of an issue. But there are several implicit assumptions in that statement. The first one is that it will be successful at all. After all, most languages fail. If Ioke fails to become successful enough (for any definition of the term), it will almost certainly not be because of lack of speed. And if lack of speed is the only problem, well, that can be fixed by focusing totally on performance after the fact. But I feel that it is much more important to first get the model correct, and then optimize, rather than the other way around.
Programmers all know the old aphorism about the dangers of premature optimization. But we still do it. All the time. It is really hard for me to try to avoid it in Ioke. But I think I’m succeeding, because Ioke is really dead slow right now.
Ioke does need speed. But it doesn’t speed right now. There are many ifs in the success of a language, but if all of them are fulfilled – well, then maybe in a year or two a focus on speed will come. Ioke is a malleable language, and it will be possible to do all kinds of tricks with the language to make performance improvement happen. But that is a consequence of the runtime model. The fact that the language is really flexible makes it slow now, but will make it easier to improve performance on later.
4 Comments, Comment or Ping
I agree that speed shouldn’t be a consideration at this point. Keeping Moore’s law in mind, if Ioke is slow now, a year or so in the future it might run at an acceptable speed even with no changes.
Of course, multicore chips might change the meaning of Moore’s law slightly and require some kind of optimization, but that optimization can wait for a while.
The other consideration is that the current popular languages often take several years, if not close to a decade, to catch on. Ruby would be my prime example here: it’s just now, within the past several years, become the hot new language, but it is in fact older than Java. Python has been around since the early 90s. I doubt Ruby or Python were optimized in their early versions.
I’d say Ioke has a while before it’s going to need to be optimized for performance. Personally, I’m more interested in seeing what can be done with respect to semantics, expressiveness, and language design over what performance improvements can be made. Even if Ioke never becomes a popular language the ideas it creates might catch on and appear in other languages, and that is certainly worth something, as it advances the profession.
January 26th, 2009
Moore’s law states that the number of transistors that can be placed inexpensively on an integrated circuit increases exponentially (doubling approximately every two years). Multicore chips don’t change that meaning in any way.
January 26th, 2009
> And if lack of speed is the only problem, well, that can be fixed by focusing totally on performance after the fact.
That strategy appears not to work so well for python. A language is better designed with compilation in mind. Many of the restrictions mentioned in the Common Lisp spec are motivated by considerations for efficient compilation.
I am not saying that speed in the most important factor, but on the other hand it’s not easy to reverse bad design decisions once there is a sufficient body of code.
January 26th, 2009
@Matthias
Right, but in practice most people just think of the implication of Moore’s law, which is that the speed of chips doubles about every two years, but now we’ve reached a point where the increase in speed is occurring because of multiple cores, not because of clock speed, and that does have software implications.
That was my point with relation to Moore’s law. I should have been more clear on that.
January 26th, 2009
Reply to “Ioke’s need for speed”