Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!rpi!bu.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Algol, and language design Message-ID: <2417@l.cc.purdue.edu> Date: 29 Jul 90 15:04:20 GMT References: <25630@cs.yale.edu> <58091@lanl.gov> <25767@nigel.udel.EDU> Organization: Purdue University Statistics Department Lines: 85 In article <25767@nigel.udel.EDU>, carroll@udel.edu (Mark Carroll ) writes: > In article <2406@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > ]> > ]> How about nested scopes and recursion? I find them handy from time to time. ........................ > I'm sure that everyone and his brother is going to jump on you for this, > but I'll join the bandwagon. This post is SO full of blatant proofs that > you know very little about language design. I certainly misunderstood what was said. As for nested scopes, I have used them when available, and I have no difficulty with the concept or the implementation. I find it somewhat annoying that assemblers do not make better use of it. As I said, I misunderstood the terminology. As for language design, I am certainly not an expert. But I do not object when those consulting me ask for something the standard statistical procedures cannot deliver. The statistical packages are as limited as the HLLs. ...................... > The other major problem in the quoted section in your remark about the fact > that recursion was hard to implement. The purpose of programming languages > is to allow you to simply express operations that would be extremely difficult > to express on the real architecture. A technique like recursion is incredibly > useful - to disallow using it in a supposedly general programming language > would be foolish. Recursion still is hard to implement. There are situations where plopping everything on the stack is a good way, and situations in which this is horrible, and managing memory blocks is a better idea. Without guidance from the programmer, the compiler will not know which. However, I do not believe that recursion, nor anything else, should be left out of the language. If you look at my complaints, they are not that things are in the language, but that things are not in the language ! My personal problem with this whole discussion is that I think we want different ! things from a programming language. What you're looking for in a language ! is a fancy macro assembler. Personally, I have no interest in that. What I ! look for in languages is a way to express my algorithm in a model of ! computation that is different from the underlying architecture of my machine. ! If it less efficient than it would be in assembler, I don't particularly care. ! I'm not looking for speed - I'm looking for the best way to express my ! algorithm in a natural way. I like object-oriented programming languages ! for certain jobs, because they let me express the relationships between the ! objects that I am manipulating in a natural way. For other jobs, I like a ! language like C, which is almost a portable assembly language. For yet ! other jobs, I like a functional language, because they provide me with ! a clean way of expressing certain kinds of mathematical relationships. ! A language provides with a clean expressive mechanism that is independant ! of my underlying architecture. That's not always what I want - sometimes ! I need to be close to the architecture. But the fact that I'm not close ! to the architecture is NOT a flaw in the language I'm using - it's a ! feature of the language! I have never stated that languages must insist on efficiency, but that they are capable of it. If you do not wish to use a feature of the language, and you can get along without it, by all means I do not intend to force you. You say you sometimes want this, and sometimes that, and sometimes the other. I want all of this, and more, at the same time. If, for example, C does a good job of expressing the structural considerations in an algorithm, an optimizing C compiler may do well. But if it does not consider relevant aspects, it will not do well. And I do use programming constructs which are very clumsy in the HLLs I have seen, but simple from a mathematical point of view. You like an object-oriented language, and you like a functional language. Why not combine everything? It is not so much a problem for the language designer as for the compiler writer. In addition, I find the architectures simpler than the HLLs. It is not true that Algol has all the primitive operators for numerical calculation in its list of operators. It is true that it has enough that one can define any other, but this is like saying that the way that multiplication should be perforemed is by squaring the sum and the difference, subtracting, and shifting right two bits. The compiler may very well miss what I see, and vice versa. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)