Lambda the Ultimate

That's because we aren't very professional about it...

Every other profession is rife with constraints. And the alleged shortcuts from working without constraints don't seem to be helping us make deadlines.

People love Excel because it lets them do what they want, when they want, how they want.

In addition, they do not care or want to know what end of the gun the bullet comes out of.

There are programming language researchers who want to build the next Excel, besting Pito Salas and coming up with the next thing beyond pivot tables.

As for the quote raould provided and its surrounding context he links to, I'm not sure what to think of it. I think they are effectively saying we shouldn't be using high-level assembly languages to do concurrency. This makes sense, when you consider the direction memory systems are going in. (Raould's mention of the cell processor is a nice example).

However, for the "sufficiently smart compiler" article, I just flat out will say it is one of those things where "the solution is obvious, once you understand what the problem is." Yet, the realization of that solution is not cheap.

Engineering is mostly about continuously building better bootstrapping techniques. You could not build the house I live in today in the 17th century, certainly not in the blink-of-an-eye time it took to build, either. There are more bootstrapping components available today; the primitives for building houses have changed/expanded into new metaphors.

i missed the "http://" part in the link, fixed it.

that theory sounds very plausible to me, and something like Oz makes sense as you say; maybe one could come up with a painful-but-popular C-style syntax for Oz. i assume cilk++ and tbb are getting some 'Greenspun' type traction. i sure wish it were s-exprs that had taken popular root rather than C-style.

if one is a programing language researcher/developer, what makes one choose to go with something more vs. less esoteric looking? does it offend if something solid gets draped in curly-bracket style? since syntax is only skin deep, it seems like it should not be a big deal. maybe we just need a standard front-end for everything, a front-end that supports {}, (), and ML styles?

then after syntax one would see if people are also turned off by the actual ideas in the system, such as promoting determinism.

at the end of the day i pessimistically think that what industry folks really care about isn't reducing bug count or anything, it is to some degree honestly just "can i hire people off the street who can use this language?" / "how hard will it be when i want to outsource this project?"

(which i should perhaps optimistically, a la Graham, see as a competitive advantage to me, should i ever get my angel funding.)

hm, trying to find SHIM online doesn't give me much other than PDFs. i haven't found actual code yet?! more is the pity.

Darpa Urban Challenge was only a semi-realistic driving situation, and they didn't go quite as fast as human drivers could have.

I have little doubt that eventually, yes, computer driven cars could make roads safer and more efficient, but a big hurdle is liability. Even if computer drivers are safer, and lives on the whole are saved, the first time a computer-driven car is involved in a fatal crash... oh my.

is getting lots of flak over the recent Red Line crash, involving automatically-driven trains. It appears that the cause of the crash was a failed sensor, not a software fault or an operator error--but society certainly places higher expectations on automated systems than they do on ones with a human at the controls.

society certainly places higher expectations on automated systems than they do on ones with a human at the controls

Hmm...I wonder if that plays into raould's original comment? That is, our expectations are lowered in a human-driven system relative to a more-automated system; we're willing to put up with a certain level of bugginess in "hand-written" code, but heavily "assisted" programming systems are sometimes denigrated for much lower-impact faults.

Perhaps we're a bit frightened that if we embrace all the constraints and assists, we'll discover that programming is even harder than we thought -- we'll trade all the low-level stumbling we currently do (and know how to make excuses for) for higher-level mistakes that will be harder to explicate.

Have you ever heard of Dr. W. Edwards Deming? He was one of the two founding fathers of statistical process control theory. Many statisticians know his name, but other fields often don't.

He argues that quite often management places unrealistic expectations on subordinates, often expecting better performance from workers than is statistically possible. At some point, assessing 'good performance' needs to be taken into context with what some quality control measure allows. Past a certain point, errors will simply occur in any chaotically ordered system. The Red Bead Game Experiment is his classical example.

I would state my own opinions on the matter, but Deming has corrupted my thinking as a statistician and software designer/product manager. Thus, I just point to him.

i sure dislike the low-level had-wringing stuff that is the bread and butter in industry; i'd be a lot happier if the bug reports we all worked through were at those more rarefied levels.