Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!mailrus!purdue!rjh
From: rjh@cs.purdue.EDU (Bob Hathaway)
Newsgroups: comp.lang.misc
Subject: Re: What is B&D? (Re: Bondage and Discipline Languages)
Message-ID: <5818@medusa.cs.purdue.edu>
Date: 11 Jan 89 16:27:06 GMT
References: <8540@megaron.arizona.edu> <2630@ficc.uu.net> <13293@cup.portal.com> <5795@medusa.cs.purdue.edu> <2670@ficc.uu.net>
Sender: news@cs.purdue.EDU
Reply-To: rjh@cs.purdue.edu (Bob Hathaway)
Organization: Department of Computer Science, Purdue University
Lines: 57

David Gudeman writes:
>It's not an analogy, it's a pun.  And it refers to the philosophy of
>language design in which the language designers feel it is their
>responsibility to constrain (hence ``Bondage'') the programmer to
>adhere to certain Disciplines in programming.  Now, ``Police state
>language'' is an analogy.  And it doesn't refer to a paradigm (a way
>in which a given languages encourages the programmer to view
>computation) since there can be functional and logical B&D languages
>as well as imperative ones.

>You don't lable a language ``B&D'' just because you can't do something
>in that language, you call it that because (1) there is something you
>can't do, (2) the designers of the language predicted people would
>>want to do it, and (3) the designers deliberately made it impossible
>because they thought it was a bad thing to do.

This sounds like you don't know programming as well as compiler writers,
language designers, programming language hobbyists, ...  I, and several
others I have talked to can do anything we can do in C in Pascal, Modula,
Ada, etc.  At *worst* we'll resort to medium level programming or operating
system calls, or even external language interfacing although the first two
possibilities are sufficient.  Ada and Modula-2 offer low-level facilities
and Ada doesn't even require explicit context clauses to access the
system package. 
>
>I don't suppose there is much point in arguing language design
>philosophy, since different languages are designed with different
>goals and priorities.
>

This is true but at the risk of sounding elitist, just because you
can't figure out a way to program something in Language X doesn't mean
proficient programmers can't.

Peter da Silva writes:
>Are you using the phrase "dynamically typed" to refer to object-oriented
>languages? I haven't run into this phrase before, and it's quite evocative.

No, although object-oriented languages such as smalltalk are frequently 
dynamically typed.  I usually consider two basic types of polymorphism,
statically checked and dynamically checked, although this is not
the canonical view.   Generics and Milner's type inference system are 
examples of statically checked (typed) polymorphism.  This form can be
accomplished at compile time and offers strong type checking.  Dynamic 
typechecking, which I often refer to as arbitrary polymorphism, is a more
powerful form and usually cannot be accomplished at compile time.  
Traditionally, Strachy defined two forms of polymorphism.  The first is 
ad hoc polymorphism, or operator overloading, where the same function 
name can refer to several distinct subprograms and the parameter
type structure is used to select the correct piece of code.  The second
is parametric polymorphism, (sometimes universal polymorphism contains this 
category), which refers to subroutines which can acept several distinct 
parameter type structures.  Several texts describe polymorphism, such 
Principles of Programming Languages, by Tennet.

Bob Hathaway
rjh@purdue.edu