My programming model rules! Yours drools!

In a schoolyard playground somewhere in Silicon Valley … two programmers meet on the swing-set.

P1: My programming language is easy to use and delivers high performance with only minimal programmer effort.

P2: Well my language is better and is safer to use than yours.

P1: Oh yeah … well mine is an industry standard and is supported on every platform that matters.

P2: Who cares … a bad industry standard is worse than no standard at all. My language supports high level abstractions well tuned to future architectures.

P1: Mine does too.

P2: No it doesn’t.

P1: Yes it does!

P2: No it doesn’t. Elegant languages are high level and require fewer lines of code. It takes a zillions of lines of code to accomplish even simple tasks with your language.

P1: No it doesn’t!

P2: Yes it does. See … I have a PowerPoint slide to prove it.

P1: Yeah, but I use a new and improved Paradigm. Your Paradigm is old and musty. We tried your stupid old paradigm years ago and if failed. All you’ve done is put a new name on an old paradigm.

P2: No I didn’t. Mine is better.

P1: Mine is better.

… and so on until the two descend into physical combat and are pulled apart by responsible grownups in the neighborhood.

This is a silly exchange. But when you get right down to it, this is how debates about different programming languages unfold. Most arguments about the inherent superiority of a programming language are contrived, subjective and for the most part say nothing more than that the person making the argument likes one language more than others. Or worse, the arguments focus on performance which says a great deal about the quality of a language implementation but little about the language itself.

If we really want to make progress with parallel languages, we need to stop acting like playground bullies and start acting like adults. We need to define in clear terms what features of a language impact programmability. We need to define a set of standard “programmability benchmarks” so we can make useful and objective comparisons.

In short, we need to start acting like scientists with hypothesis, careful experiments, theories, and honest peer review. Without a more deliberative, scientific process, we will only solve the parallel programming problem by getting lucky. And too much is riding on this problem to leave it to luck.

I have a good idea about how to make progress. I’ve spoken about this in public a few times. To crack this problem we need a community of frustrated application programmers who are tired of the arguing and ready to push for real progress. Please weigh in with your views with your responses to this blog. And over the next blog or two, I’ll share my ideas, comment on yours and see if we can together find a way to resolved this issue and stop the silly fighting.

6 Responses to My programming model rules! Yours drools!

  1. Mark Hoemmen says:

    I’m P2 ;-P
    Seriously, your call for “programming benchmarks” is a good point. One of our student groups in our undergrad parallel class
    tried an ease-of-use study this semester, with two different parallel sorting algorithms. Unfortunately they chose a poorly documented alternate programming language and so it took them a lot longer than expected to finish the project — which itself is a data point ;-)
    The idea of the study was good though — the right class of people to study in programming benchmarks are those who haven’t worked with the languages or ideas much before, have had some exposure in a class or after reading documentation, and are ready to begin work.
    It might help to start with some “dwarfs” (parallel kernels — see that are considered valuable to parallelize. That’s one dimension of the benchmark space. The other is the language and/or environment.

  2. Dimo4ka says:

    >>Elegant languages are high level and require fewer lines of code. It takes a zillions of lines of code to accomplish even simple tasks with your language.
    right 100%

  3. Mike Mallen says:

    Parallelization will be marketed much the same way Virtualization hit the market. The product will be sold as a solution to a problem, (how to justify the expenditure for multi-core products). True Parallel Processing will provide the gains, that will justified the expenditures.
    And databases and file systems as we know them today will also get a major facelift, once “Parallelization” hits the scene.
    And the languages and tools will be offered as accessories. All this will take place in the next software/hardware leap forward, some 3-5 years out, after the Virtualization sales have cooled off.
    The most elegant language is the ‘low level’ usable, and easy to understand and use, ‘machine level’ assembler coded offering. Meaning, a language that will address parallelism at the machine level, within the instructions of the chip (X-86). The number of cores will be limitless, taking full advantage of all the cores, all the time.
    This parallel core offering will also provide for major upgrading of application level parallelism, and they will run in tandem.
    No idle time excuses, (to save energy none the less). Work is work, output is output, time is time, and the less time to do more work is what is desired, (the benchmark that wins out).
    Threading isn’t the answer and it won’t be the ‘winning solution’, because ‘threading’ creates limitations. True Parallelism has no restricting limitations. And Amdahl’s Law will be revisited, and rewritten.
    And scientist in the lab will not provide the parallel solution, (no put down here), it would take to long, and they would run out of funding before the problem was ever solved.

  4. Chris Ward says:

    “I want to sell BlueGene”
    “No, I want to sell 80-core chips”
    … and so it goes on.