AW: slide: useful function?

[William Lee Irwin III]

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