HDTenEightyP/NetNews huggingface dataset:
From: jac@ds8.scri.fsu.edu (Jim Carr)
Newsgroups: comp.edu
Subject: Re: Scientists as Programmers
Date: 31 Aug 92 23:33:57 GMT
Reply-To: jac@ds8.scri.fsu.edu (Jim Carr)
Organization: SCRI, Florida State University

In article <134918@lll-winken.LLNL.GOV> miller@diego.llnl.gov (Patrick Miller) writes:
>
>This has worked acceptably well so far.  We were been able to teach
>physicists to write in FORTRAN in the 60's, to eliminate GOTO's in the
>70's, and to write vectorizable codes in the 80's.  All required skill
>and training, but non-computer scientists were able to learn these
>skills or sufficiently powerful compilers were able to cover their
>lack.  Now, however, we need to teach these same physicists how to
>parallelize their codes for massively parallel computers.  This is
>much harder.  I spent hours trying to convince a computational chemist
>that race conditions are bad and altogether too easy to generate.

Sure, but one once spent hours telling that person that (GOTOs, 
unvectorizable loops, ....) were bad.  It is just a new problem, 
just like the old ones, that will yield to education and the 
flow of information by word-of-mouth through the community. 

>FORTRAN 90 makes some strides in that direction by introducing
>functional vector semantics, but no variant of FORTRAN (IMHO) has
>adequately addressed many of the other problems (data layout, aliasing

It took a decade or more for the vector structures to sneak into the 
language.  I think the fact is that there is no way a *standard* 
language will show up that works with still-evolving systems until 
we have a lot of practical experience with those systems. 

>problems, etc...).  Here, we will need to see changes in the language
>physicists use because massively parallel computers EXPOSE TOO MUCH OF
>THE NATURE OF THE COMPUTER -- and their use requires much more

Only a matter of degree.  One needed to know about the nature of 
the computer to do vector programming.  One needed to know about it 
to avoid out-of-bounds array references, for that matter.  

>knowledge of how to manipulate them.  We will need to create some
>synergy between language designers and physical scientist so that we
>don't need to pair a computer scientist with physicist (or cross-train
>them).

I think we will need to cross-train them.

--
J. A. Carr                                    |  "The New Frontier of which I  
jac@gw.scri.fsu.edu                           |  speak is not a set of promises
Florida State University  B-186               |  -- it is a set of challenges."
Supercomputer Computations Research Institute |   John F. Kennedy (15 July 60)
Xref: sparky comp.edu:1453 comp.lang.fortran:3342 comp.lang.misc:2849 comp.arch:9131 sci.math:10804
From: sichase@csa1.lbl.gov (SCOTT I CHASE)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 1 Sep 92 19:41:40 GMT
Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA
Distribution: na
Reply-To: sichase@csa1.lbl.gov
NNTP-Posting-Host: 128.3.254.196
News-Software: VAX/VMS VNEWS 1.3-4   

In article <1992Aug31.133811.3626@crd.ge.com>, davidsen@ariel.crd.GE.COM (william E Davidsen) writes...
> 
>  The problem as I see it is that too many scientists and engineers
>think that because they can write working code they don't need (or are)
>programmers. Most people can learn to play the paino, but would agree
>that they are not professional quality, even the "background music in a
>piano bar" professional quality. Yet they think that programming
>somehow requires less training, practice, and dare I say it, *talent*
>than music.

It all depends on what you need to get done.  We physicists are very bottom-line
oriented.  I program carefully if I expect that I might need to modify 
a program somewhere down the line.  But if not, I just slap something together
that works.  If I need to sort a list, it probably doesn't matter which
algorithm I use as long as it works.  

But if I know that my ability to get the answers I need will depend on the 
method I use, then - and only then - do I take the time to look into the
best way to do it.

It's rather like cooking.  Most of us are not four-star chefs.  But we 
all cook when we need to get the job done.  I don't need a programmer most
of the time - certainly not more often than I need a chef.

-Scott

