ds@hollin.prime.com (10/17/89)
A Position Paper - -------- ----- I believe that programming languages should change little once they are in widespread use, to encourage portability and programmer productivity. This implies that languages should be designed carefully and "shaken out" by alpha and beta testing prior to release as is done for most real-world software products. This can be done formally, as was the case with Ada, or informally, as was the case with Forth. Allowing languages to change a lot (as is seen in the Cobol 85 and Fortran 8X standards efforts) encourages each language to pick up all the semantics of the others, plus more. In effect, each language becomes a syntactic variant of the current "universal language" that PL/I used to represent, and this set of target semantics keeps getting more complicated. I would love to see Fortran returned to a simplicity intermediate between FORTRAN II and FORTRAN IV (with all the ugly stuff retained, so dusty decks could still be compiled), and new languages designed for vector operations and other such semantic improvements. I am in favor of language extensions that make a language more consistent with its design philosophy or better suited to its users' purposes, but I oppose extensions that do not fit its design philosophy or that address the needs of only a very few users. IMHO, many of the current standards efforts violate one or both of these principles. I believe that there is room for a large number of languages, both because new languages bring us improved expressive power and because certain languages are best suited for specific applications (Basic and LOGO for beginners; Forth for programming peripherals and in other small-memory environments; Prolog for reasoning over a knowledge database; Lisp for list manipulation; SNOBOL, awk, and Icon for string manipulation; PL/I and Ada for accurate and/or precise arithmetic calculations, etc.). I believe that there is much to improve in both the syntax and semantics of our programming languages. We should use new languages as the vehicle for experimenting with such improvements in most cases, not merely tacking them onto an existing favorite language. As people play with Eiffel, Edison, Euler, Y, Miranda, and the hundreds of other new and sometimes obscure programming languages they will gradually discover the best language features to use in the various programming environments. Avoiding incompatible language extensions is an important tool in achieving progress while minimizing its negative impact. David Spector Prime Computer, Inc. ds@primerd.prime.com (until the layoff)
ok@cs.mu.oz.au (Richard O'Keefe) (10/17/89)
In article <26600001@hollin>, ds@hollin.prime.com writes: > A Position Paper > - -------- ----- > I believe that programming languages should change little once they are in > widespread use, to encourage portability and programmer productivity. The way I put it is "I can use almost anything if it will only STAY PUT". There is a BSI/ISO committee currently working on a Prolog standard. The standard was originally promised for the end of 1985. The committee are busily trying to hack the thing around to suit their own personal taste. In the mean time, Prolog users have to make do with what they can get. I have been saying since 1984 that the appropriate thing to do with Prolog is to take the language as it stands, freeze it, and then go on to do something different. People designing the next generation of logic programming languages should not be hampered by compatibility with the makeshifts of the current generation, and people trying to put the current generation to practical use shouldn't have half-baked ideas about the next foisted on them.
gateley@m2.csc.ti.com (John Gateley) (10/19/89)
In article <26600001@hollin> ds@hollin.prime.com writes: >I believe that programming languages should change little once they are in >widespread use, to encourage portability and programmer productivity. This >implies that languages should be designed carefully and "shaken out" by alpha >and beta testing prior to release as is done for most real-world software >products. This can be done formally, as was the case with Ada, or informally, >as was the case with Forth. First, the main argument against language freezing is new developements in language design. It is this tension between new developements and portability/stability which make the issue you are addressing difficult. Second, for almost all languages, there is a hurdle to surmount: user acceptance. If I went into reclusion, wrote the worlds best language, then came onto the net and said "I need alpha testers", my language is going to die because no one will use it. Ada is an exception because the DOD mandated usage. Most language designers don't have this much influence. >I would love to see Fortran returned to a simplicity intermediate between >FORTRAN II and FORTRAN IV (with all the ugly stuff retained, so dusty decks >could still be compiled), and new languages designed for vector operations and >other such semantic improvements. Suppose this were true: and next year someone came up with a bug in the old FORTRAN compiler: whose gonna fix it? Not the people who wrote the compiler, they have since gone on to bigger and better things. And now this poor guy has to rewrite his entire application (possibly including several dusty decks) in a newer language to get around the problem. >I believe that there is room for a large number of languages, both because new >languages bring us improved expressive power and because certain languages are >best suited for specific applications [examples deleted] There is a LARGE problem in interlanguage communication: how are you gonna get from C to Lisp, where Lisp requires tagged data objects and C doesn't. What about Ada, where parameters may or may not be passed by reference ( compiler A implements IN OUT as pass by ref, compiler B does them by copying). Now, your C compiler not only has to know about Ada function format, it also has to know which Ada compiler you are using. I would love to be able to use any combination of languages I want, but there are many problems. >I believe that there is much to improve in both the syntax and semantics of >our programming languages. We should use new languages as the vehicle for >experimenting with such improvements in most cases, not merely tacking them >onto an existing favorite language. Another approach is to have a language designed for use in studying programming languages. Scheme has been used for this purpose, since it is easy to write interpreters in Scheme. This avoids having to build a whole new language to study a single improvement. >David Spector >ds@primerd.prime.com (until the layoff) John gateley@m2.csc.ti.com