"Fast" means different things to different people

Watching this presentation by Cliff Click, I was struck by an assertion late in the disussion: "Fast" means different things to different people.

To a programmer/developer, "fast" is generally about speed of execution. To a manager, it means time to market or speed of development. Most people involved with the nitty-gritty of programming use the first definition, but lately more of them seem equally conscious of the second.

Consider two programs. One takes a week to develop in C++ and has 1ms execution time. The other is written in an hour in Python and takes around four seconds to run. Which one is "faster"?

This is an old discussion, and most of the common wisdom about it has been rehashed pretty heavily. The first case is best if you're deploying something where 1ms of execution time is preferred to, say, 2ms, let alone two seconds. The second is best if you, the programmer, are the real bottleneck.

Modern programming is, from what I see, an attempt to reconcile those two extremes. Programming doesn't have to be fast to develop or fast to execute; we can in theory have the cake and eat it too.

What people seem upset by is the fact that most of this reconciliation did not take place at the level of designing programming languages or runtimes, but at the hardware level. If Python is ten times slower than C for a job, that matters far less now than it did ten years ago. Hardware developers don't seem too upset by this trend, though, but language and runtime authors aren't happy because in their minds it means a lot of performance is still being left on the table. They're not wrong, they're just not right all the time.

For the vast majority of what I want to do, Python is plenty fast. My first goal with Aki was to make it happen at all, not to make it happen perfectly the first time. Python is a good language to make that happen in because the speed of development I get with it far outstrips every other quality. Compilation speed isn't one of the goals here, at least not yet. By the time it does become an issue, we might well be so far along with Aki that I could just rewrite the compiler in Aki itself. Don't hold your breath for that anytime soon, but you get the idea -- any Aki is better than no Aki, even one that's not wicked-sick fast. Yet.

Another possibility is that Aki will remain written in Python for a good long time to come, because I haven't even begun to explore any of the performance optimizations possible with Python in this domain. It is clear to me right now that lexing and parsing are the slowest phases of the compiler, and that the initialization of the lexer and parser are their own bottlenecks at app startup. (I'm looking into addressing this.)

All I'm trying to do is adhere to a rule I learned a long time ago: first, make it happen; then, make it happen well.