Re: Questions for a language designer

[Michael Vanier <address@hidden>]

There's another way of looking at this question.  Languages that have a
single underlying metaphor can be problematic because they force all
programs to be expressed in terms of that metaphor.  It's like the old
saying that when all you have is a hammer, everything looks like a nail
(thumb?).  So, although I greatly admire many single-paradigm languages
(smalltalk, haskell, prolog, etc.) I don't like the feeling that I *have*
to express everything in terms of that paradigm (e.g. objects, functions,
logical relations).  One reason for the proliferation of languages is that
different paradigms are suitable for different programs; some are most
naturally expressed in terms of objects, some in terms of functional
abstractions, some in terms of logical relations, etc.

Trying to fit all programs into one paradigm makes for unwieldy code.  The
designers of C++ and perl knew this, and their solution was to explicitly
put in support for the major paradigms as they saw them.  Lisp took a
different approach; the lisp abstractions are sufficiently basic (lambda
calculus, code as data) so that they can serve as a kind of meta-paradigm
in which the other paradigms can be fairly easily expressed.  This appeals
more to me, but there is still room for improvement; static typing doesn't
fit in very comfortably with the lisp model AFAICT, and neither does the
kind of low-level programming that C/C++ is so good at (and yes, I know
about prescheme in scheme48).  Also, just because you can express a given
paradigm in lisp, it doesn't mean that this will be the most efficient way
of doing this (e.g. implementing prolog in lisp is easy, but not as
efficient as implementing it in C).

Mike

> Date: Thu, 29 May 2003 15:38:02 -0400
> From: Scott McKay <swm@itasoftware.com>
> 
> At 2:36 PM -0400 5/29/03, Michael St . Hippolyte wrote:
> >On 2003.05.27 16:56 Jerry Jackson wrote:
> >>
> >
> >The finest programming is poetry, not prose.  A language has to have
> >an internal harmony and a natural rhythm to be poetic.  Such coherence
> >is never accidental; it must be supplied by the language designer.
> >
> >For the programmer, you want a language with as little friction as
> >possible, where code flows freely and naturally.  Simplicity, symmetry
> >and internal consistency all help.  A little harder to pin down but
> >just as important is a language design that lends itself to conventions
> >and idioms (the secret to C's success).
> >
> >For the reader (tester, maintainer, integrator, student), you want
> >clarity and conciseness -- two properties often at odds with each other.
> >A language which is intuitive, and thereby self-documenting,
> >accomplishes both goals.  It seems to me that the only practical way 
> >to achieve these things is
> >to begin with a unified underlying vision -- a mental model or metaphor
> >rich enough to suggest answers to almost all of the design questions.
> >Best is to have both a model and a metaphor -- a conscious mental model
> >to determine the broad structures and rules, and an intuitive metaphor
> >or style to determine how those structures and rules get translated
> >into concrete symbols and syntax.
> >
> >Of course most language designers do have mental models -- that's often
> >why they design languages in the first place, so that they can talk
> >about their mental models knowing that there's at least one language
> >it makes sense in :)
> >
> 
> Yes, I quite agree.  One reason I find C++ and Perl
> surprising (to use) is that the mental model seems
> incoherent to me.  What is also surprising is that
> their bizarre mental models came from one person!
>