Path: utzoo!mnetor!uunet!littlei!ogcvax!pase From: pase@ogcvax.UUCP (Douglas M. Pase) Newsgroups: comp.lang.misc Subject: Re: HLLs vs asm (was Re: portable "asm") Message-ID: <1600@ogcvax.UUCP> Date: 24 Mar 88 07:55:34 GMT References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <1592@ogcvax.UUCP> Reply-To: pase@ogcvax.UUCP (Douglas M. Pase) Organization: Oregon Graduate Center, Beaverton, OR Lines: 87 In article cik@l.cc.purdue.edu (Herman Rubin) writes: > However, the >first requirement for an _adequate_ programming language is that if I start >with a reasonable mathematical construct, [...] Imperative languages are built around the concept of a state machine -- statements in the language are transformations from one state to the next. There's nothing inherently un-mathematical about that. In fact, Floyd, Hoare, and others have developed a rather interesting mathematical structure around such machines. If you would argue that it isn't "reasonable", well, many persons smarter than I am have varying opinions on what is "reasonable", and they don't necessarily agree with you. (I use the term "state machine" in its more general sense -- I am not refering to the FSM of language theory.) >There are two different aims of a programming language. One is the description >of the procedure. For this, the current languages are totally inadequate. >They are much too restrictive, as well as lacking in scope. Did you ever wonder why those "restrictions" are there? Do you think it's because those who designed the languages ``just weren't smart enough to do the job right?'' It's very very easy to design a language which is internally inconsistent. Many of the inconsistencies do not become apparent until one actually tries to *implement* the language. Some are not even known until much later than that. Another thought, people use programming languages for many different purposes. Does this mean that we should look for that one "reasonable" mathematical structure which subsumes all possible uses for computers? Ridiculous! Some languages attempt to do just about that (Ada and PL/I immediately come to mind), but it is questionable that they succeed at it. >It is necessary to restrict portability. Semi-portability >may still be desirable. You may consider this a desireable feature, but I, for one, do not. >In article <1592@ogcvax.UUCP>, pase@ogcvax.UUCP (Douglas M. Pase) writes: >> If you think you really can do better than ``C'' or some other successful >> language, *** DO IT ***. >If you provide me with the necessary programmers, I will. Here I am. If you come up with a language description sufficiently precise that it can be implemented, I'll be happy to produce a working compiler. It doesn't require an army of programmers to *design* a language. Besides, why are you trying to foist this part of the task on others -- you're supposed to be the one with the ideas. Even writing a compiler for your proposed language shouldn't be that much of a problem for you -- unless you have no idea how a compiler works. If this is the case I would be a bit more skeptical about your ability to design a language. (Yes I realize that some compilers require many man-years of effort. One needn't implement a full-blown all-the-bells-and-whistles compiler the first time around.) >The ability to define types as needed >and operators as needed, to ignore types when necessary, to use such machine >hardware as the language designer does not know about, to use condition codes >when convenient if available, etc., are extremely important. These are noble goals, and they have been incorporated into various languages with varying success. (Roll-your-own-operator is done in Prolog, define- your-own-type is a feature of CLU and (I think) Ada, ``C'' allows you to ignore types when you really want to, plus it allows access to the "bare metal", etc.) >We also need to be able to write the necessary constructs with a reasonable >number of keystrokes, and the notation should be reasonably easy to read. Some argue convincingly that verbosity is an advantage. Others argue against it. Some think ``C'' is easy to read but Pascal isn't; others believe the reverse. Everyone seems to have an opinion on this stuff. I have not recognized much in your postings that was not opinion. If you have something more substantial than gut feelings, please share it with us. As best I can tell you have not yet proposed much beyond a number of vague design goals with a small set of "features". You haven't even described your language's intended use. This is one reason why I suggest you flesh out your ideas a bit more. Your ideas may very well be dead on the mark -- gut feelings are sometimes right. If you did work out more of the details we would be better able to consider your ideas a bit more objectively. Through this whole article I have spoken strongly, but without intent to offend. If for any reason something I have said gives offense, please accept my personal apology. -- Doug Pase -- ...ucbvax!tektronix!ogcvax!pase or pase@cse.ogc.edu (CSNet)