Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!allegra!alice!pereira-x.research.att.com!user
From: pereira@research.att.com (Fernando Pereira)
Subject: Re: Language ecology (was: Is Visual Prolog "real" Prolog?)
X-Nntp-Posting-Host: pereira-x.research.att.com
Message-ID: <pereira-2105962033380001@pereira-x.research.att.com>
Sender: usenet@research.att.com (netnews <9149-80593> 0112740)
Organization: AT&T Research
References: <317752DA.C2C@pdc.dk> <andrews.830314122@Turing.Stanford.EDU> <4m4ard$knq@goanna.cs.rmit.edu.au> <4mda7n$7mk@mod-serv.dfki.uni-sb.de> <4mn8jk$pje@mulga.cs.mu.OZ.AU> <pereira-0805962321250001@greeley.research.att.com> <4nilp3$qd5@orion.cybercom.net> <4nj74a$jta@soap.news.pipex.net> <pereira-1805962140010001@pereira-x.research.att.com> <4nqqm4$k73@orion.cybercom.net>
Date: Tue, 21 May 1996 19:33:38 GMT
Lines: 53

In article <4nqqm4$k73@orion.cybercom.net>, dennis@amzi.com wrote:
> [...]
> >The reason I go over this seemingly trivial example is that it actually
> >illustrates the point I was was making originally and Dennis Merritt
> >disagreed with.
> 
> My intention wasn't actually to disagree, but rather to present some
> ideas on why programmers don't, in general, gravitate to higher-level
> languages, based on having wrestled with these issues from the vendor
> side of the business for a number of years.  It has been my experience
> that users often get confused and frustrated with products that seem
> intuitive and easy-to-use to individuals working for the vendor.
> [... interesting discussion of the difficulties programmers have
>  with declarative tools such as 4GLs and NL DB interfaces]
I particularly liked the NL DB interface example, since I worked in the
area (not commercially) and also noticed the mismatch between the original
claims ("NL makes it easier") and reality. But with hindsight this should
not have been surprising. Crafting a complex specification in English, or
a complex program in a declarative language, is a difficult, skilled task
very different from day-to-day programming. It has been often observed
that good English majors make better specification writers than good
engineering majors. Only a minority who has the inclination, training and
time is able to bridge the gap comfortably between specifications and
execution, whether for programming in a declarative language or for
designing an imperative program from a declarative specification. This is
precisely the ecological factor that I was discussing. Traditionally,
programming selected for people capable of mentally orchestrating complex
sequences of events and their interactions, not for specification crafters
(those typically went to law school ;-)). Thus, languages that favor the
latter will find poor soil in the former, who are the majority of the
programming profession. The two ways of thinking come together in
mathematics, although the marriage has never been perfect, viz the fights
between "dynamic" and "static" views of infinity and limits that go back
to the conflicting Newtonian and Leibnizian views of the calculus if not
to the classical world.
Thus some mathematically-inclined people find it relatively easy to jump
between declarative and imperative views of a problem. However, it is
presumptuous to suppose that this what "real world" programming is like. 

In addition to the examples we have been discussing, I encourage anyone to
look at the Microsoft Active VRML language for another instance. It is in
my opinion a very elegant functional language based on ideas from Lucid,
Concurrent ML and others to specify combinations of complex behaviors
(space-time extents in virtual space) without unnecessary explicit
mentions of time or synchronization. However, I suspect that it will have
a hard time being adopted compared with more conventional VR scripting
languages because the relationship between an algebraic specification  of
a dynamical system and the synchronizations and numerical integrations
that implement it as a concrete behavior on a machine could be far two
remote for the practitioner. This is not a criticism of practitioners, by
the way, but rather a reflection on what skills and inclinations have been
selected for in the development of the programming profession (hence the
fights between "systems engineers" and "coders," too).
