Conference turris::languages

Whether a language is advanced is independent of any quality of "highness."
better, altitude.
A language is low-level to the degree that it depends on the specific nature
of the hardware on which its programs are executed.  Microcode for the 780
can be run only on the 780 hardware, no other VAX; therefore, Microcode is
a low-level language, certainly the lowest level language.  

VAX machine-code (forget Macro11 compatibility) may be run on any VAX
(see the sales brochure :-) ) , so it is a pretty low-level language, because
it DEFINES the VAX programming Architecture.  Machine Code Defines the
programming architecture of a machine.  

Assemblers translate mnemonics with a  one-to-one correspondance to
machine instructions, using some directives to improve programmer
efficiency, so Assembler language is a representative form of machine
code, making it dependent on the machine programming architecture, and
a very low-level language.  VAX Macro can't be run on Apple 2E or
Cray I's, only on VAXes.  It is dependent on the hardware machine.

BASIC, FORTRAN, ADA, APL, LISP, PL/I, COBOL, PASCAL, C, PROLOG and others
are all equally high-level languages.  This is true because the all have
equal potential for portability, and fail the pjortability test only becuase
of choices made by the compiler-writing teams.  However, these languages differ
in their use of advanced concepts of programming efficiency and 
applications pertinence.

Tom

Although this definition is harder to quantify, I think it's more accurate
and useful than machine-dependence:

	Language A is "higher-level" than language B if language A allows
	you to express your application in a more concise and problem-
	specific way.  This necessarily means that you can only usefully
	compare the "altitude" of languages in specific problem areas.

So, for example, if you're talking about string processing, SNOBOL is
probably the highest-level language around.  If you're talking about
numerical processing, FORTRAN (blech!) is probably it (maybe APL).
If you're talking simple accounting or financial modelling, Lotus 1-2-3.

The September (?) issue of Scientific American, devoted to software,
had an interesting article on languages by Alan Kay.  He had a chart, with
time on one axis and "altitude" on the other.  "Altitude" was divided into
names like low-level, medium-level, high-level, very-high-level, and ultra-
high-level (if memory serves).  I found his placement of VisiCalc in
the ultra-high-level both amusing and appropriate.  Also amusing and
appropriate was LISP's appearance in several categories (the only language
to span categories).

Re .0:

There is a problem with the "counting symbols" definition.  Not all of
the text of a program in many HLL's is contributing towards the simple
goal of expressing an algorithm to a machine.  Consider the person who
has a Cobol program with large identification and environment divisions,
and who has code with statements like ADD A TO B GIVING C.  The extra
symbols beyond the assembly language version are spent to communicate with:

1.  The next programmer who comes along and has to maintain the program.

2.  Other humans (particularly their bosses who can't program, according to
the original conception of Cobol).

Another example of this is the extra space used in most HLL's for
declarations.  In languages with strong typing, the programmer is
embedding assertions about how the data structures are to be used
(so the compiler can add value to the compilation process by verifying
these assertions).  The emphasis shifts from just allocating storage.

And the absence of declarations doesn't always mean the same thing.  For
instance, compare a missing declaration in SETL with Fortran or C.  The
SETL compiler just generates slower code, and checks the type of the
variable at runtime.  The Fortran and C compilers just flip a coin about
what you meant, and if there is a type mismatch, you'll know when you
program produces wrong answers.

As far as the advertisement for C is concerned, I am not as devastated
by the increase in raw power of a[i][j]++ over A(I,J):=A(I,J)+1, nor is
the average piece of C code likely to be as portable as he thinks.

Re .1:

Consider the pedagogical assembly languages MIX or SAMOS.  No doubt they
have been implemented on many computers.  Does that make them as high-level
as the other languages named?  For that matter, the machine language for
PDP-11's and 8080's are implemented on other computers.  Does this make
8080 assembler just as high-level as Prolog?  Equating portability with
altitude requires this, yet it is an absurd result.

