Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83 based; site houxf.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxb!mhuxn!mhuxm!mhuxj!houxm!houxf!stewart
From: stewart@houxf.UUCP (Bill Stewart HO 4K-435 x0705)
Newsgroups: net.lang
Subject: Re: Language level measurements query
Message-ID: <853@houxf.UUCP>
Date: Mon, 11-Feb-85 00:34:21 EST
Article-I.D.: houxf.853
Posted: Mon Feb 11 00:34:21 1985
Date-Received: Tue, 12-Feb-85 05:15:58 EST
References: <645@sdcsvax.UUCP>
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 32

The problem with even proposing level measurements is that "level" isn't a
one-dimensional variable - some of the things that go into the concept are:

	What kind of "high-level" abstract objects are available
	What "high-level" verbs can you apply to those objects
		(or, for object-oriented languages, what actions can you ask
		the objects to do for you.)
	What kind of control structures does the language provide
		this definition applies more to algorithmic languages
		than to functional ones.
	What are the "lowest-level" objects you can manipulate (low-level in
		the sense of machine-dependent, implementation-dependent,
		"real stuff".)
	What are the lowest-level objects you *have to* manipulate to do
		useful work?  (In APL you can use flexible-sized arrays; in C
		you need pointers and often malloc().)

The latter two are easy to mix up; people like Jerry Pournelle think BASIC
is higher level than C because pointers let you know about objects'
locations in memory; I guess BASIC is low-level if you include PEEK and POKE
and high-level without them.

Also, a language can be "higher-level" for some tasks than for others; I'd
rather write simulations in C++ or LISP,  but I'd rather crunch statistics
in APL.

-- 
Bill Stewart	ho95c!wcs AT&T Bell Labs, Holmdel NJ
HO 4K-435 x0705   (201-949-0705)
{allegra, ucbvax!ihnp4, decvax!harpo}!houxf!stewart
------
Sorry if the articles I'm replying to re ancient; we lost news for a month.