--------------------
Scott I. Chase			"The question seems to be of such a character
SICHASE@CSA2.LBL.GOV		that if I should come to life after my death
				and some mathematician were to tell me that it
				had been definitely settled, I think I would
				immediately drop dead again."      - Vandiver
Xref: sparky comp.edu:1406 comp.lang.fortran:3279 comp.lang.misc:2803 sci.math:10693
From: hougen@uirvlh.csl.uiuc.edu (Darrell Roy Hougen)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 29 Aug 1992 21:19:32 GMT
Organization: Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign
NNTP-Posting-Host: uirvlh.csl.uiuc.edu

mbk@lyapunov.ucsd.edu (Matt Kennel) writes:

>I personally would love a "Numerical Eiffel" type of language ...

Try "Sather".  It is an object-oriented programming language that is
competitive with Fortran in speed for complex problems.  Of course,
the object oriented dispatch makes it slightly slower for some types
of problems, but the designers have gone to great lengths to make it
fast.  The principle designer, Steven Omohundro, is a physics PhD
turned computer scientist, so that may explain why he is interested in
bridging the gap, as it were.

Sather is available from Berkeley via anonymous ftp.  However, I can't
seem to find the ftp site at the moment.  The author's email address
is om@icsi.berkeley.edu.  Be sure to mention Sather in the subject.

Darrell



Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Los Alamos National Laboratory
Date: Tue, 1 Sep 1992 23:41:06 GMT

In article <1992Sep1.202814.13937@crd.ge.com>, davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
|> [...]
|>   A certain nameless friend who is doing a PHd in CS was trying to sort
|> a million numbers using a bubble sort.  [...]

A certan CS *graduate* announced proudly to me that he never
bothered to take the sorting and searching courses because if he
ever need to sort something, he could pipe it through sort(1) and
you can always avoid complicated searching - just keep your data 
sorted and use a binary search!

The point is that there are anomalously *bad* programmers in
all fields.  The question remains, what does this say about
the quality of the CS department which graduated these examples?
It would seem similar to a physics graduate who couldn't solve
balance-beam statics problems.  Or a mathematician who didn't
know that multiply was commutative.

-- 
J. Giles
Newsgroups: comp.edu,comp.lang.fortran
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: scientists as programmers (was: Small Language Wanted)
Organization: Los Alamos National Laboratory
Date: Tue, 25 Aug 1992 20:23:07 GMT

In article <1992Aug25.154501.8654@colorado.edu>, ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:
|> [...] No offense to scientists, but I have rarely if ever seen a
|> scientist who was a good programmer. [...]

You must encounter a different set of scientists than I do.  Most of
the ones who develop code at all - that I deal with - are among the most 
talented programmers I've ever met.  Possibly this is not common at the 
*.edu sites.

To be sure, it is rare for a language to be designed with an eye toward
making the scientist's job easier.  Often, the computer "scientist" will
respond to a feature request from a scientist with "who'd want to do that?"
Or with "you don't want to do that" (as if the scientist didn't know what
he wanted to do).

Now, it's true that most scientists are not code-developers at all and
don't know anything about it (this is changing).  However, the fact that
people who never do code development are bad programmers doesn't seem
relevant.

-- 
J. Giles
Xref: sparky comp.edu:1503 comp.lang.fortran:3399 comp.lang.misc:2909
From: mccurley@cs.sandia.gov (Kevin McCurley)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 3 Sep 92 02:18:22 GMT
Article-I.D.: cs.1992Sep3.021822.14559
Organization: Sandia National Laboratories, Albuquerque, NM

