Path: utzoo!attcan!uunet!oddjob!ncar!ames!oliveb!intelca!mipos3!omepd!uoregon!markv From: markv@uoregon.uoregon.edu (Mark VandeWettering) Newsgroups: comp.lang.misc Subject: Re: What makes a language "easy" to program in? Message-ID: <2176@uoregon.uoregon.edu> Date: 10 Jun 88 17:40:20 GMT References: <350@piring.cwi.nl> <711@cunixc.columbia.edu> <3799@pasteur.Berkeley.Edu> <712@cunixc.columbia.edu> <3880@pasteur.Berkeley.Edu> Reply-To: markv@drizzle.UUCP (Mark VandeWettering) Distribution: comp Organization: University of Oregon, Computer Science, Eugene OR Lines: 38 In article <3880@pasteur.Berkeley.Edu> faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes: >The way you would add such data types to a language is to build them out >of the primitives available, which are pointers (in the case of C), or >arrays (in the case of APL). Actually adding them as primitives would >be a very bad idea -- you could never add enough to make everybody happy. The plus and minus side of building complex data items into the language are: + You don't have to code them (unless you are the language designer). + They then form a standard reusable part of the language. - You don't know how they are implemented, so they might be inefficient. At the very least, you don't know the cost of individual primitives. The Icon programming language supplies sets, tables and lists as data types, and seems to provide acceptable performance (for an interpreter). If optimum performance is not an issue, it can provide a convenient platform to do many kinds of programming for which C would be awkward or expensive. >The sorts of things I use pointers for that I couldn't use arrays for >are parse trees and graphs (both directed and undirected). Often there >is no "higher-level concept" I am trying to express. Has anybody written >code to deal with these things in APL? Is it as ugly as it seems? I don't exactly see your point here, but there is definately a higher-level concept in parsing. And chances are a language with list or tree datatypes would allow you to express that more clearly (if less efficiently) than C. As for APL, well, if you are bound and determined, I am sure you could do parsing, but why do it when it is poorly suited for the job? > Wayne mark vandewettering