🚀 go-pugleaf

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.