pcolsen@SUPER.ORG (Peter C Olsen) (12/14/90)
Colston Chandler has hit the nail on the head. Computer Scientists use computers to do computer science; other scientists and engineers use computers to do something else --- like physics, O.R., chemistry, ocean modelling. The difference is that while Computer Scientists can appreciate systems for their own elegance, the rest of us must master both the computer and another discipline to get some net output. A good computer language should do more than substitute for binary machine code at a higher level; it should help you think about the problem at hand. It should "extend the vocabulary" with which you can address your technical subject. Computer languages, like every day languages, have different strengths and weaknesses. Ideas which are easy to express in some are difficult to express in some languages are very difficult to express in others. This is precisely why enforced standardization on a single language (an occasional bureaucratic result of language wars) is so harmful; it restricts the vocabulary we can use to understand problems. Where I work, the answer is "C" --- we just have not yet found all the questions. Now I have no objection to C; I write a lot of good code in it, but it's the Holy Grail. For some problems, C is a natural language --- especially those in which the data comes in "bytes". But for other problems --- especially those which are array- or list-oriented, it's often not the best language in which to think about the problem. For these problems, I may use APL, Scheme, or Lotus-1,2,3, depending on what I need to do. This upsets my local software support people because it's "not standard." My response is that I'd rather have a working algorithm in a non-standard language than a non-working algorithm written in C. I can always translate a working algorithm later. What then marks a "good" language? I think it is the balance between conceptual power and syntactic simplicity. APL and Scheme may be two polar cases. APL is a language of extreme conceptual power, but convoluted syntax. It's my language of preference for problems involving numerical array computations because of the powerful and concise array operators it offers. I could write the same operations in Scheme or C, but they are part of the basic vocabulary in APL. Scheme, on the other had, is a language of elegant syntax and conceptual simplicity. Scheme is my language of choice for problems in which I can pose the problem as a set of simple recursive operations on a stream of data. Scheme is a natural language for logical recursion, just as APL is a natural language for arrays. In summary, the "best" language --- in my experience --- varies with the specifics of each problem. There is no one "best" solution.