By the way, if you look at those things which cause portability problems
for a particular language, you will find that the harder problems to avoid
are those which are left unspecified (for the implementor to guess about).
It is pretty easy to avoid getting stuck on a particular implementation by
avoiding all extensions.  But writing code which will work no matter how
big an integer is, especially when there is only one kind, is much harder.

Re .2:

It will be interesting to see whether the rough labels on languages
undergo inflation over time.  "Minicomputer" and "mainframe" are relative
terms.  Will people ever get so sick over "(very)**n high level languages"
that they start to change what the terms "low" and "high" mean?  Or will
the people who use terms like "Nth generation language" win out?
				/AHM

So what makes Fortran a better numerical language than Ada?  It hasn't got
half the expressive capabilities.   Its just a lot older.

/Bevin

PS: For those of you who want proof, express the following Ada concepts in
Fortran....


1.	type FLT is digits 8 range 0.0 .. 1_000_000.0;

2.	generic
		type F is digits range <>;	-- any floating point type
		type A is array(INTEGER range <>, INTEGER range <>) of F;

I used FORTRAN as an example, rather than ADA, because:

	1) I'm not very familiar with ADA
	2) FORTRAN compilers generally (please, no flames from ADA
	   implementors!) produce better numerical code than compilers
	   for other languages
	3) Numerical stuff is about the only thing FORTRAN is good for

Remember, I was making a broad general statement.  Just because MACLISP
produces code almost as fast as FORTRAN for numerical stuff doesn't
mean we should run off and rewrite SPICE in LISP.