In article <9224622.17597@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>>C++.
>
>Exactly. What's more, with C++ I can have arbitrary precision integers,
>arbitrary precision rational numbers, fixed point real numbers, etc.
>(all of these are available using GNU's libg++). If you want
>quaternions, then it's no big deal to add them too.

I am getting pretty tired of this thread, but there are lessons to be
learned.  I personally do my programming in C because it allows me to
get close to the silicon and manipulate data structures at high speed
as is needed for my branch of science.  Others in my lab use Fortran
for several good reasons: 

1.  the existing code in their area of science is worth leveraging.
2.  Fortran manipulates integers, floats, and arrays.  Coincidentally
these are the same things that silicon usually manipulate, and the
thing that scientists most often need to compute with.  This makes it
easier for the programmer to write efficient code (from a runtime
viewpoint).
3. It provides some degree of portability between suns, sgis, crays, 
and intel and ncube parallel machines.

We have access to the fastest computers (serial, parallel, and
vector), but the solution is not to just get faster processors to make
up for sloppy code.  One of the groups that consumes the largest
amount of Cray time here at Sandia decided to switch to C++ to gain an
advantage in code maintainability, but this change is not for free.
One cost of C++ is that it hides the operations performed by Silicon
(a good example is the problem of temporary copies).  Another lies in
the fact that good (read efficient) C++ compilers are hard to come by.

I am always amused by the language wars.  It reminds me of the car
salesman that tries to sell me a two door because that is what he
sells, rather than what I need.  In the end the marketplace will
decide this issue, and I predict that Fortran, C, C++, and even Cobol
will find some prosperity in the future.  

Kevin McCurley
Sandia National Laboratories
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: Small Language Wanted
Keywords: modular programming
Date: 28 Aug 92 16:10:00 GMT
Distribution: na
Organization: Los Alamos National Laboratory


In article <8749@amsaa-cleo.brl.mil>, mcohen@amsaa-cleo.brl.mil (Marty Cohen) writes:
|> [...]
|> >And if the elimination of computed GO TOs will
|> >help make FORTRAN more structured, then you can simply not use them.
|> In Fortran 77 there is no way to code a while loop without using a GOTO.

In *NO* language is it possible to write a WHILE loop without a GOTO.
In most languages, this GOTO is *spelled* END WHILE (or in some similar
way).  To be sure, this is a much better spelling*(footnote).  But 
semantically, a WHILE loop *IS* the following:

   10 IF (cond) THEN              !WHILE
         ... body of loop ...
      GOTO 10
      ENDIF                       !END WHILE

Proper commentary will elucidate this further, and you should never
use the label as the target of any *other* GOTO.  

This whole debate about GOTOs is irrelevant to the question of whether 
Fortran programs (or those in any other language) are structured or not.

*(footnote): As I have stated before, it is my opinion that syntax
is probably the *most* important aspect of a language's design.  And
the lack of a WHILE loop is a very serious weakness to standard Fortran 77
(which is why most implementations - on mainframes anyway - already allow
DO WHILE --- ENDDO as an extension).  In spite of this weakness, Fortran
has syntactic *advantages* over other languages for scientific/numerical
work which offset it.

-- 
J. Giles
Xref: sparky comp.edu:1486 comp.lang.fortran:3379 comp.lang.misc:2891 comp.arch:9173 sci.math:10871
From: mike@majestix.cs.uoregon.edu (Michael John Haertel)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 2 Sep 92 18:04:45 GMT
Article-I.D.: majestix.MIKE.92Sep2100445
	<1992Aug27.154823.583@alchemy.chem.utoronto.ca>
	<1992Aug31.133811.3626@crd.ge.com> <25910@dog.ee.lbl.gov>
	<92245.124125KGZXK@ASUACAD.BITNET>
	<MEISSNER.92Sep1202838@curley.os
Distribution: na
Organization: CS Dept, University of Oregon

In article <MEISSNER.92Sep1202838@curley.osf.org> meissner@osf.org (Michael Meissner) writes:
> C++.

Ah, yes.  "The most complicated complex number extension ever invented
for any language."  (I first heard that from Bart Massey.)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
From: peter@ferranti.com (peter da silva)
Subject: Re: Scientists as Programmers
Organization: Xenix Support, FICC
Date: Wed, 2 Sep 1992 15:34:35 GMT

In article <1992Sep1.044840.2269@ccu1.aukuni.ac.nz> ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig) writes:
> There is, however, another aspect to this. Scientists usually view a
> program as a means to an end. Any time they spend on the niceties of
> program documentation, code cleanup etc. is going to come straight out
> of the time when they could have written that other publication or made
> these four extra experiments to check out that exciting new theory.

