In my previous posts I’ve wondered about the future viability of static typing, arrays and loops. Can I get any more out of touch with reality? Well, what about numbers?

Computers are number crunchers, so how can we possibly program a computer with a language that doesn’t know numbers. Surely I jest?

Well yes, but only a little. Numbers are actually very problematic citizens of programming languages. C# is a mess with sbyte, short, int, long, byte, ushort, ulong, float, double, decimal, and even weird pseudo numbers like char, IntPtr, UIntPtr, and pointers. C is even worse, with things such as short, long and long long and rules that do not tell you how long a long is, but do tell you that is at least as long as a short.

And then there are the literals for numbers. C has decimal integer literals, floating point literals, octal literals (which look uncannily like decimal literals, except that 012 != 12), hexadecimal literals and all sorts of weird suffixes. C#, thankfully, gets rid of octal literals, but add suffixes galore. JavaScript had octal literals, then deprecated them, but didn’t quite follow through with that.

Of course, numbers by themselves are somewhat meaningless. Rather than just “5” we might mean “5 meters” or “5 kilograms”. Not surprisingly, there have been attempts at making programming languages aware of the units of numbers. During the early days of the ECMAScript Editon 4 work, a lot of effort went into such a proposal, which got weirder and weirder as time went on and eventually fizzled out and disappeared.

And then there is the small matter of precision. In much of the scientific world, there is a big difference between 5.0 and 5.00. Ada had some interesting ideas here: you could specify the precision needed for a number and then the compiler would select the best implementation that meets the required precision. No other major language picked this up, so the experiment must be considered a failure.

Coming back to C# and its myriad of numeric types, the C# rules for how numeric values are converted from one type to another  are complex and arcane. It can take some careful reasoning and consulting the rather daunting specification to figure out what happens in some cases. There is also a rather tricky interaction between numeric promotion and method overload resolution. At least the C# rules mostly do the right thing. You’ll never accidently turn 255 into -1 or 257 into 1, but you do need to insert explicit casts in many cases where they are not actually needed (which is something you become very aware of when you translate a C program to C#.) Not that C has it right: it happily lets you treat a numeric variable as a signed number in one place and an unsigned number in another, without so much as a “by your leave”.

A big problem these days, when unsuspecting software components are at the mercy of “evil doers” intent on exploring every corner case to see what damage can be done is that most languages provide arithmetic operations that silently overflow. C# lets you specify that particular areas of code should use overflow checking, but it does not encourage you to make use of this checking. And when you do turn it on you are confronted with significant slowdowns as well as the need to handle very costly exceptions every time a number overflows. As a result, few programmers bother to check for overflows, and those who do check, have to pay a heavy price or need to resort to arcane coding practices. A while back I heard a claim that at least 50% of security bugs these days are related to unchecked for arithmetic overflows.

In JavaScript, things are not quite so bad. There is only one numeric type: the IEEE 64-bit floating point number (doubles). Such numbers have the nice property that they do not overflow and that all arithmetic operations are complete (defined for every value).  Yet, JavaScript programmers are not happy campers and the language design committee keeps looking for ways to improve the language. The reason, in a nutshell, is that numeric literals are (mostly) expressed in decimal, while doubles are represented with fixed length binary numbers. This can lead to expressions resulting in numbers that print slightly differently from what high school arithmetic leads us to expect. It also leads to persistent bug reports from incredulous programmers that do not understand the intricacies of fixed length binary floating point numbers.

A persistent proposal is the replace binary floating point numbers with decimal floating point numbers, which is probably an improvement (if one could just change the meaning of existing programs, which we cannot). But this still does not solve the problem of finite precision, which rounding mode to choose and how to deal with the fact that in much of Science, 1.0 is not the same as 1.00.

All this makes we wonder if we should remove the special status that finite precision numbers currently enjoy in programming language. Perhaps the default interpretation of a numeric literal should be: a Rational number represented as a pair of arbitrary precision decimal numbers. All other kinds of numbers should be objects with same status as any other object in the language. Compilers can have special knowledge of some of these types of objects, but this should be an implementation detail, not a language feature.

