Lambda the Ultimate

Rather we should praise them for its flexible, postmodern nature: one cannot pigeonhole software by such outmoded and meaningless labels as `correct', `secure' or `reliable'. Modern software developers know that such terms are only artificial categories invented by sophists to simplify reality and so oppress developers.

The sophist says, `Users demand correct software.'

The developer rightly replies, `Correctness is an illusion. The program exists or it does not exist; it behaves as it behaves. Motibo ergo sum.'

The sophist counters, `What users want is an illusion?'

`No. We exist only to serve. Such is our purpose. But our masters are fickle,' says the developer. `They do not know their minds, which are clouded by their own desires.'

`How can you serve your master when you do not acknowledge his desires?'

`We are clever and nimble. Though a chasm lies between us, our master may say, ``Come hither,'' and we run elsewhere very quickly, knowing his true mind.'

`Why do you not build a bridge?'

`We have no such art; do you think us engineers?'

`Then why do you not tell him you cannot please him?'

`Simpleton! Who bites the hand that feeds? He is anywise oft amused by our agile antics. We do not go where he asks, but where we go, we go quickly.'

Here endeth the lesson.

I'm guessing the "radical" solution of constraining pointer use or using a language that makes it easier to detect and avoid overflows has been ruled out a priori by the large code base and his lack of imagination. ;-)

Though you have created a convincing parody of the worst excesses of software development, it is also an accurate parody of almost ANY human activity.

It seems that to some extent you think programming should NOT be a human activity, but a tightly-constrained mathematical one.

And though I understand the impulse, and have felt it myself, there aren't ANY domains that I know of that AREN'T subject to the kinds of human factors you lampoon.

Science, engineering, even mathematics itself, are subject to social pressures such as pleasing academic supervisors, appealing to journals, reflecting the latest fads in the field, etc.

And this isn't a strange "impurity" in these activities, but a side-effect of their core function: to expand the bounds of human knowledge and power. Since humans are humans, so is everything we do infected with human foibles.

At this point we can throw our hands in the air and say "what's the point then?", but my prefered approach is to find ways to be effective in spite of the vagaries of human behaviour.

In a PL context, this means understanding what features people like and dislike, find intuitive and unintutive, what disciplines are simple enough that people will follow them, etc. and take that knowledge to build a language that is human-tolerant and relatively safe.

You may not be far wrong...

It seems that to some extent you think programming should NOT be a human activity, but a tightly-constrained mathematical one.

Mathematics is a human activity!

Indeed, it's a characteristically human activity, as we learned when Gödel showed us that (non-trivial) mathematics is one of the things a machine can't do.

So if you aren't sure sometimes
If you control your UNIX box
Or it's controlling you,
Show it who's the boss:
Prove a theorem or two!

Blecch... that needs some work.

And though I understand the impulse, and have felt it myself, there aren't ANY domains that I know of that AREN'T subject to the kinds of human factors you lampoon.

I wasn't lampooning human factors at all (except the `bite the hand that feeds me' part, which I put in out of spite) but rather intended to show that `agility' is meaningless without correctness.

I agree completely.

but rather intended to show that `agility' is meaningless without correctness

I don't think this is controversial in and of itself; the tricky part is what you think it means to be correct. One definition is: "proven by theorem to be equivalent to some specification". Another is: "Conforms to the expectations of the boss or user".

There not mutually exclusive, but they are not identical either.

The final product he shipped had no observable buffer overruns. (He was a "army of one" so to speak, tested his code in numerous ways, and had written exception handlers that no test he could come up with, ever triggered.)

So - the statement "buffer overruns are inevitable" only makes sense when you write complex systems in low-level languages, and in particular, when you write in a low-level way, in those languages.

[2] Frank, thanks for today's lesson. That was a hoot. :-)

[3] There was an article sometime in the 80s in Software Practice and Experience (Welsh? is that the author?) called "Efficient Range Checks in Pascal." The gist: in Pascal, one could provide 100% coverage in array bounds checks, for an overhead of something like 20% in run time. (The 100% coverage was a combination of actual run-time checks, and other instances in which you could prove the check would never fail, in which case you eliminated it. Think about iterating over a suitably-defined array type whose index is an enumerated type, as an example.)

I don't know enough of deep compiler theory to know how "20% hit for Pascal" translates to C or C++. My understanding is that C (etc) has various horrors in its type system that make array bounds checking hard enough to implement, that no vendor does it.

[4] Every programming language comes pre-attached to a culture --- a set of values speakers share, and that programs they write, embody. (warning, gross overgeneralizations follow) The Ada culture favors readability. The Haskell culture favors proveability. The Lisp culture favors hackability. The C culture favors, uh, constant employment.

I write "constant employment" only partly tongue-in-cheek. C programming for large, complex systems -- the more horrendous the data structures, the better -- is a test of manhood. The correctness of the end-result is secondary to the awe inspired by having the system work *at all*. And if the system is hard to modify, well, you can always pay me to continue working on it, right?

In my observation, non-C/C++ cultures seem to revolve around other core values (correctness, dynamism, expressiveness, etc). and Microsoft? Microsoft is a undying bastion of C culture.

For example, if someone wrote a webserver and was fool enough to use an buffer of 80 characters to process input, and someone sent a message longer than 80 characters, the spillover would fall into the operating system and be executed as a command inside the host system.

This problem was fixed pretty quickly in the Apache webserver.

Microsoft's problem is that their webserver is closely integrated with their operating system, and therefore can access quite a few libraries on the host, and so the MS coders would have to go through each one of Microsoft's DLLs and find all the potential buffer-overflow problems, and then fix them.

(1) The first principle was security: ...
A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array.

Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous.

Microsoft is a undying bastion of C culture.

On the contrary. Externally, the source code for most of Microsoft's products is not shipped with the product, so Microsoft as a company gains nothing by making it difficult to work with.

Internally, writing complex code would (1) make it more difficult to pass code reviews, and (2) make it more difficult to transfer to other interesting projects (because your lead would not want to give you up).

I think you are on to something. The company really goes after the developer mind share.

But all language providers seem to have a need to always "upgrade" their languages with more features. Perl, Python, Java, C# it doesn't matter. OSCON, Java One, and whatever it is MSFT has all have sessions on what's next for these languages.

If developers had a sense of history, they might be content with a language that has garbage collection and classes or functions. Those were the hills that needed to be climbed IMO. Everything else (iterators, generics, XML, AOP, etc.) is icing on the cake.

Anyway, I was thinking about the "eat your own dogfood" mentality, which is related but not identical to going after the developer mind share (they are developers after all...)

Cyclone ( http://www.research.att.com/projects/cyclone/ ) is probably the best known project that does this.

Cyclone and Vault (a somewhat similar MS research project) have been mentioned on LtU.