Hold that thought...

> Making life easier for someone who might someday come across a similar
> problem is not going to be high on their list of priorities.

But isn't *that* what publication is all about... making life easier for
someone else? If there were a mechanism to reward scientists for publishing
good software (and, no, I don't mean royalties, I mean publication credits
and tenure and the like) they would. And it would help advance science as
much as a paper on a new technique in electrophoresis.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.edu
Subject: Re: Scientists as Programmers
Date: 2 Sep 92 00:09:14 GMT
Organization: Commodore, West Chester, PA

1416@hubcap. <134918@lll-winken.LLNL.GOV>
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Followup-To: 
Distribution: 
Organization: Commodore, West Chester, PA
Keywords: 

miller@diego.llnl.gov (Patrick Miller) writes:
>Both writers have a point.  Computer science types can produce better,
>more elegant code because they understand the nature of _computing_,
>while physicists, chemists, etc... can write better codes because only
>they understand the nature of the _science_.

	Quite right.  The trick is to find a good way for them to work
together, and/or create physicist (or whatever)/programmer positions.
Physicists know what sort of data is likely, but not how to code cleanly;
and programmers know how to code cleanly, but don't know what characteristics
to expect from the data.  One thing that will certainly help is specifying
the parameters of the data better, and another may be expert systems to help
select the correct algorithms from packages (such as the old IMSL stuff).

	The other thing you have to watch out for is a program written for
certain types of data being reused for other data that doesn't meet the
original criteria of the algorithms used.  When writing scientific programs,
it might be good to try to put in checks to see if the data appears to be
"reasonable", and warn if there seems to be a discrepency.

	I suspect that with parallel programming becoming more important, new
languages will have to be designed to give non-computer-specialists more
support in developing parallel programs.  The scientists are going to have
to new ways of thinking about programs and numeric problem-solving.

-- 
"Rev on the redline, you're on your own; seems like a lifetime, but soon it's
 gone..."  Foreigner
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Newsgroups: comp.edu,comp.lang.fortran
From: gooch@leland.Stanford.EDU (Carl Gooch)
Subject: Re: Small Language Wanted
Organization: DSG, Stanford University, CA 94305, USA
Date: Wed, 26 Aug 92 19:55:51 GMT

In article <1992Aug25.154501.8654@colorado.edu> ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:

>I don't mean to sound like I'm running down scientists at all. I'm
>just saying that the problems lie not in our stars, but in ourselves.
>You can have good programs in any programming language, and bad
>programs ditto. It's more a function of the programmer's outlook and
>training than the programming language (IMHO). 

I'd agree with that.  If you're writing a piece of code that you know
will be 5000+ lines and that you're going to have to maintain and
improve for a long time to come, you write it reasonably well in
self-defense.  I'll grant that the definition of "reasonably well"
varies between individuals, but I doubt there are many large new
Fortran codes being written with flocks of arithmetic if's and
computed goto's.  

>I never use common blocks myself, ditto global variables (are their
>global variables other than in common blocks?). Subroutine arguments
>are always passed by reference, never value (how do you pass by
>value?). User defined data types (i.e. structures) are available in
>many implementations of FORTRAN (e.g. Sun), if you don't insist on
>standard FORTRAN 77, ditto for loop constructs. I have to say right
>here that I am talking about FORTRAN with extensions. I would never
>like to write in strict standard FORTRAN. But I think that commercial
>applications are rarely written in FORTRAN, and too many FORTRAN
>programmers don't use the language extensions, althought there is
>little chance they will ever have to port their code, and a good
>chance that if they do, the other machine will support the same or
>similar extensions.

It's true that common blocks don't help code readibility, but there
are cases where not using them requires passing a long list of
parameters several steps up and down a call tree.  In those cases, I
prefer to use common and pass only parameters which are immediately
relevant.  (I also declare common blocks and the variables contained
in them in include files, so that I never have to worry about my
declarations of the same common block conflicting.)

