home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.edu:1403 comp.lang.fortran:3271 comp.lang.misc:2798 sci.math:10684
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!rutgers!network.ucsd.edu!lyapunov.ucsd.edu!mbk
- From: mbk@lyapunov.ucsd.edu (Matt Kennel)
- Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
- Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
- Message-ID: <17mcr4INN4qq@network.ucsd.edu>
- Date: 28 Aug 92 23:28:36 GMT
- References: <BtpAIn.EE5@mentor.cc.purdue.edu>
- Organization: Institute For Nonlinear Science, UCSD
- Lines: 109
- NNTP-Posting-Host: lyapunov.ucsd.edu
- X-Newsreader: Tin 1.1 PL3
-
- hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
- : The problem is that the CS people are, in this sense, like the purissima
- : mathematicians (if it can be applied, it is time to work on something else.)
- : They concentrate on what no scientist is particularly worried about, like
- : making the printed output look neat, or even making life easy for the
- : compiler.
-
-
- : Most good scientists can think of their problem, and how reasonable operations
- : can attack it. But the languages do not facilitate this, and often even if
- : the features are present, they are in some obfuscated syntax.
-
- I agree. I believe the CS vs. Science programming divide is cultural, but
- I'm going be somewhat partisan and blame the programming authorities a bit more
- than the scientists.
-
- My view of things:
-
- 1) There are scientists who don't know the value of organized software
- engineering. I mean basic things like type-checking subroutine
- arguments, modularization, modern data types, and other things like
- that. They write the infamous spaghetti Fortran.
-
- 2) There are computer scientists who don't understand the demands of
- scientific computing, which is understandable, because they never
- write scientific programs.
-
- The problem is this:
-
- There are scientists who *have* learned the value of good software
- engineering and believe what the comptuer scientists have said for years, and
- honestly try to stay up to date.
-
- Too many CSoids however dismiss the concerns of scientists as being
- narrow and "uninformed", assuming that they're all like the nerds in
- #1 above. Or they claim that language X does what scientists need
- (or "no we don't need to bother because it's possible to implement that
- in a library" or "a quality of implementation issue" (a euphemism for
- "we don't really give a shit") ) and say that we're silly when we disagree.
-
- Software technology and practice for addressing the particular concerns of
- computer scientists has advanced tremendously since the early days, but the
- model of scientific computation hasn't changed much since early Fortran
- except vicariously through the progress in "regular" computer science.
-
- I personally would love a "Numerical Eiffel" type of language, but I bet the
- Eiffel gurus would say "eeuy yuck, you're polluting our pristine creation
- with needless cruft". One of the Modula-3 people has said that one of
- their design goals was to make it good for numerical computation (a
- refreshing attitude). One of the examples was "easy access to the IEEE
- rounding modes" (what the f*???) as standard in the library, but admitted that
- complex numbers weren't, much less array operations.
-
- I don't want "good for numerical computation" to mean "not all that much
- worse than Fortran 77"!
-
- I believe Herman Rubin and other mathemeticians when they say that they want
- good performance and easy use of multiprecision integers and fixed point
- numbers, even though I and most physicists, would never have a use for
- them. So can the computer scientists accept our needs as well? Remember,
- it's the scientific programmers who *DO* want change who are doing all the
- complaining--the "old farts" just keep on banging out Fortran and mind their
- own business.
-
- Scientists don't want to needlessly accept *regress* in concrete areas in
- order to make supposed "progress" in areas they haven't been convinced they
- want. The progress has to be good enough to convince departmental computer
- comittees to buy a new $2000 compiler. Notice that scientists aren't
- all that hidebound by tradition---they enthusiastically take up Maple
- and Mathematica---because they can immediately recognize progress, and
- even despite their lack of "goto". :-)
-
- And finally the old standby "why speed is in fact, important". Why does
- factor of 2 matter? It's the old "the program is everything" view. Running
- any particular one program faster is not, in fact, what matters. What does
- matter, is that with a faster machine and a faster language I can do *more*
- and *better* science. (I could easily use up a 10 teraflop machine next
- month.) Many times we're running things on hardware far too underpowered to
- "do the job right" in any case, but science accepts approximate solutions.
-
- Take the statement, "Scientific progress is proportional to the logarithm of
- computer power."
-
- The computer scientist hears this and says "You silly fools, if you
- saw the big picture you'd realize that the constant factor doesn't matter
- one bit so quit complaining."
-
- The scientist hears this and says "Well that's why we need to get
- all we can get, and then some, in order to make progress."
-
-
- I think there is in fact some hope.
-
- Specifically, the parallel- and super- computer research community.
- In it, there are people who truly understand both the computer scientists
- and the scientific users and are committed to progress rather than
- defining away the problem as uninteresting or trivial.
-
- : --
- : Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
- : Phone: (317)494-6054
- : hrubin@pop.stat.purdue.edu (Internet, bitnet)
- : {purdue,pur-ee}!pop.stat!hrubin(UUCP)
-
- --
- -Matt Kennel mbk@inls1.ucsd.edu
- -Institute for Nonlinear Science, University of California, San Diego
- -*** AD: Archive for nonlinear dynamics papers & programs: FTP to
- -*** lyapunov.ucsd.edu, username "anonymous".
-