Of course, compilers should also do an outstanding job of not making you pay the full price of using arbitrary precision Rational numbers as your default numeric type. I suspect, however, that once you remove arrays and loops from a programming language, the performance of arithmetic operations will be much less of an issue.

Should arrays get axed from future languages?

In some ways the question is shocking. Arrays have been built into programming languages since ancient times.  Arrays provide the foundation for many data structures and form the subject of an entire chapter in most introductions to programming. Why meddle with success?

Well, arrays have always been problematic data structures. In FORTRAN they were the source of semantic ambiguity. In Pascal they were the source of type checking problems. In their C/C++ incarnation they have wreaked all sorts of havoc. In their Java/C# incarnation they are so unsatisfactory that no self respecting API can dare use them.

To expand a bit on their C# incarnation: arrays are always mutable, which is a big problem when you need immutable data structures. Nevertheless they always have a fixed length, which is a big problem when you need mutable data structures. They are covariant, but only for arrays of reference types. Covariance is great for read-only arrays, but those don’t exist. Covariance is of little use for mutable arrays, but to use those you must pay the price of a runtime check for every element assignment.

In short, C# programmers should hide arrays deeps inside of fundamental data structures such as the generic List class of the CLR. Unfortunately, the exalted status conferred on arrays by their special syntax and dedicated book chapters makes programmers far too likely to sprinkle arrays all over public APIs. That alone is probably enough justification for wielding the axe.

But merely replacing “int[]” with “List<int>” is probably not going far enough. At the very least it should be “IList<int>” to provide some flexibility for the implementation. But that is not the whole story either: the very idea of random access needs rethinking.

For small arrays, it does not matter very much if one accesses the array elements in sequence or randomly. For large arrays, it matters a great deal. Missing the L1 cache is bad, missing the L2 cache is very bad and taking a page fault is a disaster.

Perhaps the time has come to rediscover and reinvigorate streams as the basic data structure for collections. C# v2 has made a step in this direction with iterators and C# v3 has turned it into a leap with LINQ.

In my previous posting I speculated that compile time type checkers as we know them today may fall by the wayside in favor of something that looks and feels a lot more like the dynamically typed languages.

One of the statements I made, “If you store an object in field foo and then call foo.bar(x, y, z), you really don’t care what the type of the object in foo is, only that it should have a function property called bar that can handle the arguments x, y and z.”, needs further qualification.

Yes, you do not care what the type of the object in foo is, nor do you care about the particular function value that is stored in the bar property. However, you do care about what exactly is going to happen when you call foo.bar(x, y, z). It is pretty hard to program if you do not know what your program is going to do.

In our current champion languages you get narrow things down by being specific about what types of values you may pass to bar and what type of value you can expect to get back. But that is a far cry from knowing what the function is going to do.

Much more useful is a precondition that states “before you call this function, the following things must be true” and a postcondition that states “if you call this function while satisfying the precondition, you can be sure that the following things will be true”.

Our current best practice is to state these conditions in documentation. Getting this documentation to be accurate and to stay accurate is quite a challenge. And much of the time we never quite get around to creating the documentation.

I am persuaded that a programming language that makes it really easy to write down these pre and post conditions (contracts) and that quickly and accurately checks that function implementations satisfy their contracts, will make programming easier and programmers more productive.

In previous posts, I’ve speculated that one of the necessary ingredients for the ascent of a new “champion” programming language is that the overall computing market should expand significantly.

This seems to have been the case in the past, but will the pattern necessarily repeat itself? One could plausibly argue that as computing becomes ever more pervasive, it also becomes ever more diverse and that “one size fits all” programming languages will be displaced by languages specifically tailored to the needs of particular domains.

The argument has merit and does not lack proponents. After all, most communities of experts quickly develop domain specific jargons that help them communicate concisely and precisely with each other, even if this comes at the expense of the ability to communicate with outsiders.

