AW: slide: useful function?

[David Bergman]

Hi, Bill.

I agree 90% with you in your questioning the adequateness of trying to
incorporate design patterns in Haskell, and the actual productive use of
them in other languages as well.

But, I must defend design patterns, and Haskell, a bit...

William Lee Irwin III wrote:
> 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

What has this to do with design patterns? There is, as you know,
certainly no need for theoretical substance in order to either define or
apply design patterns. They are often quite vague and pragmatic.

Oh, I see, you switch between critizising design patterns and
declarative languages... Ok, I will try to follow.

> (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.

I have used design patterns mainly as (1) a common language in
communication with development teams and (2) as a library of thought
patterns (adornments, visitors, wrapper etc.) for less experienced
developers (i.e., developers not having built up these patterns
"implicitly"). So, the use of design patterns is *not* mainly to create
code directly, but rather a common terminology within teams and
communities.

But, design patterns are clearly overestimated as a tool for (indirect)
code production, you are right in that.

> (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.

What infrastructure are you referring to?

> (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.

Yes, linear search is certainly bad, not only in that particular
context, but in all... We can all agree on that one.

> 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.

There is one such language: C (if you can call the type system
decent...)
 
> 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

It is also fruitful to separate "formal" and "mathematical" a bit, since
most people tend to diverge into differential geometries, categories,
Gilbert spaces etc. when "mathematics" is mentioned, but stay still when
"formal" arguments are presented. I.e., your example scenarios above
would probably be best classified as formal. Yes, I know that everything
formal is mathematical when scrutinized...

> 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 

Although I do use Haskell for small (in the complexity sense) systems
tasks sometimes, there is a certain pain in my stomach when people
classify Haskell as a scripting language. Developing solutions to
problems is not always scripting (at least not in my problem fields),
and Haskell expressiveness comes to its full right in solving
non-trivial (also, complexity-wise) problems.

> 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.

I hope the Perl+Unix+awk+crontab people do not kidnap Haskell. I think
there are enough linear approaches to "quick solutions". Let us keep
Haskell non-linear! As you said earlier, that would simplify expressing
solutions to non-linear problems. That is the tool needed.

/David