This post is part of the series Programming Theories, in which we discuss new and old ways of programming.

When discussing the design of programming languages or the extension of existing ones, the question What concepts can simplify the tasks of the programmer? always triggers lots of interesting debates. After that, when an effective solution is found, inventors are cheered, and a new language is born. Up ’till this point all seems ok, but the problem comes with the intervention of the status quo: C, C++, Java, C#, PHP, Visual Basic. Those languages want the new feature implemented in the way their programmers expect it. But this would be like trying to implement the advantages of a motorcycle into a car without paying attention to the adjustments needed by the design of the car.

I’m in favor of learning concepts instead of doing new things the old way… but only when the latter has proven to be better than the former. The lean acceptance of i.e. functional languages tells a lot about how it goes in reality (with great exceptions like LINQ). That brings a lot of trouble when moving to multi-core. So, how do we get existing languages to change instead of just evolve?

High Level Languages for Multi-Core

Let’s start with a quote from Edsger Dijkstra:

Projects promoting programming in “natural language” are intrinsically doomed to fail.

In other words: a language can be too high level. A programmer needs the language to be able to effectively micro-manage what is being done. We speak of concerns for a reason. Still, the urge to create the highest programming language is strong.

Don’t get me wrong. A high-level language can be very powerful once its concepts define both ways. One way concerns the developer: does the programmer understand the concept and the contract of the command or programming style being offered? The other concerns the machine: can it be effectively programmed to run the command, or could a new machine be made to do just that? This two-side contract is one of the reasons why natural languages are not fit for programming.

And we have also found out that binary programming is not fit for humans.

The cartoon refers to this gap between what programmers want and what computers want.

But now… How to evolve higher level languages closer to humans without creating a gap filled with wishful thinking?

Back to the Future

We are quite restricted by what we already have discovered. The presentation below explains this very well. The presenter acts as if he were in the past and, from that perspective, he talks about the now. You can notice how people just don’t laugh at some of his jokes. Yes, we accept how things are and continue on the same path. No worries, being change-reluctant is just normal human behavior.

http://www.youtube.com/watch?v=8pTEmbeENF4

The Low-levelness of OpenCL and CUDA

OpenCL and CUDA are low-level languages because they’re defined close to the hardware with i.e. explicit memory-transfers. People tell me that they find OpenCL and CUDA a bit too low-level. I agree, but I disagree with most solutions because of the needed magic. In the next article (appearing within a week) I will put this into perspective and show where the gaps are that restrict progress towards higher levelness.

Even though OpenCL is low-level, it defines what is possible using multi-core and vector programming. These definitions give people the language to discuss higher level language concepts, and this is very important. Using examples in OpenCL I can explain why ‘for’ and ‘do’ have become wrong ways to define loops, while it would be a totally different discussion when the language would still only target single core processors. The question is: do we need to fix loops and other concepts or extend them?

The future of High-Level Languages

We have not solved the parallel programming problem after all those years and multi-core processors have therefore been postponed and postponed until there was nowhere else to go. Not being able to extend our current programming models (mainly iterative and OO) had an important role. Now the programming model of OpenCL has brought us new ways of programming effectively; and this should not be thrown away just because “programmers don’t want it”.

We need a break with the past and start doing things differently for a change. I’d like to end with the conclusion of Bret Victor’s talk:

If you want to be open to new ways of thinking, I think the first step is to say to yourself: “we as a field don’t know what we are doing”.

You have to say to yourself: “We don’t know what programming is. We don’t know what computing is.  We don’t know what a computer is”.

Once you truly understand and believe that… then you’re free. And then you can think anything.

And speaking about thinking… What do you think? Is there a way to evolve languages like C, C++, Java to handle multi-cores and GPUs? Or you think we need to make big changes?