Apart from the LISP faithful, who inevitably  can (and do) point out that every programming language idea worthy of consideration has been present in LISP since shortly after I was born, the most vocal proponents of Domain Specific Languages tend to be from the Modeling community. A typical pitch goes something like this: “I have (or am building) a system that allows you to construct graphical models from an open ended set of shapes and lines. To create a domain specific language, you merely choose a vocabulary of shapes and line and add some syntactic and semantic constraints on how these shapes and lines combine. Then you attach a particular semantics to the language, typically by combining together elements from some convenient collection of semantic constructs that come with the system. Now you have a DSL from which my system is (or will be) able to automatically generate executable code, prove correctness properties, and so on.” For those of us who are “graphically challenged”, there is usually the option to create traditional concrete syntaxes as well.

Intriguing as these systems/proposals are, some words of caution are in order. As the Lispers point out there is not really anything new here. If we look at the domain specific jargons developed by communities of experts, we hardly ever see major departures in alphabet, pronunciation and grammar. For the most part, domain specific jargons are constructed by adding new words to English, sometimes accompanied by new symbols to help with conciseness.

It also bears noting that jargons are seldom designed as a conscious act. Instead, they slowly evolve along with the supporting community, typically in the context of an education system that teaches the jargon along with the expertise.

To me, this seems more like the gradual evolution of routine libraries and frameworks tailored to specific communities, than it seems to me a like new Tower of Babel.

To conclude: programming language design is really hard. A set of innovations that address our major pain points in a coherent way is more likely to come our way in the form a general purpose language created by an inspired team of language experts. Domain specific jargons will not go away, but they will always be based on top of general purpose languages rather than collectively displacing them.

I hope so.

If history is anything to go by it seems inevitable. I have been in the computing field since the mid seventies, mostly in an academic/research/advanced developement context. I've have used many programming languages over the years, but some of them have been much more equal than others at various times.

In the seventies, Fortran and Cobol where champions. In the eighties, we had Pascal and C. In the nineties, Basic and C++ and in the noughts Java and C#. Why would the teens be any different?

Well, in the long run only death and taxes are inevitable. There has always been strong, determined and well grounded opposition to new programming languages. I remember long debates (in South African academic circles) about whether to move from Fortan to Pascal as primary teaching language. C++ sort of snuck in on the back enthusiam for Unix and C, but by the time Java came along there was a large and passionate group opposing its adoption. I also well remember hearing Anders Hejlsberg protesting in 1999: "I am not inventing a new programming language. Nobody wants a new programming language. C# is just C with a few corrections to take account of what has been learnt over the years."

Almost ten years later C# may be a "champion" but is still something of an emerging language. It continues to evolve and shows little sign of senility and fading away. Moreover, the former champions still have their loyal followers and show no signs of impending death either. A new champion will have to have quite a lot to offer before seizing the crown. Getting to the point where there is a lot on offer will require a huge investment. Huge investments are not made often or lightly, and take a lot time. It seems hard to imagine any of the current pretenders to the crown attracting this kind of investment, or a new pretender coming along soon enough to really impact the teens.

Looking back at the successions that did occur, what can we learn? For me a few things stand out: When Pascal and C came along, Fortran and Cobol had far too little support for procedural abstraction and data structures. They evolved, but did so at a glacial pace and events just overwhelmed them. Still, the succession might not have occurred had it not been for the advent of the mini computer and the huge expansion of computing beyond the mainframe IT shops dominated by IBM and the BUNCH.

(Visual) Basic offered event based programming and supported GUI programming in a way that Pascal was slow to match and C never managed. C++ rode the wave of object orientation and the general concern with modularity and programming in the large. Still, the succession may not have happened had it not been for the huge expansion of computing brought on by the advent of the micro computer. The old champions where not so much dethroned as surrounded and reduced to vasal status in a much larger empire.

Java and C# offered garbage collection, strong typing and above all, extensive standardized libraries. But it took the world wide web and a further expansion of computing to make the succession happen. And the succession is by no means complete.

If we are to have another succession, we should probably have another expansion. Is there room for one? I think so, but we'll have to see. My guess is that ubiquitous computing and the "cloud" will provide such an expansion.

A new champion will also need to solve problems that matter to this expanded world and that the existing champions will be slow to provide (or find impossible to provide).

I have some ideas on what this might be, which I'll expound on in my next post.

Herman