jc@mit-athena.ARPA (John Chambers) (12/26/84)
> ... (really, now, is C much higher level than assembly language?).
(No, but it's a higher-level language than most of its competitors. :-)
Come now, what does it mean to say that language X is "higher-level"
than language Y? We could start a very long debate on this subject.
(Hint, hint....)
I'll throw out a definition for consideration, flaming, etc. I will call
X "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. The definition of "lower-level" is left to the reader.
Note that by this definition only supplies a partial ordering. Two
languages may be so different that, depending on your application,
either may require the smaller number of symbols. I also won't listen
to pickiness. If most examples differ by only 50%, I will consider
them to be the same level. Some pairings, like APL and Prolog, are
simply incommensurable.
This definition sounds intuitively like a useful one, but it sometime
has results that partisans of various languages might find surprising.
For example, Cobol is lower than assembly language. PL/I and Ada tie
with assembly language. Pascal, Fortran and Basic are close, and barely
above assembly language. C comes out somewhat better, beating assembly
language by about a factor of two. Lisp, not surprisingly, comes out a
bit higher, around 3 or 4. APL, Snobol4, Forth, and Prolog and Smalltalk
come out much higher (around 10-20 for certain application areas, but only
in the hands of a programmer that understands them.)
A related observation is that the time it takes me to make a chunk of
code work right is basically limited by how much I can see on a screen
at once. (Yeah, I know about paper; it's about 2 orders of magnitude
slower. Ever try running grep on a listing?) Most terminals in the
real world are 80x24 or so; this is the practical limit to what I can
work on at once. When I get ahold of some of Martillo's nice terminals
(not hard, he's right next door, and I know where the master key is.:-),
I'll be able to work on bigger functions. But anyhow, the amount of code
it takes to express a concept is important. The fewer symbols, the more
I can work on at once in my 2Kbyte window.
I find it interesting and amusing that C, intended originally as a sort
of "structured assembly language" is able to express many concepts in fewer
symbols than its supposedly "high-level" competitors. It's also interesting
and amusing that designing a language for ease of expressing low-level
"hardware" concepts such as pointers, absolute addresses, etc., resulted
in a language that is more portable than languages that were intended to
be portable (but rarely live up to the advertising very well). I suspect
that it's not a fluke. I think language designers should spend less time
flaming about the defects of C (which are many), and spend more time looking
at what makes this language better than most of its competitors for writing
the code it was designed for - operating systems, low-level drivers, etc.
Maybe eventually we might have a really high-level language that does what
C does, but does it a lot better.
Does anyone have another good (or at least interesting :-) definition of
high-level? After all, people have been bandying the term about for years;
it's about time we had a definition so we could really tell which languages
are the advanced ones and which are just pretenders.
John Chambers (Project Athena @ MIT)g-frank@gumby.UUCP (12/28/84)
> I'll throw out a definition for consideration, flaming, etc. I will call > X "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. The definition of "lower-level" is left to the reader. > > I think language designers should spend less time > flaming about the defects of C (which are many), and spend more time looking > at what makes this language better than most of its competitors for writing > the code it was designed for - operating systems, low-level drivers, etc. > Maybe eventually we might have a really high-level language that does what > C does, but does it a lot better. > > Does anyone have another good (or at least interesting :-) definition of > high-level? After all, people have been bandying the term about for years; > it's about time we had a definition so we could really tell which languages > are the advanced ones and which are just pretenders. > > John Chambers (Project Athena @ MIT) Of course, it's all in the eye of the beholder, and the most I can flame at is the focus of the eye, eh? In one sense, any definition is hopeless, given that "high" is a judgement word, like "nice." I find an interesting conflict in John's description. First, he says that it's good to be able to express operations in a minimum of symbols, in which case APL is the highest of the high. Then he says that C is best since it's good for writing operating systems in. Which is it? No on in their right mind would write an operating system in APL (would they?). So the definition is already flawed. I think it's important to look at why programming languages were designed in the first place. Most of the time their designers wanted to be able to express to the computer what they wanted to do in the most clear and natural way possible. They felt that assembly language didn't express their ideas naturally. I suspect that terseness, so beloved of C hackers, was not a major goal. For a while, designers concentrated on special purpose languages for string handling, vector computation, etc. Once again, they wanted a language to model their particular application environment more accurately. They felt (as did the authors of C) that this would lead to higher productivity and maintainability. More recently, language designers have tried to solve software engineering problems, designing languages that reduced coupling between modules, allowed reusability of code, increased readability so that programs could be maintained by people other than their authors, and permitted handling of exceptions in a meaningful way. None of these is particularly well done by C, yet each is considered a "high-level" feature (if you need it, of course; otherwise it's just "baggage"). A programming language may be considered just a means of communicating with a computer, but it should not be forgotten that it is also a means of communicating with other programmers (including the original author, say in three weeks or so). And we still haven't mentioned the issue of provability of correctness!
mccaugh@uiucdcs.UUCP (12/30/84)
Re: the question of hi-levelity--
It seems to me that what eludes us in the way of definition is that we
have yet to define "levelity" itself before we can assess the "hi-ness"
of it...It was my understanding that Bell's classic on Computer Struct-
ures might be a first resort to the problem: if by "level" we mean some
"layer" of abstraction between programmer and bare machine, then per-
haps the lowest-level languages are indeed the assembly languages that
are (except for macros) in 1-to-1 correspondence with the machine's own
language. Alternatively, we might think of "hi-ness" of levels not only
in terms of distance from the physical machine but (since they are lay-
ers of "abstraction") also in terms of what virtual machine does play
host to that language, e.g., the string-oriented machine that one might
have in mind to interpret his Snobol program. That is to say, "height"
of the language level might pertain to the virtual machine instead of
the language, the usefulness of which concept is that then one can be-
gin to think of equating languages level-wise if the virtual host can
interpret them both.
uiucmsl!mccaughjejones@ea.UUCP (12/30/84)
Re high-level = able to express things in fewer symbols: how much of C's advantage over Pascal, etc., would disappear if one behaved as the Algol 6x reports request, and consider BEGIN, END, etc. to be one symbol? i.e. are we counting characters or tokens? James Jones
ndiamond@watdaisy.UUCP (Norman Diamond) (12/31/84)
How's this for a first approximation to a definition of high-levelness:
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. (Notice that this is two-way translation. Those
programmers who are satisfied with write-only languages may alter this for
one-way translation, and define a different term.)
Here are additional thoughts:
If it is easier to translate a problem into a program than it is to translate
the program into machine code, then the language is at least moderately high-
level. (This may give a bonus to write-only languages. Anyone who can fix
this defect, please e-mail.)
If users of a language find their work easier than those who develop and
enhance compilers for it, then the language is at least moderately high-
level.
We could try a direct comparison between total time spent by all application
programmers using a particular compiler, and total time spent by all system
programmers who maintain the compiler. After all, firms develop compilers
when they expect to have a lot of customers, and the customers expect to use
the compiler quite a bit.
So, nearly all present-day languages are still low-level. True.
-- Norman Diamond
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond
CSNET: ndiamond%watdaisy@waterloo.csnet
ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa
"Opinions are those of the keyboard, and do not reflect on me or higher-ups."smh@mit-eddie.UUCP (Steven M. Haflich) (12/31/84)
Norman Diamond (ndiamond@watdaisy.UUCP) defines an ordering function for high-levelness: >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. This is an attractive formulation which directly addresses the expressive `ease' of a language. However, he then continues by jumbling up the language with the hardware on which it runs: >If it is easier to translate a problem into a program than it is to translate >the program into machine code, then the language is at least moderately high- >level. The problem, of course, is that by implication a language's high-levelness is penalized when running on `higher-level hardware'. If someone forges silicon that executes Prolog directly in microcode, without compilation, does that make Prolog low-level? Is C running on a 8086 higher level than when running on a VAX or 68000? Soon more and more hardware will look less and less von Neumann. At least, I hope so! :-)
jc@mit-athena.ARPA (John Chambers) (12/31/84)
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. If Lincoln had said the same things in 10,000 words, would we still remember the Gettysburg Address? Don't be silly! Terseness counts. I liked the comment about provability, perhaps because I can turn it around to support my liking of terseness. I've played around with provability, and one thing that is obvious is that difficulty of proving correctness goes up as a very bad function of the number of tokens. APL one-liners are usually easy to prove correct. Pascal 10-pagers are usually hopeless, even if they do the same thing in the same way. I suspect that C is hopeless in this respect. Or is it? But provability is only loosely related to high-levility. Or is it? John Chambers
g-frank@gumby.UUCP (01/01/85)
> But provability is only loosely related to high-levility. Or is it? > > John Chambers This is the most interesting question I've heard all week. Most of the definitions and discussions submitted so far on "high-levelity" do deal, in one way or another, with the issue of "expressive ease." Whether speaking of ease of translation or natural expressivity, we all mean the same thing. Proof of correctness "works," in my limited experience, because constructs of the pseudo-language in which such proofs are constructed correspond to actions transformable into predicate calculus (does that make sense?). A language allows programs to be proved correct when its constructs are so transformable, and correct programs may be generated in such a language from well-defined specifications. Is there a connection between a "natural deduction system" and the "expressive ease" mentioned above? Yes and no. Certainly such a system has expressive rigour, and little or no ambiguity. Whether such a system is indeed natural has a lot to do with background and training. Is the idea of expressive ease enough to define "high-level?" BASIC programmers will tell you that BASIC is high-level because it's "easy" to write in. I think that the more sophisticated the programmer's ideas and algorithms, the more he or she demands of the language's expressiveness. Does the programmatic calculus approach represent the pinnacle of such expressiveness? One argument for this statement is that correct programs are generated directly from the specifica- tions, and as a result the program "expresses" what it is to do, which is "higher level" than a program that simply expresses how it is to be done.
jack@vu44.UUCP (Jack Jansen) (01/02/85)
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.g-frank@gumby.UUCP (01/03/85)
> 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. > > Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack One of my arguments for the high-levelness of programmatic calculus and related languages was, in fact, that given a precise enough specification (ah, there's the rub), different individuals will tend to come up with very similar code. On the other hand, I've never been a grader in a class on the subject. Can anyone out there verify or make hash of this assertion?
jr@bbncca.ARPA (John Robinson) (01/04/85)
Newsgroups: net.lang
Subject: Re: High-levelity
References: <235@gumby.UUCP> <96@mit-athena.ARPA> <237@gumby.UUCP>
gumby!g-frank's observations about provability vs expressive
consistency vs the predicate calculus reminds me of some observations
Doug Lenat made during a talk last fall. He was reviewing the success
of his PhD work, a program which was able to, given a small set of
axioms about mathematics, discover interesting theorems by use of a
surprisingly small set of hueristics like "look for interesting members
of a set and explore their properties." [I fail to do his entertaining
presentation of the system justice here. Also, I {red-faced} forget
the name - its successor of sorts is EURISKO, a program that reasons
about whatever body of knowledge you choose to innoculate it with. If
you're interested, start searching with the Sep84 Scientific American.]
At any rate, perhaps the most cogent observation about the success of
his program was that it drew a lot of its power from the similarity of
the subject area (mathematics and predicate calculus) to the language
it was programmed in (LISP). In part, this is because one of the ways
it searched for interesting new facts was by "mutation" of the LISP
code itself. But I think the observation is really deeper than that.
So there does seem to be a clustering of the ideas of ability to
{express, prove} things in a language and its {high-levelity, ease of
use}. I think Jack Jansen's observations about precision (how many
different programs will 100 COBOL programmers write?) relate to this as
well - if the language has no straightforward way to express a given
problem, programmers will arrive at any number of different solutions,
most of which lose the original problem expression in the details,
whereas when the language is appropriate to the problem, the usual
solution will just jump out at everyone. I might even venture an
opinion that an expert system done well may be the creation of an even
more closely-targeted formal language that focuses on an even more
limited area of knowledge. (You must stretch the definition of
"language" a bit to account for the interactive nature of these tools).
So the comparisons yield different measures of success of different
languages which depend on the subject area attacked using the language.
Thus, LISP proves to be useful in expressing ideas in the predicate
calculus and mathematics in general, and perhaps the popularity of C
relates to its ability to express what really are machine-oriented
notions (addresses, loops) in a way that is divorced from a particular
machine language, yet almost as precise while including (like Fortran
or Pascal) a standard arithmetic expression notation. Unfortunately,
this also means that the ease of use is intimately tied to the intended
area of application of the language; thus the inevitable differences of
opinion among programmers who work in different environments with
different languages of choice.
/jrjc@mit-athena.ARPA (John Chambers) (01/04/85)
> 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
chuck@dartvax.UUCP (Chuck Simmons) (01/07/85)
> ... >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.) Wouldn't a "high-level" language simply allow you to request that your data structure be sorted without you having to worry about how it got that way? >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. >... >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 In Basic (Dartmouth Basic 6, more or less the original) I would invert a matrix A using the statement: 100 MAT A = INV (A) What could be more high-level?
msb@lsuc.UUCP (Mark Brader) (01/09/85)
> > In Basic...I would > invert a matrix A using the statement: > > 100 MAT A = INV (A) > > What could be more high-level? How about APL (or the last APL I used, anyway)? A gets domino A Where "gets" is a left arrow and "domino" is quad-overstrike-divide-sign. None of these silly MATs or needless function calls. Frivolously, Mark Brader one-time APList
mangoe@umcp-cs.UUCP (Charley Wingate) (01/10/85)
I like the notion that "Higher level languages express higher level
constructs better", and I think the following operational measures allow
some sort of comparison. Consider first what most people would agree is
the very lowest level sort of language: the machine language of an 8-bit
processor. ANY construct has to be provided by the programmer. When one
progresses to, say, Fortran, one finds that a large number of constructs are
now provided; the programmer no longer has to construct them for every
instance.
I therefore propose the following operational test:
Language A is "higher-level" than Language B if, on the average,
the number of machine instructions executed per "unit" of language A
is greater than the same measure for language B.
For the purposes of distinguishing "terseness" from "expression", I choose to
define "unit" as tokens that actually do something. Begin-End constructs
don't count, for instance. One can normalize these comparisons further by
doing all the comparisons on the basis of 8-bit processor instructions; this
will allow us to compare different assembly languages as well as making the
notion of language level independent of the processor.
One can readily see that (for instance) 32016 assembly language is higher
level than z-80 assembly. Fortran is higher level than either, but not by
much. APL and PROLOG are MUCH higher level; of the two, Prolog is probably
higher level. Lisp is intermediate. Note that for specialized languages,
it makes sense to make the comparison on the basis of the type of tasks the
language is designed for; it makes little sense to try to compare APL with
SNOBOL, for instance.
I'm not sure this means anything, in the long run. A number of languages
(PL/M and FORTH, for example) are deliberately low level. To use "level" as
a measure of merit is to misunderstand the purposes of the higher level
languages. Languages like APL, SNOBOL, and Prolog are very high level
because the constructs used are well known, and thus the compiler/interpreter
overhead of translation is acceptable. In comparison, by this measure
languages like PL/I and Pascal are not especially high level. Almost any
common data structure has to be constructed by the user. It is evident
(to me anyway) that people are therefore ranking languages on some other
basis.
Charley Wingate umcp-cs!mangoejack@vu44.UUCP (Jack Jansen) (01/10/85)
Well, let me air a few more thoughts on high-level{ity,ness}:
- A few people said that assembler is higher in level than
machine code. I think that this is *not* true.
Though macro-assemblers and such things may be higher-level
than non-macro-assemblers, I think that bare assembly is
just as low-level as machine code.
For instance, if you compare an 8080 to a 6809, everyone (I hope)
agrees that 6809 machine
code is higher level than 8080 machine code.
Now, it would be ridiculous to make 8080 assembler higher in level
than 6809 machine code (I, for one, would rather write 6809 machine
code than 8080 assembler, but this might very well be caused by
a serious brain-disease :-).
- Someone (sorry, I forgot who) said that one language is more HL than
another if it lets you say *what* is to be done, while the
you have to specify *how* it should be done in the other.
This sounds as a really neat criterion. It is also more-or-less
measured by my previously posted "statistic approach" (have
a number of programmers tackle the same problem, and see how
many come up with the same solution).
-
- There are some parial orderings that seem to be quit general
accepted ( F66 < F77, Algol 60 < Pascal, etc), and there are some
pairs of languages that are probably not comparable (C and LISP,
APL and COBOL, etc).
But, there are also some languages that are in the same class, like
Pascal, C, Algol 68, Ada, or SNOBOL, AWK, ML/1 (maybe).
Maybe we could try ordering these *within their class* by having
people defend their pet-language by showing it's strength over
the other languages in the same class? If enough people do this,
we should be able to make a list of pros and cons of each language,
and use this to order the languages within one class.
--
Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack
or ...!vu44!htsa!jack
If *this* is my opinion, I wasn't sober at the time.mwm@ucbtopaz.CC.Berkeley.ARPA (01/12/85)
> In Basic...I would > invert a matrix A using the statement: > 100 MAT A = INV (A) > How about APL (or the last APL I used, anyway)? > A gets domino A > Where "gets" is a left arrow and "domino" is quad-overstrike-divide-sign. > None of these silly MATs or needless function calls. How about SAS (if memory serves me correclty): A = A ** -1 ; <mike
david@ukma.UUCP (David Herron, NPR Lover) (02/05/85)
I have been interested in this discussion. But have stayed out of it
because I wasn't sure if I could contribute well. But I have had one
idea that nobody else has talked about.
It has to do with the types of operators the language has. A high
level language would have a high proportion of high level operators.
Most low level languages are extremely low level since the operations
they can perform are very limited. But prolog is very high level since
one operator may represent much work.
This idea springs out of a feeling I got when I finally understood
what an integral was. I all of a sudden KNEW that this squiggly
'S' shaped thing meant that I was supposed to do an infinite number
of additions of areas (all of which are infinitely small). It is
just kind of staggering what kind of power that is. I have felt that
same feeling for only two programming languages, Icon and Prolog.
(Neither of which I know well, gosh darn it).
At any rate. By the above definition, Calculus is a very high
level language.
I also suspect that this is only part of the definition. That the
"level" of the data types has a lot to do with language level.
(Level of data type would also affect level of operator, and
vice versa. hmmmm.....).
Well, thanks for listening to me.
--
-:--:-
David Herron;
ARPA-> "ukma!david"@ANL-MCS or david%ukma.uucp@anl-mcs.arpa
UUCP-> {ucbvax,unmvax,boulder,research}!anlams!ukma!david
UUCP-> {mcvax!qtlon,vax135,mddc}!qusavx!ukma!david
UUCP-> {A-Large-Portion-of-The-World}!cbosgd!ukma!david
No stupid sayings (I can't think of one).
No stupid disclaimers (Nobody else would claim my statements anyway).jsdy@hadron.UUCP (Joseph S. D. Yao) (02/25/85)
I think the best fuzzy-definition for this fuzzy concept is that a
higher-level language has higher-level abstraction of concepts. That
is sufficiently fuzzy that, whatever you think is a better abstraction,
a language that has that is higher-level f o r y o u . Let's not
forget that there is some subjectivity involved here, since languages
are used to communicate concepts, and typically at least one of the
entities involved is a human or other sentient entity. ;-)
The above definition would include david@ukma's concept of more
powerful operators. It would also include better control structures
(an extension of "operator") to perform more abstract operations.
It would include better data type definitions: first, of more
"natural" atomic data types; then of complex data types; then of
data types with actions associated with them, and so forth.
No flames, please: I will respond either OK, we disagree or yes,
for you that is a better abstraction. Constructive discussion &
criticism welcomed.
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}