Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!fs1!ee.ubc.ca!mikeb
From: mikeb@ee.ubc.ca (Mike Bolotski)
Newsgroups: comp.lang.misc
Subject: Re: The Universal Language (Was Re: Efficient Fortran)
Message-ID: <1990Aug7.035707@ee.ubc.ca>
Date: 7 Aug 90 10:57:07 GMT
References: <23893@megaron.cs.arizona.edu> <1356@fs1.ee.ubc.ca> <1990Aug7.020234.13032@cbnewsc.att.com>
Sender: root@fs1.ee.ubc.ca
Reply-To: mikeb@salmon.ee.ubc.ca
Organization: Dept of EE, University of British Columbia
Lines: 95

In article <1990Aug7.020234.13032@cbnewsc.att.com>, lgm@cbnewsc.att.com
(lawrence.g.mayka) writes:
> In article <1356@fs1.ee.ubc.ca> mikeb@coho.ee.ubc.ca (Mike Bolotski)
writes:
> >
> >This is a cop-out.  If the language is defined to be English, then
all
> >currently existing languages are only sublanguages in a common
framework.
> >A language with a sufficient amount of sufficiently different
"sublanguages"
> >cannot be said to be a language.  
> 
> The previous two sentences are self-contradictory.  English indeed
> includes myriad sublanguages for any and every specialty, yet is most
> certainly "said to be a language."  (Consider, especially, *spoken*
> English, which by necessity includes even highly technical notations
> of all kinds.)
> 
> Your objection about the "sufficient differences" between
sublanguages
> is a matter of degree, not of kind.  Would you be more inclined to

There are several points to be addressed in the above.  

1.  Human language vs. Programming language.

    I should've said "all existing programming languages".   English
    is most certainly a human language; it is not a programming
language
    until the natural language understanding folks solve quite a few
    problems in their field.

2.  The sufficiency of English for "any and every specialty".

    English (or any human language) is certainly close to optimal
    as a programming language for most tasks.  I still would not say
    for _every_ task.   I mentioned two counter examples earlier:
    circuit diagrams and mathematics.  When two engineers discuss 
    a circuit design they typically both look at a diagram.  If 
    you've ever attempted to discuss a circuit over a phone, you'll
    understand the frustration at the inadequacy of English.

    A similar argument goes for mathematics:  droning a list of
    symbols is an extraordinarily inefficient way to discuss an
equation,
    and most people require a visual representation.


> But perhaps the programming-language equivalent of a universal syntax
> is
> 
> (OPERATOR OPERAND OPERAND ...)

I've noted your bias toward LISP before :-).  And I'm aware that
LISP is the programming language of choice when both representing 
circuit diagrams and performing symbolic mathematics.  Still,
this is the internal representation and not the preferred method
of programming, if you define programming as giving instructions
to a computer.


LISP ASIDE FOLLOWS:
-------------------
As far as LISP goes, my bias is that it is wonderful for tasks that
require the functional viewpoint, but horrible at tasks that 
require object-oriented thinking.

I've recently implemented a technology mapper in CLOS.  The pattern
matching, tree-traversing, and branch/bound search were an absolute
joy to write.  But the second stage that dealt with representing
gates  as object was extraordinarily clumsy in CLOS. Maybe this is
the fault of CLOS instead of LISP, since from what I've seen of
Flavors it is much more natural.

RANDOM ASIDE FOLLOWS:
---------------------

On the topic of choosing the right programming language for a subtask
and interfacing them.  A friend of mine works for a local telecom
company.  His group just finished a package that uses Prolog for
database management and queries,  C++-based Interviews for
user-interface,
lex/yacc for various parsing tasks, and Eiffel for something that I'd
rather not know about.   The coordination in this case was via
standalone programs and sockets, but it sure would be nice to mix
and match languages at some intermediate level between object code
and processes. 


--
Mike Bolotski           VLSI Laboratory, Department of Electrical
Engineering
mikeb@salmon.ee.ubc.ca  University of British Columbia, Vancouver,
Canada