wgh@ubbpc.UUCP (William G. Hutchison) (12/03/88)
In article <3688@hubcap.UUCP>, steve@ragman (Steve Stevenson) writes: > From article <406@ubbpc.UUCP>, by wgh@ubbpc.UUCP (William G. Hutchison): [ table of languages with success/failure evaluations omitted ] > Though your table seems to be correct as far as languages now in use > is concerned, I think you should look at another perspective. The > impact of Algol-60 on the follow designs is considerable. agreed. > There are notable absences on the list: Simula-67 for example. Simula > is the ancestor of Ada and Modula. Likewise, CPL and BCPL. True: I was focussing on languages still current. > Languages are often busts because their inventors try to pass them > off as the UNIQUE solution to ALL the world's problems. ... > ... Pragmatic issues will win out. > Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Thanks, Steve, for the sensible remarks. The motivation behind my original posting is not to flame folks, but to discuss why progamming languages succeed and fail: this is a branch of psychology and political science as much as computer science. Now that we have gotten back to the topic I really wanted to discuss, I propose to focus on one particular issue: How can we (or you) produce a language that will supplant FORTRAN, in the sense that folks using FORTRAN would voluntarily migrate their code to the new language, or that economics would force them to migrate? Remember, responding that "Language X is better than FORTRAN already" is probably true, for many unifications with X, but it is not an answer to my challenge. An answer would be a new programming language, or a political and economic strategy to promote the use of X rather than FORTRAN. -- Bill Hutchison, DP Consultant rutgers!liberty!burdvax!ubbpc!wgh Unisys UNIX Portation Center "What one fool can do, another can!" P.O. Box 500, M.S. B121 Ancient Simian Proverb, quoted by Blue Bell, PA 19424 Sylvanus P. Thompson, in _Calculus Made Easy_
g-rh@XAIT.Xerox.COM (Richard Harter) (12/04/88)
In article <416@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes: > Now that we have gotten back to the topic I really wanted to discuss, I >propose to focus on one particular issue: > How can we (or you) produce a language that will supplant FORTRAN, in the >sense that folks using FORTRAN would voluntarily migrate their code to the >new language, or that economics would force them to migrate? This is not an easy proposition. For that matter it is not clear that there is any language which is so clearly better than Fortran that it is worth the effort. "better" is a relative term -- one has to take into account who uses a language and what it is used for. As a tecnical matter, however, the language would have to meet at least two requirements. The first is that the character set of the language should not include any characters that are not on both IBM and Ascii terminals (a major problem with C). The second is that there must be a fortran to X translater that accepts readable fortran and produces readable X; it is strongly advisable that there be one going the other way. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
steve@ragman (Steve Stevenson) (12/05/88)
From article <416@ubbpc.UUCP>, by wgh@ubbpc.UUCP (William G. Hutchison): > Now that we have gotten back to the topic I really wanted to discuss, I > propose to focus on one particular issue: > How can we (or you) produce a language that will supplant FORTRAN, in the > sense that folks using FORTRAN would voluntarily migrate their code to the > new language, or that economics would force them to migrate? > > Remember, responding that "Language X is better than FORTRAN already" is > probably true, for many unifications with X, but it is not an answer to my > challenge. An answer would be a new programming language, or a political > and economic strategy to promote the use of X rather than FORTRAN. At Supercomputing '88 there was considerable heat (and not much light) on the subject. The participants from the eng/sci side seemed pretty adament about retaining Fortran. But I heard an undercurrent that I've heard from years. Scientists I've worked with certainly quote Hamming: ``the purpose of computing is insight, not numbers.'' At the ``Grand Visions'' session, several science types presented problems they saw as requiring a computer science solution --- and then claimed that CS folks were not in tune. I pointed out to the panel that no CS person was on the panel so it amounted to an incestuious relationship. But, I think they have a point. I would add the following rewrite of the Hamming quote: ``The purpose of programming languages is insight, not programs.'' I personally think that you will get scientists off Fortan when they can quit ``programming'' and start doing science. I would therefore say the following will have to happen: @ CS folks must recognize that their programming problems are to build eternal systems. A scientist's program is always evolving, as her/his insights deepen. @ CS folks do not have a recogized derivation criteria for their programs. Programs unfortunately just ARE qua ARE. Scientists and engineers have recognized ways to deal with the derivation. We should support that somehow. @ The promotion of X (above) requires showing the scientist/engineer that their science is preserved. Fortran is to science what Cobol is to DP: a tremendous investment in the past and, right or wrong, the embodiment of the societal knowledge. So I'd challenge the CS community. Quit carping; Ada is not a solution if nobody uses it. Claiming that complex numbers are not interesting enough to be a defined part of the language will not sell any scientist doing eigenvalue problems. Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906
ok@quintus.uucp (Richard A. O'Keefe) (12/06/88)
In article <3741@hubcap.UUCP> steve@ragman writes: > @ CS folks do not have a recogized derivation criteria[sic] for their > programs. Programs unfortunately just ARE qua ARE. Scientists > and engineers have recognized ways to deal with the derivation. > We should support that somehow. This sounds important, but I don't understand what you mean by "a derivation criterion". (I guess Statistics doesn't count as science or engineering, otherwise I would know what the "recognised ways" are.) Where does program transformation come into this?
steve@ragman (Steve Stevenson) (12/06/88)
From article <814@quintus.UUCP>, by ok@quintus.uucp (Richard A. O'Keefe): > This sounds important, but I don't understand what you mean by > "a derivation criterion". (I guess Statistics doesn't count as science > or engineering, otherwise I would know what the "recognised ways" are.) > Where does program transformation come into this? What I mean is to take a physics model and postulate some behavior. That behavior is subject to principles which have their effect on the trajectory functions. Take for example the Navier-Stokes equations for fluids. It specifies the various parameters, etc. The development proceeds until either an analytic solution exists or we must solve numerically. The bridge is then to Numerical, which must deal with the convergence, etc. There is the ultimate test of the postulates: does the model validate. Statistics does qualify in this sense, because we must provide sampling information --- and a bridge to probability. Again, the questions and parameters are well understood, or the statistician must then deal with a ``first principles'' problem. The history of science is replete with stories of models not being accepted, even though they eventually were based on empirical evidence. Example: statistical mechanics and its sad (personal) history of carpings and suicide. I know several folks who were burned bad by the computer in the late 60's. The program was fine: the model stunk and folks forgot to validate. [This goes back to the discussion I started on sci.logic. We have a real handle on the (formal) Reals. One is unlikely to propose a model of first order logic without producing a deduction theorem, for example. That discussion is aimed at the (pragmatic) observation that a ``proof'' isn't a proof if no one believes it. A derivation is not a derivation if no one believes it or can validate it. Now, the sum total of the ``mores'' of the community is the ``philosophy'' of the subject. Who set the p<.05 mark for most tests --- the community did. Can we have the same derivation concept in CS?] I think that the use of language between scientists and computer scientists is quite different: the scientist seeks insight --- that's the product. Yours and my products are meant to be a model of thought for the next person. We tend not to directly provide insights, but let the user come to her/his own. I'm proposing that we look at the ultimate objective: providing the scientist with insights; that subsumes our original goal of providing models of thought --- albeit only indirectly. Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906
john@uw-nsr.UUCP (John Sambrook) (12/08/88)
In article <3741@hubcap.UUCP> steve@ragman writes: >Scientists I've worked with certainly quote >Hamming: ``the purpose of computing is insight, not numbers.'' I could be wrong but I think this quote should be attributed to Alan Perlis, and not Hamming. I would check ACM SIGPLAN Notices, volume 17, number 9, September 1982. There is an article by Alan Perlis "Epigrams on Programming." I don't have the article handy, so I can't be certain that the quote is by Perlis. -- John Sambrook Internet: john@nsr.bioeng.washington.edu University of Washington RC-05 UUCP: uw-nsr!john Seattle, Washington 98195 Dial: (206) 548-4386
steve@ragman (Steve Stevenson) (12/09/88)
From article <1436@uw-nsr.UUCP>, by john@uw-nsr.UUCP (John Sambrook): > In article <3741@hubcap.UUCP> steve@ragman writes: > I would check ACM SIGPLAN Notices, volume 17, number 9, September 1982. This quote is in the frontespiece of Hamming's original "Numerical Analysis for Engineers and Scientists," NY: McGraw-Hill, 1962. Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906
john@uw-nsr.UUCP (John Sambrook) (12/09/88)
In article <1436@uw-nsr.UUCP> john@uw-nsr.UUCP (John Sambrook 548-4386) writes: >In article <3741@hubcap.UUCP> steve@ragman writes: > >>Scientists I've worked with certainly quote >>Hamming: ``the purpose of computing is insight, not numbers.'' > >I could be wrong but I think this quote should be attributed to Alan >Perlis, and not Hamming. I really blew it. The quote is from Hamming, not Perlis. Please accept my apologies. Maybe someday I'll learn not to post on a hunch. Sorry for wasting the bandwidth. I'll shut up now :-) -- John Sambrook Internet: john@nsr.bioeng.washington.edu University of Washington RC-05 UUCP: uw-nsr!john Seattle, Washington 98195 Dial: (206) 548-4386
smryan@garth.UUCP (Steven Ryan) (12/11/88)
I agree languages are but a tool and should meet the needs of the users, but
what are the needs of users?
Does anyone have a wish list of concrete proposals to make life easier for
scientific programming and/or numerical analysis?
--
-- s m ryan
--------------------------------------------------------------------------------
Commenting on the importance of student opinion to the adminstration,
Professor Deane declared, `Whether the students vote "yes" or "no" on an issue
is like telling me they like strawberries.'khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (12/13/88)
In article <2176@garth.UUCP> writes: >I agree languages are but a tool and should meet the needs of the users, but >what are the needs of users? This is what x3j3 grapped with for over 10 years > >Does anyone have a wish list of concrete proposals to make life easier for >scientific programming and/or numerical analysis? to produce the f88 document (as per WG5 ordination). Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
eugene@eos.UUCP (Eugene Miya) (12/13/88)
> S. Ryan asks Are there concrete proposals?
Sure FORTRAN 8X. 8)
Let's see, when I was in High School I heard about Fortran II, in college
I learned Fortran IV (WATFOR AND WATFIV), I took a workstudy job
and learned about Levels G and H (OPT=2), I forgot what SCOPE had,
Univac had Fortran V and Data General have VII and we all know VII > V > IV
right? Do you think DEC or Cray or any of the other vendors (American
European or Japanese) are any better? So, what's Fortran? Do you
believe in portability?
(You must also believe in the reply key on your mail system.)
I think we should scrap the language (COBOL, too). I think all
compiler development of the language should stop. Sure all science
as we know it now would stop. Even Backus doesn't write FORTRAN.
Now you can freeze existing compilers, that's okay. Just no fixes.
Now a few people (those who promote the conversion of dusty decks into
perfectly parallel code) would scream, as would the users.
The computer community should force the rest of the world to reevaluate
their codes and if they really need them, convert them.
Bell Labs and universities effectively did this with Unix.
I think this will benefit science as well as keep people employed.
A few token efforts will try to rewrite Fortran compilers, but all the
best compiler writers will be working to improve C, right?
This would also give other languages a chance to try their hand.
Don't think at evolution is necessary a gradual transition [Gould].
Those people and projects willing to make the transition to radically
new languages on architectures which perform significantly better
will cause colleagues to change because they won't want to be left in the
dust. That's why people went to computers in the first place.
I think its more important to replace BASIC (used to teach physics majors
at Caltech [noted in an issue of Engineering and Science over a year ago].
You see language design is the result of the tension between expressiveness
and flexibility. If you want help on a computer, some keyboards
actually have a "HELP" key, a single powerful key, whereas others require
4 separate stokes ('H''E''L''P' on the QWERTY keyboard). This has never
been standardized. This is why I don't like Programmed Function keys
Do you hit "Backspace" or "Delete?" (another relgious argument).
Do you think the PF keys are standard?
Anyways, it will never happen.
You can start breathing again.
Another gross generalization from
--eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov
resident cynic at the Rock of Ages Home for Retired Hackers:
"Mailers?! HA!", "If my mail does not reach you, please accept my apology."
{uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene
"Send mail, avoid follow-ups. If enough, I'll summarize."smryan@garth.UUCP (Xxxxxx Xxxx) (12/15/88)
>to produce the f88 document (as per WG5 ordination). In other words, we'll supplant fortran with fortran 8x? -- -- x x xxxx +------------------------------------+-----------------------------------------+ |`Xx X-Xxxx xx xxxxx Xxxxxxx xxxxx, |`Xxxxx xx xxxxxx xxx xxxx xxx | | Xxxxxxx xxx'x xxxxxx.' |xxxxxxxxxxxxxx xxx xxxxx xxxx xxxxxxx xxx| | -Xxxxxx Xxxx |xx. Xx xxxx xx xx xx xxxxxxxxx.' -X Xxxx| +------------------------------------+-----------------------------------------+
mct@praxis.co.uk (Martyn Thomas) (12/15/88)
Is there a formal, semantic definition of FORTRAN yet? If so, please will someone post a reference? If not, FORTRAN programs would seem not to mean anything, so people who write programs in it must either: - not realise that their programs are meaningless, or - not mind, or - believe that they know their own compiler so well that they can safely predict the behaviour of their programs. In the last case, they are either right or wrong (probably wrong). If they are right, then they are effectively using a local language, of limited portability, which happens to bear a passing resemblence to other local languages (also called FORTRAN). Isn't this the essence of the problem? Of course, it applies to most languages. Of course, if there is a semantic definition, and compilers are validated against it, and programmers understand it, then the analysis above is out of date. Then there's the problem of programmers making mistakes (which they can easily do, even in a well-defined language, and not all mistakes can be detected by the compiler or run-time system). Strong typing helps a lot here, by encouraging the programmer to provide (logically redundant) information (in type definitions) which can be used for checking consistency of use of data. Good compilers (and hardware architectures) trap common dynamic errors (such as index out-of-bounds). The worst combination would be a language with no formal semantics, weak data-structuring and weak typing, limited bound-checking (and other exception-detection), running on a hardware architecture with no memory protection, or overflow/underflow detection. Does this remind you of a FORTRAN (or C or ...) implementation somewhere near you? Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: ...!uunet!mcvax!ukc!praxis!mct