Ok, I have two nearly unrelated but interesting things to blog about today—let’s see if I can combine them into one post.

First, Shakespeare. Wow, what a poetic and expressive programming language that gets nearly nothing done! I had a friend over yesterday (Jamin) and we read the “acts” and “scenes” involved in generating prime numbers in the language. We laughed about the idea of actually having a theatre group perform “Primes”. The plot itself might not satisfy the theatre-connoisseur’s appetite. But then, I wonder, would the audience be impressed to find that the story performed before them had actually been an algorithm in action? Nah, maybe not. Well, unless the audience was composed of CS students and math geeks.

Moving on. Second, a decades-old question: Can dynamic languages scale? Ted Neward adds much-needed clarity to the discussion about “scalability” and points out that we must be more careful about what we mean by “scale”. Here are his two definitions:

1. Size of project, as in lines-of-code (LOC)
2. Capacity handling, as in “it needs to scale to 100,000 requests per second”

Shakespeare obviously can’t scale, (in neither the scale(1) way, nor the scale(2) way, but possibly in the scale(3) way of “creativity…”) But the distinction helped me to frame my own programming challenges in a new way—I’ve absolutely loved the scalability(1) of Ruby, but in recent months I’ve become somewhat frustrated by the in-scalability(2) of it as well. Algorithmically, there is still a lot that we can do to improve our MemoryPress.com system, but still, it’s frustrating to be bound by a language that is 40-50x slower than C . I’m starting to eye Erlang, Scheme, and Haskell jealously.

As a software engineer, I find that new material to learn is not in short supply. Gratefully, with discussions and challenges like this, I will be a satisfied student of computer science for years to come (whether I’m paying tuition or not!)