🚀 go-pugleaf

In article <8784@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes:
>I'm getting really tired this.  There seem to be some people out there
>who are deliberately pretending not to understand what is meant by B&D
>just for rhetorical effect.  They support their favorite languages by
>pretending that the criticisms are vacous. ..............

I agree. I've been following this discussion with some interest, but
it seems to have come to a point where not much new input is
generated. One person posts a message saying that language X is/is not
a B&D language, and another quickly responds "'tis not true! I clearly
remember one occasion in the spring of '84 where I failed/succeeded in
doing [whatever] in X (:-)".

So to pour some gasoline on the burning wood supplied by a recent
poster, I'll venture to say that almost ANY language can be thought of
as being/not being B&D. It looks to me as if the fact that almost any
language has an underlying "philosophy", is being overlooked by many.
By this I mean that the designers of a language normally have a
clearly stated goal, such as supporting a particular programming
paradigm or solving a certain class of problems. These goals will then
pervade the language in the form of a more or less implicit stated set
of rules telling you how, and for what, you should use this language.
Of you stick to the rules (which you can't do unless you understand
them), you'll probably think "Oh, this is a nice language". But if you
break the rules, consciously or not, you're not adhering to the
built-in discipline of the language, and will probably feel
restrained. Two extreme examples :

* Assembler: Intended for use at the lowest level of abstraction, at
the border between hardware and software. So, if I want to do some
bit-fiddling in the register of some I/O controller, or write a small
piece of time-critical code, I'd feel right at home in assembler. But
if I want to construct a fancy data-type, B-trees say, I'll wast a lot
of time doing things a higher-level level language could have done for
me. Like ensuring type-consistency, through the use of a typechecker.
So I'd feel constrained (having to do a lot of "unnecessary" work)
because assembler doesn't support this type of programming task.

* A purely functional language (like SML, Miranda etc.): Designed to
allow the programmer to write, and think about, programs in a very
formalized and abstract way. It's a dream to construct abstract
datatypes in a decent functional language, but I sure wouldn't want to
write a time-critical interrupthandler in SML. (I know, I know, SML
allows side-effects and might therefore not be considered entirely
pure, but that's beside the point fella's {;-).

So, to sum up: I don't think it makes much sense to claim that
language X is/ain't a B&D language under any and all circumstances.
Some languages come close to being usable general-purpose tools, but
language design is like politics : you can't have it all, so you've
got to compromise. The only other alternative is to build in
everything but a kitchen-sink, and that certainly won't make a pretty
design and would problably not be everything to everybody anyhow.

 -----------------------------------------------------------------
 | Since nobody else will, I'm forced to speak for my self, etc. |
 |  Steen Kroyer -  Oregon Graduate Center - kroyer@ogccse.edu   |
 -----------------------------------------------------------------