While FORTRAN doesn't provide the equivalent floating point declaration
(I don't understand the rest), that capability is only sufficient for some
algorithms if the results are confined exactly to that range, including all
intermediate results.  If this isn't true, then the underlying constraints
must be determined.  If this is true, then the code efficiency must be terrible.

Numerical algorithms have been developed which deal with ranges of values
like 2**58 to 2**-57, 0, -(2**-56) to -(2**58).  {This is DEC's implementation;
uniform accuracy, varying precision, and discontinuity about zero.  Others use
varying accuracy and varying precision and no discontinuity.}

To bring this back to high vs low level.

The ideal high level language for numerical algorithms would allow the option
of selecting a specified uniform accuracy or a specified uniform precision with
no discontinuities over a specified range.  Either the compiler would analyze
the code and generate the appropriate efficient code with corrections or the
hardware would be designed to offer this capability with the same performance
as if these constraints hadn't been applied.

Reality strikes.  Neither the hardware nor the code generation capability exists
to accomplish this.  Furthermore, it is possible to achieve the results desired
by explicitly correcting for the total system (the hardware, compiler, and math
RTL) only where appropriate or needed.  The advantage to this approach is
performance.  The disadvantage is that it is much more difficult to implment.

However, while the high level approach isn't yet feasible and may never be, the
middle level approach is much lower in cost than the low level approach.  The
low level approach would be to write the system entirely in a language that
gave complete control over each and every calculation.  Probably an assembly
language or perhaps BLISS.  The disadvantage is that even the calculations
that don't need special attention require that you give them the much the
attention as those that do.

Re .6:

"The ideal high level language for numerical algorithms would allow the option
of selecting a specified uniform accuracy or a specified uniform precision with
no discontinuities over a specified range"

Well, then Ada's your language! Here today!

consider the declaration:

	type MY_TYPE is range -1_000_000.00 .. 1_000_000.00 delta 0.01;

this has all of the properties you desire! And, its exact, as internally its
implemented as an integer type, scaled as required. (however, this could limit
the range of numbers to those specified in 32 bits ... at least at present
with the VAX Ada compiler, as I understand it). And, this implementation
(as integers) is MORE efficient then using the hardware floating point!
(I make the assumption here that the basic integer operations take less
CPU time than the corrosponding floating point operations).

re: .-1

Sorry, thats

	type MY_TYPE is delta 0.01 range -1_000_000.00 .. 1_000_000.00;

BLISS has the interesting feature that you have some control over how
high-or-low a level you to code at.

For example, you can use the CH$-string functions to perform your
character manipulation (and allow the compiler to decide what code to
generate) or you can use the built-in functions (CMPC, SPANC, etc)
to explicitly determine the instruction sequence.

This is especially true in BLISS-36, where by using the MACHOP built-in,
you can start coding in assembler language at any point in your Bliss code.

Using XPORT (memory management, I\O, string-functions, and all of it
transportable), you can write you application in a high-level language,
and later on refine it by replacing XPORT with RMS, RTL (etc) calls.

mark

Re: .7
	Well, then COBOL's your language!  Here 16 years ago!
	Or..., Here 5 years ago! (VAX-11 Cobol).

P.S.  Happy anniversary, VAX Cobol.

What 'level' is 'high' in a high-level language?

I believe that high-level languages are those in which a high level of 
information is available to the reader of the source code.  Thus, the 
progression from low-level to high-level language might look like this:

		0001000000000001

		070001

		MOV R0,R1

		  .

                  .


                POST VISITOR_TOTAL ON SCOREBOARD

I'm glad you didn't go through the intermediate language of HEX-11.
				/AHM

PL/I allows you to specify the precision in terms of binary and decimal
"digits", instead of range.  This is much more efficient because it doesn't
have to produce in-line code for range checks like ada.

And PL/I has been around for nearly 20 years.....

	db

The next four replies come from the USENET (net.lang).

Jack

Path: decwrl!decvax!genrad!mit-eddie!godot!harvard!seismo!mcvax!vu44!jack
Subject: Re: High-levelity
Posted: Tue Jan  1 13:33:12 1985

The problem with all definitions given for 'high-levelness' is that
they use unmeasurable variables.
Besides that, it is probably impossible (and also not very interesting)
to compare two languages that have a completely different target,
for instance, COBOL and APL.
If you define 'high-levelness' as a function of the application
you want, how about this definition:

The degree of high-levelness of a language X for a problem Y is
defined as the size of the biggest subset of a set of programmers
who come up with the same solution, divided by the size of the
base set.

Or, in normal english, if you want to check how good COBOL is for
inverting matrices, you find yourself 100 COBOL programmers,
and tell them to write a program to invert a matrix, and
compare the results. You then divide the programmers into sub-sets
that used essentially the same algorithm (yes, I know, this is the
tricky part), count them, and the number of programmers in the biggest
set (divided by hundred) is a measure for the usefulness of COBOL
for inverting matrices.

After this, we could have even more fun, by asking 100 BASIC programmers
to write an operating system, 100 APL programmers to write a LISP
interpreter, 100 LISP programmers to write an APL interpreter, etc etc etc.
-- 
	Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack
	or				       ...!vu44!htsa!jack
If *this* is my opinion, I wasn't sober at the time.

Newsgroups: net.lang
Path: decwrl!decvax!genrad!mit-eddie!godot!harvard!macrakis
Subject: Definition of `high level'
Posted: Wed Jan  2 18:44:56 1985

	The Nature of a Definition

There seems to be some confusion between `definition' and `measurement'.
Chambers' original proposal tries hard to be operational, that is, susceptible
to measurement:

> X [is] "higher-level" than Y if it is generally possible to express concepts
> (data structures, operations, flow of control, etc.) in fewer symbols in
> X than in Y.	-- [email protected] (John Chambers)
	(and of course the X and Y give us that warm mathematical-definition
	 feeling in our guts)

I would rather try to clarify my intuition first.  I don't see that setting up
a numerical measure helps me.  Thus, my definition was:

>   A high-level language expresses high-level concepts WELL.
>	-- Macrakis@Harvard

...and I asked if we could all agree on this.

Diamond returns to the operational approach, but one which doesn't let you
crank out numbers:

> If it is easier to translate between the problem being solved and a program
> in language X, than between the problem and a program in language Y, then
> X is higher-level than Y.  --  [email protected] (Norman Diamond)

Chambers now retorts that no one else has presented a `definition':

> Hey, c'mon fellas!  I mean, it's fun to read criticism and take pot
> shots at the pots shots, but where's your definition?  I admitted at
> the start that mine was limited.  Let's hear some better ones.
>	-- [email protected] (John Chambers)

Now Jansen accuses even Chambers of being negligent:

> The problem with all definitions given for 'high-levelness' is that
> they use unmeasurable variables. -- [email protected] (Jack Jansen)

... and proposes a survey procedure:

> The degree of high-levelness of a language X for a problem Y is
> defined as the [proportional] size of the biggest subset of a set of
> programmers who come up with the same solution....

Why this emphasis on numbers?  Will it make us wiser to discover that
Algol-68 has a Jansen matrix-inversion score of 23.12% or that Teco has
a Chambers palindrome-search score of 5.04?

	Shall we Discuss Definitions?

So let me propose that we separate the issues of definition and
measurement, and continue our interesting discussion at the level of
definition.  Perhaps it will eventually be productive to reduce the
definition to some empirical measure, but I don't see how that helps at
this stage.  Thus, I would rephrase Chambers' definition as:

	HLLs* induce short programs.			*high-level languages

  ( "within their domain and in competent hands" for all these definitions )

Diamond's comes out as:

	HLLs make programming easier.

Frank's first note discusses many aspects of the quality of a language
and the motivations of designers, so I will consider his comments to be
outside the scope of `definition of high level'.  His second suggests
the definition (although he doesn't push it):

	HLLs induce provable programs.

Jansen's is:

	HLLs induce unique mappings from problems to programs.

My definition remains

	HLLs express high-level concepts well.

I'll agree that of these definitions, mine is perhaps the vaguest (as I
discussed in my note), but I'll also argue that it leaves room for improvement
by increasing its precision.  Terseness, ease of use, and provability can
all be desirable traits, but none seems directly linked to high level (there
are certainly other dimensions of description of languages besides level, and
many of them contribute to quality).

Jansen's notion of uniqueness is intriguing, and seems to relate to
certain ideas of Dijkstra's about program development.  I would call it
`closeness' or `directness' to an application area, and this indeed may
be an important component of high level.  The other side of the coin is
that this very directness may be simply narrowness.  Is it really 
`high-level' to encourage to the point of enforcement the representation
of graphs as adjacency matrices in APL, for instance?

Now, some others' ideas about the nature of high-level languages...?

	-s

Newsgroups: net.lang
Path: decwrl!decvax!genrad!mit-eddie!godot!harvard!seismo!uwvax!gumby!g-frank
Subject: high-level-headedness
Posted: Thu Jan  3 21:26:42 1985

>   A high-level language expresses high-level concepts WELL.
>	-- Macrakis@Harvard

My knee-jerk reaction is to agree.  On reflection, however, I have two
questions:

  1) Which is more important to this definition:  expressiveness, or
     the level of the concepts expressed?

  2) Are we going to have an easier time defining high-level concepts
     than we did defining a high-level language?

A virtuous man is filled with virtue, I suppose, but definitions of this
sort leave us in doubt as to the value of his qualities.

Can we take a different approach and suggest, as I once did in a rather
fuzzy way, that the first purpose of a language is to communicate, and
that all the features of the elephant we've been blindly describing may
be different aspects of effective communication of ideas and purpose? 

Newsgroups: net.lang
Path: decwrl!decvax!mit-athena!jc
Subject: Re: High-levelity
Posted: Fri Jan  4 12:17:10 1985


> The degree of high-levelness of a language X for a problem Y is
> defined as the size of the biggest subset of a set of programmers
> who come up with the same solution, divided by the size of the
> base set.
> 
> 	Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack

This is one of the more enticing suggestions I've seen so far.  But 
it needs a little work, as there is one important qualification to
this approach.  There are some problems that have more than one real
solution.

A classical mathematical example is the high-school textbook proofs
that the base angles of an isosceles triangle are equal.  There are
two equally "fundamental" but different proofs.  One starts with
dropping a perpendicular from the apex to the opposite side, and
proving that the two resulting triangles are isomorphic (and right).
The other consists of showing that the original triangle is isomorphic
with its mirror image.  Both proofs end up with the angles in question
being the corresponding angles of isomorphic triangles, but two very
different triangles are used.

This would be considered by most mathematicians not a sign of the
weakness of Euclidean geometry, but rather of the power of the notation
used to express it.  Both proofs are simple and elegant; they are
not variants of a single underlying proof.  The language can handle
both with equal ease.

Similarly, in the world of programming, we have examples like sorting.
Suppose your programmers were asked to write a routine to sort a list
(or array) in memory (or other random-access storage).  Given no other
constraints (such as knowing how the data is likely to be ordered before
the sort is started), there are several algorithms that are fundamentally
different from each other.  Two of the best known are "quicksort" and
"bubblesort".  They are both very simple, and do their work in very
different ways.  There is no way of saying which is "best".  If the
list is short or starts out close to sorted, the bubblesort is better.
For a large random list, bubblesort is atrociously slow, and quicksort 
is about the best known.  A language that is "high-level" for sorting
would express both elegantly.  (It might also have an elegant way of
expressing the best and worst cases for each.)

I think that this definition does have its appeal.  Most of the 
extant sort algorithms can be expressed succinctly in some languages,
and not in others.  Thus, quicksort can be expressed simply and elegantly
only in languages that support recursion.  Without recursive functions,
you have to fake the recursion with a visible stack.  The code to do
the stack manipulations swamps the code for the elegant sort algorithm,
making a messy routine which is difficult to comprehend without much
study.  On the other hand, bubblesort is somewhat awkward (though not
very much so) in a language that has only recursive functions and no
explicit looping function.  

A language that has the power to express known sort algorithms probably
is required to have both recursion and a simple looping construct.
Sorting is a good example for another reason: A "practical" 
implementation of a sort algorithm is only possible if the language 
allows a comparison test routine to be provided as a parameter.
This immediately excludes most current programming languages (except 
for Lisp, C, Forth, Prolog, Snobol4, and a few others).  Note that
this is easy to express in most assembly languages (though the sort
algorithms are not).

I might also point out that there are several non-equivalent ways
to invert a matrix.  Can your language express all of them elegantly?
If not, it's not a "high-level mathematical" language.

By the way, I find myself trying to type "high-levility" rather than
"high-levelity"; I notice that others say "high-levelness".  Do we
have any votes for "high-levelhood"?  

> Some other definitions:
> 
> 1. X is "higher-level" than Y if it has fewer detractors among professors
> 	of computer science.
> 
> 2. X is "higher-level" than Y if fewer people believe it should be
> 	stamped out.
> 
> 3. X is "higher-level" than Y if it was invented as a substitute for Y.
 
Great!  I love all of them!  (Except that #3 has an obvious exception:
Basic was invented as a substitute for Fortran, Algol, and all those
other academic playthings.  Surely you don't mean to suggest that Basic
is a high-level language!? :-)

				John Chambers

Sorry Dave,  in Ada you can also say


	type FLT is digits 6;


So PL/I is not unique in this.   You can also THEN say

	subtype CHECK_RANGE_IS_ENOUGH is FLT range -1_000_000.0 .. 1_000_000.0; 

and thereby verify that you aren't going to run into range problems, as
well as documenting what the required range is.

/Bevin

re .18

gag, not a bubble sort.  always use an insertion sort !

see knuth, searching and sorting

sorry, but i learned the hard way about sorting and when i finally got
knuth's book, i read it with a passion.  never, never, use a bubble sort
as a language example.  use an insertion sort.