This is part of the story and this is interesting, but as both an employer of technical workers and a technical worker myself it doesn’t seem so simple to me. I have certainly seen large numbers of entitled technical workers who simply refuse to learn anything new and are neither able to take initiative or willing to take direction. But it is undeniable that investing in software R&D is anathema to many corporate managers and also that US technical corporate management takes decisions to outsource often with zero substantive research on cost/benefits. And it’s not unusual to see situations where technical staff who actually create the products that bring in the wealth are shut out of the rewards. Corporations where top management who do mediocre work routinely earn millions while top technical talent is locked into some parsimonious wage scale are common.Â Also, as the soon-to-be US President has pointed out, the era in which corporate management takes decisions that hurt their own employees (or customers) without any sense of responsibility is one that needs to end. “Maximize shareholder value” is often used as an excuse for utter callousness and short sighted greed.
No thumb drives for the US military. (found on David Bader’s page)
The last time I went to a “Supercomputing” conference, Jim Gray came by to talk to me and Cort about PowerPC Linux. That must have been in 2000 or 1999. We had gone by the AIX booth and been roundly sneered at by IBMs Operating System Gurus and were walking away, somewhat crestfallen, when Gray stopped by to talk and to illustrate why he was such a widely admired person. Yesterday, I went by SC08 here in the Capital of Texas, snuck into a talk by one of the poor people who survived my Operating System class back before 2000 and roamed the floor looking at all that, as we highly trained and educated technical people say, “stuff” on the floor.
The problem of parallel computing is, of course, the standard topic of SupercomputingÂ and currently Supercomputing seems to be a celebration of MPI. I was amazed to see that people have added parallel constructs and even MPI to Mathematica. Why not just try to automatically extract parallelism from the high level constructs?
Not as strange as the Tokyo University use of parallel Ruby for scientific computing though.
He [Perlis] published a very obnoxious paper arguing against a mathematical approach to programming cite
Here’s the paper by De Millo, Lipton and Perlis. It starts as follows:
Many people have argued that computer programming should strive to become more like mathematics. Maybe so, but not in the way they seem to think. The aim of program verification, an attempt to make programming more mathematics-like, is to increase dramatically one’s confidence in the correct functioning of a piece of software, and the device that verifiers use to achieve this goal is a long chain of formal, deductive logic. In mathematics, the aim is to increase one’s confidence in the correctness of a theorem, and it’s true that one of the devices mathematicians could in theory use to achieve this goal is a long chain of formal logic. But in fact they don’t. What they use is a proof, a very different animal. Nor does the proof settle the matter; contrary to what its name suggests, a proof is only one step in the direction of confidence. We believe that, in the end, it is a social process that determines whether mathematicians feel confident about a theorem–and we believe that, because no comparable social process can take place among program verifiers, program verification is bound to fail.
To me, the problem with Dijkstra is that he was so sharp and such a good writer that he was able to make persuasive cases out of wrong ideas. Dijkstra wanted to be a scientist in the model of theoretical physics, not an engineer. I’m pretty confident that Dijkstra was wrong: programming is engineering – in fact, physics is not as far from engineering as some people would like to believe. I’m not a huge fan of the engineering discipline as it exists in the USA. It has all sorts of negative aspects – including those Dijkstra railed against. But the vision of a programmer as, not a mathematician, but a formal logician flying far above the grubby compromises and trade-offs of mere engineering in a platonic bubble of pure reasoning is wrongheaded.
Dijkstra published some criticism of the Demillo paper at the time and in their response the authors stated something that, as far as I know, remains true
We must begin by refusing to concede that our confidence in a piece of
real software has ever been increased by a proof of its correctness
When I was in graduate school, a famous formal methods scholar came for a talk and explained to us that formal methods were needed if we were ever going to develop fault tolerant software. I pointed out that, for example, the Tandem Software worked pretty well in practice. “It cannot”, retorted the famous scholar.
Thanks to Ohioans. (and Virginians, Floridians, Iowans, … ). phew.