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.