On Mon, Dec 02, 2002 at 10:37:09AM +1100, Andrew J Bromage wrote:
In the interest of fairness, the declarative programming community occasionally appears to have an aversion to actual engineering. If you mention a term like "design patterns", people look down their virtual noses at you like you're trying to infect their pure theoretical world with something unsanitary. My point is that nobody is immune from this kind of thinking, it just takes different forms.
I've got some issues here: (1) Various things I'm doing as a practitioner lack theoretical background (and/or content) for various problems in them. e.g. how does one measure per-cpu time spent waiting on io on SMP? e.g. page replacement mixes kinds of memory, creating list searches (2) In theory and in practice I've seen "design patterns" and a couple other "popular" programming movements add up to nothing. Design patterns in particular produced precisely zero useful code or code design during its entire lifetime as designs on the level on which its principles operate are not ever getting freshly redone. (3) Various tidbits of theoretically motivated languages assume so much infrastructure as to be unsuitable for various (kernel) environments. There's a circular dependency between what some things implement and the infrastructure assumed, which is where the problem lies. (4) There is no excuse for willful ignorance. Linear searches in interrupt context and other gross inefficiencies have brought systems down because the events triggering the poor algorithms occurred in realtime and are generated by hardware. They consistently livelocked boxen with sufficient cpu counts. At any rate, the gist of all this is that even though I don't use much in the way of theory now, I would like to use more of it, and there are various things I wouldn't mind having that aren't universally available. A much lower-level language (i.e. one requiring far less infrastructure) with a decent type system and some modularity would be nice for systems programming, which is the majority of my work, but it really just doesn't make a difference because the work is generally concentrated on a given preexisting system, which isn't going to get converted between languages. And last, but not least, programming is a mathematical discipline. Even the most dreary programming tasks are phraseable as such. (1) hardware does not obey spec, but driver is needed -- augment the driver's state machine to handle new error cases (2) ridiculous code/patch merging constraints are enforced -- analyze program structure to devise incremental merge strategy (3) make process interaction and/or scheduling decision -- scheduling has lots of mathematical stuff behind it None of this is to say that I haven't made extensive and highly beneficial use of Haskell in userspace, which I have. It is a full- blooded substitute for perl, python, and several other "scripting" languages that supposedly ride on the breadth of their libraries that instead remains self-contained without the need for domain-specific library knowledge, which is by all measures a great boon (substituting general for specific knowledge). The highly general, flexible, and expressive language semantics infrastructure negates the need for many preassembled libraries meant to avoid tasks that are generated by the awkwardness of expressing various idioms in less powerful languages. Bill