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.
Connect With Us
- s.mcknight on The Third Eye View
- Qingfeng Zhu on The Third Eye View
- Anil on The Third Eye View
- Olajfestmény on Intel and Stanford Researchers Reveal Peptide Chip Details to Categorize Diseases and Analyze Protein Interactions
- Tony Rivers on Intel and Stanford Researchers Reveal Peptide Chip Details to Categorize Diseases and Analyze Protein Interactions
Tags#IntelR&Dday @idf08 Big Data Cloud Computing Ct CTO energy efficient Future Lab Future Lab Radio HPC IDF IDF2008 IDF 2010 Immersive Connected Experiences innovation Intel Intel Labs Intel Labs Europe Intel Research ISSCC Justin Rattner many core microprocessor mobility multi-core parallel computing parallel programming radio Rattner ray tracing research Research@Intel Research At Intel Day Robotics security silicon silicon photonics software development Stanford technology terascale virtual worlds Wi-Fi WiMAX wireless