🚀 go-pugleaf

In article <23893@megaron.cs.arizona.edu>, gudeman@cs.arizona.edu (David Gudeman) writes:
> Only ridiculous if you have a limited imagination.  It is perfectly
> plausible that it is possible to design a ``universal'' language of
> some sort, that makes it unnecessary to use other languages.  Such a

This is an interesting claim.  Of course, it is difficult to dispute
statements that begin with "it is plausible", but I will attempt to do so.

For one, I haven't seen any supporting arguments for the possibility
existence of the universal language (handwaving excluded).

Here is a counterargument.  Workers in different fields solve problems
using entirely different languages.  Mathematics is one such language,
and it includes many "sublanguages" -- continuous variable notation,
matrix notation, logic, etc.   Circuit diagrams are another language.
English, with terms specialized to each area,  is another language, used 
almost exclusively in non-technical fields.

A "universal" programming language is in a sense equivalent to the claim
that a single language is appropriate for all areas of study.  

> language will probably not be small, and it may be divided into many
> sublanguages, each appropriate for different problems, but there could
> be a unifying framework and user interface.  In fact a lot of current

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.  

> research is going into the search for such a language, although the
> researchers don't generally think of their work in this way.

I should hope that the researchers don't think of their work that way.
They would probably change research areas.  By the way, whose work
do you consider falling into this category?

> for your problem.  To suggest that the issue has been decided is a
> little premature to say the least.

These days, the suggestion that any issue has been decided is premature.
One can point to the various speed levels  that were "proven" to be
non-exceedable by humans, for example

On the other hand, the excuse of "this hasn't been decided yet" gets
vacuous rather rapidly without any supported counterarguments.
 
--
Mike Bolotski           VLSI Laboratory, Department of Electrical Engineering
mikeb@salmon.ee.ubc.ca  University of British Columbia, Vancouver, Canada 


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

In article <1356@fs1.ee.ubc.ca> mikeb@coho.ee.ubc.ca (Mike Bolotski) writes:
>In article <23893@megaron.cs.arizona.edu>, gudeman@cs.arizona.edu (David Gudeman) writes:
>> language will probably not be small, and it may be divided into many
>> sublanguages, each appropriate for different problems, but there could
>> be a unifying framework and user interface.  In fact a lot of current
>
>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
consider English a unified language if its grammatical structure and
vocabulary extension were more regular?  Perhaps Esperanto would meet
your requirements. 1/2 :-)

But perhaps the programming-language equivalent of a universal syntax
is

(OPERATOR OPERAND OPERAND ...)


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.

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 

I always thought that The Universal Language was PL/1. After all it did
combine the needs of the commercial programmer (Cobol features) with the
needs of the scientific programmer (algebraic expressions, matrices), thus
meeting everyones needs.

Or maybe the Universal Language is Ada, since it also is an Osterizer language.

I got it now. It must be C, or rather C++, because you can write *everything* 
in these, and they are *popular*.

:-) on the above. There could no more be a Universal Language than a Universal
Religion or a Universal Screwdriver. As long as people and projects differ
there will never be a Universal Language.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply

First, a comment on the "Efficient Fortran" thread that led to this discussion: 

It is true that you shouldn't *have* to resort to the inner workings of the
computer, such as the format of real numbers, but sometimes you do, and when
that happens, you shouldn't have to "fight the system" to do simple things like
play with bits in words, simply because the designers held the view that bit
twiddling is fundamentally evil and, besides, they'd put everything into the
language any reasonable programmer could ask for. There are some classes of
problems that need a spot of machine-level fiddling in an otherwise HLL; my
view is that the language should hope to reduce its frequency, but allow it
(albeit with warning bells). Now on with the new topic...

In article <23893@megaron.cs.arizona.edu>, gudeman@cs.arizona.edu (David Gudeman) writes:
> ... possible to design a ``universal'' language of some sort, that makes it 
> unnecessary to use other languages.  
 
In article <1356@fs1.ee.ubc.ca>, mikeb@coho.ee.ubc.ca (Mike Bolotski) writes:
> Here is a counterargument.  Workers in different fields solve problems
> using entirely different languages.  Mathematics is one such language,
> and it includes many "sublanguages" -- continuous variable notation,
> matrix notation, logic, etc.   Circuit diagrams are another language.
> English, with terms specialized to each area,  is another language, used 
> almost exclusively in non-technical fields.
> 
> A "universal" programming language is in a sense equivalent to the claim
> that a single language is appropriate for all areas of study.  
> 
There is a difference between proving a very general-purpose language that
people can use (if they like) for anything, and that one language is most
appropriate for everything (and therefore ought to be used for everything).
There are two good reasons for try to at least *approximate* a universal
language:

 (a) Organisations have difficulties managing projects that use what ever
