How the Wolfram Language Measures Up
June 4, 2014 — Wolfram Blog
Back in 2012, Jon McLoone wrote a program that analyzed the coding examples of over 500 programming languages that were compiled on the wiki site Rosetta Code. He compared the programming language of Mathematica (now officially named the Wolfram Language) to 14 of the most popular and relevant languages, and found that most programs can be written in the Wolfram Language with 1/2 to 1/10 as much code—even as tasks become larger and more complex.
We were curious to see how the Wolfram Language continues to stack up, since a lot has happened in the last two years. So we updated and re-ran Jon’s code, and, much to our excitement (though we really weren’t all that surprised), the Wolfram Language remains largely superior by all accounts!
Keep in mind that the programming tasks at Rosetta Code are the typical kinds of exercises that you can write in conventional programming languages: editing text, implementing quicksort, or solving the Towers of Hanoi. You wouldn’t even think of dashing off a program in C to do handwriting recognition, yet that’s a one-liner in the Wolfram Language. And since the Wolfram Language’s ultra-high-level constructs are designed to match the way people think about solving problems, writing programs in it is usually easier than in other languages. In spite of the Rosetta Code tasks being relatively low-level applications, the Wolfram Language still wins handily on code length compared to every other language.
Here’s the same graph as in Jon’s 2012 post comparing the Wolfram Language to C. Each point gives the character counts of the same task programmed in the Wolfram Language and C. Notice the Wolfram Language still remains shorter for almost every task, staying mostly underneath the dashed one-to-one line:
The same holds true for Python:
Although the typical methods for comparing coding languages are usually by character count or line count, these measures are not reliable when looking at the Wolfram Language. Lines are fluid and arbitrary in the Wolfram Language, and it has long, descriptive function names. On the plus side, this makes the language very straightforward and easy to understand—but it can also skew data when trying to quantify coding efficiency in terms of character count or line count. Instead, we can compare “tokens,” or any string of letters and numbers that are not interrupted by a number or punctuation. This lets us classify length in terms of “units of syntax,” which, while it isn’t perfect, gives us a clearer picture of the number of different elements required to build a function or program.
And so, using tokens now as our metric to compare the Wolfram Language and Python, we see a slightly different spread, but the points still lean very much underneath the one-to-one line, implying that the Wolfram Language still ranks comparatively shorter.
Using a MovingMedian can help clean up some of the ambient noise around these results. Below, the Wolfram Language appears to, on average, increase in token count at a slower rate than Python. Using FindFit, we can estimate that a typical Python program that requires x tokens can be written in the Wolfram Language with 3.48 tokens, meaning a Python program that requires 1,000 tokens would require just 110 tokens in the Wolfram Language.
Similarly in the four comparisons below, the number of tokens naturally increases for both languages as the tasks become larger—but the Wolfram Language gets larger at a slower pace. (Their respective coefficients: C++ -> 2.85, C -> 2.36, Java -> 3.53, MATLAB -> 4.16.)
We can also look at the data in a table of ratios, comparing the languages across the top to the languages to the left. Numbers greater than 1 mean the language on top requires more lines of code.
The Wolfram Language does even better compared to every other language when looking specifically at large tasks.
To see more data, or to experiment with the code yourself, download the notebook at the end of this post. And to get a more in-depth look at the process we used to perform this analysis, give Jon’s blog post a read!