Victus Spiritus

Who likes waiting for more complex programs to run?

In doing some research on fast dynamic programming languages, a couple of great finds caught my attention. I’m seeking a language that feels like Ruby but can run natively faster than using the MRI for the types of problems I like to work on (some numerically intensive). Alternatively, I don’t want to waste time with premature optimization. I am looking for a development language that is easy for me to create in, build on, and fast to execute, and finally has the easy to read syntactical feel of Ruby (I often reread my own code to figure it out months/years later). I’ve looked at Scala before, but have found much more enjoyment in Ruby coding. My fear is that a faster execution environment will detract from the qualities that endear me to dynamic languages (I come from c++ my day job’s default, so all of this is gravy to me). JRuby has shown some promise as well as the underlying tools (Duby) that are used to make interpreting Ruby on the JVM a more enjoyable process.

Q&A on Stack Overflow

Fortune smiled on me early this morning. I came across a couple of Stack Overflow answers which I appreciated on several levels. Over the past week I’ve grown accustomed to waking at 4 and searching for topics that have been bothering me. If the meritocracy of dynamic programming (features over class hierarchies) and malleable language structures call to your creative interests, you may need:

a) psychological help or

b) a damn good dynamic programming language

The first question “Are dynamic languages slower than static languages”. Jorg W Mittag’s well crafted response (here’s an excerpt):

In general, running well-designed code on well-designed high-performance execution engines will yield about the same performance, independent of whether the language is static or dynamic, procedural, object-oriented or functional, imperative or declarative, lazy or strict, pure or impure.

In fact, I would propose that the performance of a system is solely dependent on the amount of money that was spent making it fast, and completely independent of any particular typing discipline, programming paradigm or language.

The second question “What’s the difference between Duby and Juby and why would I need either of them?” has several parts:

• “What’s invokedynamic and why does Duby “need a playmate”?”
• “Could someone elaborate a little bit more on what this distinction is about?”
• Why do we need (need!) another Ruby-related language? Or, rather, two more Ruby-related languages?

and another great answer from Jorg (2 snippets):

2. Could someone elaborate a little bit more on what this distinction is about?

Duby is statically typed, Surinx (which is the final name for what was for a short amount of time called Juby) is dynamically typed. That’s already all there is to it.

Actually, there is one small detail as a consequence of this: Surinx syntax is a strict subset of Ruby syntax, i.e. every syntactically valid Surinx program is also a syntactically valid Ruby program. Duby OTOH is almost a syntactic subset, except for its mandatory method parameter type annotations:

def foo(bar => Integer, baz => String) => Array
# …
end
3. Why do we need (need!) another Ruby-related language?

Now, the funny thing is, Charlie came to Ruby, because he didn’t like his day job, doing Java development. And now, he still writes Java code all day long! Of course, he doesn’t like that, and so he was looking for another programming language in which to implement the core of JRuby. One option would certainly be to just write it all in Ruby, but with metacircular implementations there usually comes a point of diminishing returns, where the implementations degenerates into academic masturbation. It would certainly make sense to rewrite the libraries, the ahead-of-time compiler (actually, that’s already being done) and some of the core classes in Ruby, but some parts of the engine core are better written in something closer to the execution model of the JVM itself.

Charlie was looking at the available options: Scala, Groovy, Fan, Clojure, Nice, but all of them had a significant disadvantage: a fairly large language runtime. The size of the JRuby runtime is already a big problem in terms of memory consumption and startup latency (especially compared to MRI or YARV and even more so if you actually include the JVM itself in your measurements), and rewriting it in a language that adds its own runtime to that weight is simply a no-go. Unfortunately, there was no programming language which satisfied the two basic criteria Charlie was looking for: no runtime and compiles to JVM bytecode that is at least as efficient as the equivalent Java.

So, he decided to create his own. The reason why he chose to use a syntax similar to Ruby, is actually quite simple: he didn’t need to write a parser for it, Duby just uses JRuby‘s already existing parser with one minor modification to support method parameter type annotations. (Actually, he also likes Ruby‘s syntax, that was of course also a factor.)

Where are Programming Languages Going?

What I took away from my morning readings is that unorthodox optimization is already happening. People are selecting languages where they can quickly express themselves, and comprehend structures and flow easily. They’re even going so far as to adapt these “syntactically pleasing” languages and highly dynamic forms to faster compilers (Just in time compiling on the Java Virtual Machine, or even gcc)

The most popular and useful programming languages of the next ten years will share some of the following characteristics:

• Super Simple, Lightweight, & Easy to Get Started: the lighter the syntax and language, the more inviting it is to new programmers. New programmers come from all backgrounds and specialties. They bring their practical domain expertise to bear on problems dedicated hackers have a hard time understanding
• They will be net native. The most useful languages will be useful anywhere and everywhere on the web within browsers, JVMs, Javascript Optimizers, etc.
• Super Fast: programmers are nearly always subject to premature optimization. I do it unconsciously, and it’s a terrible habit. Of course there are mistakes aka “you’re doing it wrong” (usually made when underlying structures aren’t understood). If you’re trying to solve a problem, make the solution your first priority, then iterate on speedups after you have true representation of the data flow and usage.