language is "flavour of the month", e.g. being left over with old software
written in "PLAN", but not having any programmers skilled in the language in X
years time. Even if the whole organisation standardises on one language for all
time, they will have difficulty in finding new programmers, software updates,
etc sooner or later.

 (b) Programmers often have to program with a language not perfectly suited to
a particular job, for practical reasons (e.g. the organisation standardised on
COBOL ten years ago, and isn't about to change simply because one programmer
wants to write a word processor!). More often, it is simply habit - better the
devil you know. Since this sort of thing happens anyway, it would be nice if
the language was flexible - as a universal language would have to be.

But consider a user of something like a Unix command shell, that has set up
lots of aliases for him/herself to do the things that are most often required.
In effect, they are using their own language. Now, if they are sick for a week
and someone else has to use their machine (someone used to their own set of
aliases), then there are problems - either they abandon all the command alises
and use "pure" csh or whatever, or try to understand the previous person's
language. If the tasks to be performed are fairly complex, say special file
update and backup procedures, then they will probably need to understand what
was happenning before for the system to keep functioning. They may even adapt
them with components from their own "language" if they will be working at the
job long enough. 

Think of the manager of such a system; would you enforce everyone to use the
same set of aliases (or no aliases at all)?  Some people like to have 2-letter
abbreviations for the commands they use often. For a beginner this is terrible,
but after a while it is ergonomic. This is not the sort of issue that people
can come down with hard and fast decisions like "never use aliases" or "always
use the shortest abbreviations even if it means beginners suffer for a few
weeks". Of course, the same arguements apply to conventional programming
languages: people are going to want different languages in different
situations, and there are going to be hassels because of this. So don't expect
a "universal programming language" to be *universally applied*. 

This isn't to mean one shouldn't be available, and doesn't mean one can't be
produced. A language I and some other folks down here in NZ are working on,
called NGL (part of eNGLish, and Nth Generation Language), attempts to be a
universal language, by being dynamically redefinable. Further explanation:

(1) Consider again the person with a set of important aliases on a system, away 
 for a while. Suppose that a command, called "weekly_update" was defined in 
 terms of "pure" commands and a handful of other aliases (which, in turn, may
 be defined in terms of other aliases). Suppose you could see the weekly_update
 command file expanded in "pure" commands only. So you only need to know the
 standard language (csh or whatever, in this case), and your own "dialect" of
 it, never other people's. This is something that is easy to understand and
 implement. If you define a "macro" (or whatever name you want to give it) in
 terms of other macros you have defined, you could see the macro listed in
 either pure language components or your other macros (still easy to imagine,
 but a wee bit more tricky to program). Now suppose you can see anyone else's
 macros in terms of your macros. If they define another word for exactly the 
 same command or sequence of commands you have, you see your name for it.

(2) Think back to some versions of BASIC that convert the external source into
 some form of internal p-codes. Data General's Business BASIC is a very good
 example; it converts expressions into RPN, for example. When you list the
 program, you see what you typed in (reformatted nicer, perhaps). But you
 don't need to convert assignments into "LET ... = ..." you could just as
 easily list it in a form like "... := ...;" a la Pascal, or C, or COBOL or
 anything. The same with different "FOR" statement structures - you could see
 the p-codes in just about any language (if the language doesn't have an
 appropriate construct, you could list it as more fundamental operations).
 You could have a team of programmers working on a project using a variety of
 languages (really, all NGL in disguise) and each seeing the whole in their own
 favourite language. 

(3) Imagine a person talking to the computer via a voice recognition unit. In
 all probability, a much wider range of language will be used than when typing
 commands, and English being what it is, the best way to handle that is to let
 the command processor learn as it goes. What has that got to do with the NGL
 programming language? Not a lot at the moment, but that seems to be a logical
 (if distant) progression. 

So, this takes care of the language used in communicating needs to the
computer, but there is obviously more to discuss. Feel free to e-mail me.
What I hope to have explained is that something like a "universal" language is
feasible (sorry to use that word again), but we really need to talk about a 
flexible language, one where you can choose detail or general instructions to
teh system, and then within that, choose the wording and syntax that is most
convenient for you.

Mark Aitchison, University of Canterbury, NZ.