sasaki@harvard.ARPA (Marty Sasaki) (03/18/85)
> I have had the distinctly unpleasant experience of trying to fix a DEC > internal system which was written in OPS5, but fired up tasks written in > > o BASIC > o BLISS > o COBOL(!) > > Anyone acting in the role of program doctor would have done what I did. > I prescribed euthinasia. Why can't systems be written in multiple languages? Why can't you just plug in the "correct" language for a certain part of a system? Is the problem just the data-representation problem? Or is it more deeply involved? Maybe the paradigms are sufficiently different in each language that no human could be expert enough to handle more than one language? This seems like a problem that AI could solve. Programs, like the various "programming apprentice" systems could do the mapping from one data-representation to another. The paradigms are difficult, but work has been done here too, hasn't it? (I really don't know since my main interest is more software engineering rather than AI.) DEC has gone through a lot of trouble to provide good compilers for the various languages, why can't we take advantage of it? -- ------------------------------------------------------------------------- Marty Sasaki net: sasaki@harvard.{arpa,uucp} Havard University Science Center phone: 617-495-1270 One Oxford Street Cambridge, MA 02138
hen@bu-cs.UUCP (Bill Henneman) (03/18/85)
There are the technical issues about language-language interface which can be sources of error, but generally they are documented (at least in the source listings of the compilers/interpreters. For example, the LISP I use on the IBM 3081 puts extra information in an array header for faster indexing: I have to reformat the array before I pass it to FORTRAN. This means that, before deciding to go multi-language on a system, I have to do a calculation that the time spent groveling through manuals (and sources) can be bought back by the added efficiency. However, I my reference to Whorf was possibly to elliptic. Whorf was an American linguist who advanced the hypothesis that the language you speak greatly influences the way you think about the world around you. As I said, whether or not his hypothesis is valid for natural languages, it is certainly true for computer languages. Implicit in the fact that I am writing a program in COBOL is the decision that the data flow is important, and the control flow is trivial. Similar judgements go into any choice of language for any program I write. I try to match the tool to the job. Each language has its own strengths and weaknesses, but the price paid for the strength of any given language is that it imposes a problem-solving style on the programmer. Just as in natural language, computer languages cluster into families. There is nothing hard about mixing FORTRAN & COBOL modules into a big system (or FORTAN & PL/I). I've done plenty of that sort of stuff. It's when you move across families where things break down, and especially where you try mixing an inherently interpreted language like LISP or SNOBOL with an inherently compiled one like FORTRAN that things get dangerous. A system which is dangerously multi-lingual will, in my view, perforce be difficult to maintain because it is opaque for the two reasons cited above: some of the code will be obscure because it is faking an environment for the sibling, and the rest will lack unity of style. Speaking from experience, I can say that no one person is going to be able to understand the whole system. I've been programming since 1955, and I've never met a programmer equally proficient in all languages. Some languages match their thought processes, and some don't. The amount of worthwhile communication between a FORTRAN programmer and a LISP programmer is non-measurable, because their fundemental ideas about what programming is are irreconcilable. Bill Henneman
shebs@utah-cs.UUCP (Stanley Shebs) (03/19/85)
In article <259@bu-cs.UUCP> hen@bu-cs.UUCP (Bill Henneman) writes: >It's when you move across families where things break down, and >especially where you try mixing an inherently interpreted language like >LISP or SNOBOL with an inherently compiled one like FORTRAN that things >get dangerous. If a person as experienced as Bill Henneman can have this misconception, then it must be distressingly prevalent! There are NO languages that are "inherently" interpreted or compiled. The preponderance of Fortran compilers and Lisp interpreters is more the result of historical accident than of any deeper reason. In fact, some elementary diddling with denotational semantics shows that compilers and interpreters always come in pairs - every compiler has an associated interpreter, and vice versa. For "normal" compilers, the interpreter is the bare machine plus a runtime system. For "normal" Lisp interpreters, the "compiler" is the Lisp reader, which maps strings to s-expressions. But these standards of normality are dictated by convention, rather than by the actual definitions of the languages (thus we frequently see Lisp compilers, and less frequently Fortran interpreters). The *real* differences between Lisp and Fortran lie in two areas: Lisp is primarily functional, while Fortran is imperative (no, neither is perfect in its adherence to the paradigm!), and their primitive datatypes are quite different. stan shebs
slack@wxlvax.UUCP (Tom Slack) (03/20/85)
> > I have had the distinctly unpleasant experience of trying to fix a DEC > > internal system which was written in OPS5, but fired up tasks written in > > > > o BASIC > > o BLISS > > o COBOL(!) > > > > Anyone acting in the role of program doctor would have done what I did. > > I prescribed euthinasia. > > Why can't systems be written in multiple languages? Why can't you just > plug in the "correct" language for a certain part of a system? Is the > problem just the data-representation problem? Or is it more deeply > involved? Maybe the paradigms are sufficiently different in each > language that no human could be expert enough to handle more than one > language? > I strongly disagree with the first author. Until programming languages get out of their own shells (no pun intended), we will never have reasonably reusable software. This is one of the reasons that UNIX pipes were invented. I have recently (three years ago) gone through the process of moving a LISP program (which I wrote) into PASCAL through several intermediate stages where PASCAL routines were called by LISP. The original program in LISP was about 500 lines. The current PASCAL implementation is about 3000 lines. We discovered many details of importance to the application itself which were hidden by the LISP implementation and became apparent only after trying to code the problem in PASCAL. Using LISP in this manner is distictively advantageous at times. It can also have its difficulties. The computer industry has just gone through a shake down it deserved because each cpu believed that it was the center of the world (hardware wise). Personal computers are changing all that. Unfortunately there are still people writing software systems which want to take over the world (software wise). Tom Slack ittvax!wxlvax!slack
slack@wxlvax.UUCP (Tom Slack) (03/20/85)
> However, I my reference to Whorf was possibly to elliptic. Whorf was an > American linguist who advanced the hypothesis that the language you > speak greatly influences the way you think about the world around you. > As I said, whether or not his hypothesis is valid for natural languages, > it is certainly true for computer languages. Implicit in the fact that > I am writing a program in COBOL is the decision that the data flow is > important, and the control flow is trivial. Similar judgements go into > any choice of language for any program I write. I try to match the tool > to the job. Each language has its own strengths and weaknesses, but the > price paid for the strength of any given language is that it imposes a > problem-solving style on the programmer. I agree with this fundamentally, however the correct approach for the progammer worth his salt is to say that all successfull programming languages (read problem-solving styles) have some merit. A good 3rd generation system such as C or PASCAL can implement these styles albeit with some difficulty provided the programmer has them firmly established in his mind. > Just as in natural language, computer languages cluster into families. > There is nothing hard about mixing FORTRAN & COBOL modules into a big > system (or FORTAN & PL/I). I've done plenty of that sort of stuff. > It's when you move across families where things break down, and > especially where you try mixing an inherently interpreted language like > LISP or SNOBOL with an inherently compiled one like FORTRAN that things > get dangerous. The Good Programmer should know fairly well languages from several families. > A system which is dangerously multi-lingual will, in my view, perforce > be difficult to maintain because it is opaque for the two reasons cited > above: some of the code will be obscure because it is faking an > environment for the sibling, and the rest will lack unity of style. > Speaking from experience, I can say that no one person is going to be > able to understand the whole system. I've been programming since 1955, > and I've never met a programmer equally proficient in all languages. Here is where I really disagree. I have not known a really good programmer who was not very proficient in at least two families of Languages. Usually one of those was PL/1 C or PASCAL. The others were from RPG ALGOL APL and LISP to many macro assemblers FORTH or even COBOL. It may be that they have a preferred language (Mine was APL till I learned LISP), but they are quite comfortable in the other. Nothing says that people cannot think two ways (or more). > Some languages match their thought processes, and some don't. The > amount of worthwhile communication between a FORTRAN programmer and a > LISP programmer is non-measurable, because their fundemental ideas about > what programming is are irreconcilable. > > Bill Henneman I would change this to read: The amount of worthwhile communication between a programmer who only knows FORTRAN and one who only knows LISP is non-measurable, ... Tom Slack
bobd@zaphod.UUCP (Bob Dalgleish) (03/21/85)
> ... > Just as in natural language, computer languages cluster into families. > There is nothing hard about mixing FORTRAN & COBOL modules into a big > system (or FORTAN & PL/I). I've done plenty of that sort of stuff. > It's when you move across families where things break down, and > especially where you try mixing an inherently interpreted language like > LISP or SNOBOL with an inherently compiled one like FORTRAN that things > get dangerous. > > Bill Henneman My understanding is that Honeywell Multics allows/supports/encourages multiple language systems by defining data structures in parameters in a language-independent way. Thus, my neighbourhood Multics fanatic says it is easy and natural to mix LISP and PL/I (admittedly not ANSI standard). Similarly, DEC provides a common calling convention (which does not go nearly far enough - parameters are more interesting than calls). What I tell my young people (:-) is to choose "horses for courses" - use the best language for the task at hand. Medium to large projects unfortunately present a number of courses, but only one language can be used. We have attempted to disguise our single horse by using preprocessors and application generators when possible to provide more natural notation - database management and language parsing are prime candidates for this. My dream horse is one that allows me to specify what kind of course I am going to run for the next little while - the language acquires new or different capabilities to allow me to express my programs naturally. I know what happens to such bastard horses (er, languages) - they are called PL/I, LISP 2.0, Ada, etc. and they earn the undying contempt of the base language purists and the fear of those who cannot deal with having more than one way to look at a problem. The alternative is to provide an extensible language - such languages are often only trivially extensible (i.e., you still have to know the underlying language), or are so powerful as to overwhelm all but the most brave. -- [The opinions expressed here are only loosely based on the facts] Bob Dalgleish ...!alberta!sask!zaphod!bobd ihnp4! (My company has disclaimed any knowledge of me and whatever I might say)
portegys@ihlpg.UUCP (Tom Portegys) (03/22/85)
> Some languages match their thought processes, and some don't. > The amount of worthwhile communication between a FORTRAN > programmer and a LISP programmer is non-measurable, because > their fundamental ideas about what programming is are irreconcilable. > > Bill Henneman Oh come on now. This is going too far with the language X vs language Y debate. Is their a programming language which does not concern itself with tables, lists, sorting, searching, decisions, loops, etc? Yes, I know that in some languages these are called other things and can be done more simply than in others. But they are still there. And let's not forget that two programmers who have worked on the same application using different languages should have *something* in common. Tom Portegys