Welcome to the second post in the series: In Search Of The Next Big Language (NBL). In the first installment I discussed the internal and external factors a programming language might be characterised by.
In this first post I laid out the plan on the upcoming posts in this series. I decided to deviate from it, because I realized, that this second post – I planned to discuss all language characteristics the NBL might have – will get much to long and additionally it would take me much to long to get the thing finished.
I decided to make short posts. Approaching the topic serially. Focussing on only one attribute per post, but digging a little deeper and not only reference, but also discuss other attributes when appropriate.
After looking at all those attributes, I will discuss the method I will use to examine each language and in yet another the rating scheme. I’m not sure how long this posts will get so be prepared for another split up.
Each of the thereafter following posts, will take an in-depth look at an aspiring candidate. I plan to provide you with an ongoing rating table and try to update older ratings as far as I get aware of major changes in the underlying factors.
The preparation will take much longer than originally planned, but I will post more frequently. As a result, I will delay the monthly language schedule until the first Thursday of November.
After having this organizational things out of the way, let’s discuss the real topic of this post: Performance.
It’s not about developer performance. No. For now we will concentrate on the execution performance. Answering the question: How fast can a computing problem be solved using the programming language in the spotlight? I will rate the language’s performance in relation to a base languages (which might be C). I’m not really sure how to tackle this. There are a number of factors to consider:
- How much ugliness is acceptable to gain speed?
- Is it acceptable to use parallel computing? Yes, if the language is designed for this? No, it its not?
- What might serve as a fair programming problem? What areas should be covered? Filesystem I/O? Networking? Database access? Only algorithms? User interfaces?
Considering all this – and I guess there will emerge more – I will settle on tackling a basic problem. I will be pragmatic and do it in the language’s way. I don’t know how comparable the results will turn out. But that’s true for all benchmarks. We will see.
The NBL doesn’t have to perform like C. So much is clear. The rise of Java is a good example of a poor performer making it. But there should be the theoretical potential of quite high performance. Nothing C like would be necessary (or even possible, I guess).
Rating the performance, is a question of how many optimization steps the code base could have been theoretically gone through. It’s age and invested developer time and genius. You might call this: the languages current lifecycle phase. Yes. There exists a description of distinct phases somewhere. I couldn’t come up with the original source, but I found some cues. The phases were developed by Robin Sharp a few years ago, and are discussed here and here for example.
The phases Mr. Sharp outlined are: Conception, Adoption, Acceptance, Maturation, Inefficiency, Deprecation, and Decay. Unfortunately, that’s basically all I could come up with for now. No real explanation on the characteristics of each phase.
Nevertheless I will take those. And interpret them in my own way. As we are heavily scratching on yet another attribute here, namely Maturity, I will pick up this things again and look at them from a more general standpoint. We are two posts away from this factor.
Provided we know the phase, the performance has to enhance with the progression through the phases. Follow it somewhere between linear and exponential. An NBL candidate programming language in it’s:
- conception phase, has no performance, since it exists only on paper (or in the head of the language’s parents). I won’t discuss those languages, since I have no idea how I might find them and in case that might be possible, further dissect them.
- adoption phase, has acceptable performance to create some basic applications with few parallel users and little data to handle. Something around 20times C.
- acceptance phase, shows high performance in the use cases, the language was designed for. Something around 2times C for common cases and 10times C for edge cases.
- maturation phase, shows high performance even in edge cases. Around 2times C in every situation.
- inefficiency, deprecation and decay phases, are not relevant, since I won’t look at those languages. Despite the pain by leaving Smalltalk finally behind. But I might have to reconsider this decision, since an ancient language might become the NBL. Some boosting factor (whatever that might be) can make a language popular again (or for the first time).
That’s enough about Performance, for now. Concrete calculations will be explained in the posts about the method and the rating scheme.