Extensions like do-while loops are common enough that I use them
freely, partly because in an emergency, the changeover to if ... goto
... wouldn't be very painful.  Structures I tend to avoid, in part
because that's a less common extension and in part because the changes
to unsnarl it would, generally, be rather large.  If I were writing
for a single platform, I'd be a lot less picky about extensions.

Your mileage, of course, may vary.

Carl



-- 
------------------------------------------------------------------------------
Carl Gooch                       |        Why am I inside at a keyboard when 
gooch@leland.stanford.edu        |        I could be outside riding bike?
------------------------------------------------------------------------------
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: ashok@regulus.Inria.Fr (Ashok Kumar)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: INRIA Sophia Antipolis, France
Date: Tue, 1 Sep 1992 08:53:02 GMT

In article <1992Aug31.195540.13074@ctr.columbia.edu>, shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:
> In article <1992Aug31.170849.11927@mprgate.mpr.ca> mcvey@mpr.ca (Iain McVey) writes:
> 
> >'Computing Science types' who truly understand accounting should write
> >better accounting packages, shouldn't they?
> 
> Well, there's variation person-to-person within all disciplines, and we've
> heard scientists and "computer science types" comment on how well, or
> poorly, scientists write code, but in my experience the implicit notion that
> "computer science types" are automatically good programmers is false.
> 
> In many or most CS departments, computer science has more to do with 
> proving theorems than writing code, and the experience obtained by
> students getting degrees, at whatever level, in these departments
> reflects the leanings of the department.
> 
> I've recently concluded that expecting a computer science graduate to
> be a good programmer is like expecting an English major to be a good
> writer.  Both expectations are, unfortunately, false.
> 
> No flames intended ....

I fully agree with you.To draw an analogy from Mech engg. a good mechanical 
engineer need not necessarily be a good machinist.He can design a good product
and leave the implementation on a lathe or a milling machine or what have you to a skilled machinist.Similarly a good architect or civil engineer need not be a 
good mason.So too with Computer Science,computer engineering and programming.I
have come across software engineers who are excellent in designing compilers,
operating systems but are lousy programmers.In fact some of the very good
programmers are B.S. in maths or physics.No amount of language design and research
can make good programmers of every one.As long as there is flexibility there will
be always a choice in the use of code and data structures and the way they are put
together and this will remain an art which only a few will master.
Xref: sparky comp.edu:1389 comp.lang.fortran:3256 sci.math:10664
From: ajtd@honey.st-and.ac.uk (Tony Davie)
Newsgroups: comp.edu,comp.lang.fortran,sci.general,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 28 Aug 92 14:36:05 GMT
Organization: St.Andrews University

In article <1992Aug27.154823.583@alchemy.chem.utoronto.ca>, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes:

> Scientists think that any code that executes
> correctly and quickly is OK.

How do they know it's correct?
From: rrw@elden.cse.nau.edu (Bob Wier)
Newsgroups: comp.edu
Subject: Revocation of accreditation?
Date: 28 Aug 92 21:59:02 GMT
Distribution: usa
Organization: Northern Arizona University, Flagstaff AZ
Originator: rrw@elden.cse.nau.edu

What with serious cutbacks being experienced in a number
of programs in higher education (including here), I wonder
if anyone can say whether there has been any history of
an early review or revocation of accreditation by some
of the usual bodies.  Since this is comp.edu, for example
would CSAB or ABET come in and reevaluate a program early
(say it had received a "6R") if cutbacks resulted in 1/2
the faculty being let go?

THANKS



 - Bob Wier

  ---------- insert favorite standard disclaimers here ----------
                   College of Engineering
      Northern Arizona University, Flagstaff Arizona
  Internet: rrw@naucse.cse.nau.edu | BITNET: WIER@NAUVAX | WB5KXH
Xref: sparky comp.edu:1510 comp.lang.fortran:3405 comp.lang.misc:2916 comp.arch:9202 sci.math:10928