HDTenEightyP/NetNews huggingface dataset:
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 3 Sep 92 13:44:38 GMT
Distribution: na
Organization: Purdue University Statistics Department

In article <1992Sep3.112944.20996@dbsun.uucp> meyer@dbsun.uucp (Don Meyer) writes:
>In article <2!ln9fc@lynx.unm.edu> john@aquarius.unm.edu (John Prentice) writes:
> [ re: C++ and complex numbers ]
>>Fortunately, you wouldn't need to because the designers were not brain
>>dead enough to leave in out in the first place :-) .

>'C' was intended as more of a systems language, in which case complex
>numbers aren't usually needed.  C++ extends C without any particular
>bias towards features for specific applications areas.  The philisophy
>of extending the language via librarys (which can function quite as
>nicely as built-in features) is a sound one.
>I would hardly characterize this _considered choice_ as "brain-dead".

This is not brain-dead, but it is certainly brain-damaged.  Inlining of
stuff from libraries has to be done at compile time, or at most at assemble
time, as at least the compiler needs to know how much space the inlined
code will take.  If every addition, etc., required a subroutine call,
the computer would run very much slower.  So one would have to use 
some type of language extension file at compile time, not libraries.

The present compilers translate such things as +, *, &, etc., into 
some version of assembler.  Why not allow the user to say how other
operations will be similarly translated, and add them to the list?
These operations often produce temporaries; why not tell the user
how this is done, and let them be added to the list?  These would
not really complicate the language design or the compiler, except
insofar as precedence is affected.

Now why did the C designers use the term "typedef" for what should have
been called "typealias"?  I have used Fortran compilers before the creation
of C which allowed a limited number of user-defined types.

This also affects hardware.  It does make a difference in the code for
a good program what operations are available and how long they take.
On some machines, multiplication and division have to be programmed.
There is generally no single algorithm optimal on all machines, so the
hardware considerations at least have to be known to the programmer.
-- 
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)
Newsgroups: comp.edu,comp.lang.fortran
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: scientists as programmers (was: Small Language Wanted)
Organization: Los Alamos National Laboratory
Date: Wed, 26 Aug 1992 17:10:32 GMT

In article <1992Aug26.102735.12519@wl.com>, schuette@wl.com (Wade Schuette) writes:
|> [...]
|> Can we focus some attention on what CAN and SHOULD be taught to the
|> scientists who would prefer to write good code and are reasonably bright
|> but extremely busy.  On a very practical, very pragmatic basis.
|> Suppose you can get 45 minutes of time, and hold a seminar on What every
|> scientist should know about computing but probably doesnn't... or some such.

Depending on the level of expertise and experience of the audience, this
is an easy question: for all but the most adept, the subject would be
the semantic properties of floating-point numbers.  Only for *very* 
advanced audiences would this be unnecessary instruction.

-- 
J. Giles
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: doconnor@sedona.intel.com (Dennis O'Connor)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Intel i960(tm) Architecture
	<1992Aug27.154823.583@alchemy.chem.utoronto.ca>
	<BtpAIn.EE5@mentor.cc.purdue.edu> <34742@cbmvax.commodore.com>
	<1992Aug31.133811.3626@crd.ge.com> <1992Aug31.135937.5
	<34799@cbmvax.commodore.com>
Date: Wed, 2 Sep 1992 22:30:00 GMT


 Can we please drop this thread, folks ?  I haven't seen an
 computer architecture issue addressed in it in along time.
 Thanks.
--
Dennis O'Connor			doconnor@sedona.intel.com
Xref: sparky comp.edu:1497 comp.lang.fortran:3394 comp.lang.misc:2903
From: zkdc05@trc.amoco.com (Kelly D. Crawford)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc
Subject: Re: sagans of lines of Fortran?
Date: 2 Sep 92 21:07:47 GMT
Organization: Amoco Production Company, Tulsa Research
Originator: zkdc05@church


In article <61115@aurs01.UUCP>, throop@aurs01.UUCP (Wayne Throop) writes:
> > From: zkdc05@trc.amoco.com (Kelly D. Crawford)
> > With trillions of lines of existing Fortran in the scientific
> > marketplace, it is a travesty not to teach CS students Fortran sometime
> > during their education.
> 
> Let's see... assume Fortran emitted at a furious continuous pace
> of 1000 lines/day, every day since 1960, and we get
> 
>                1e12 loc
>         divide 1e3  loc/developer-day   =  1e9 developer-days
>         divide 365  days/year          ~=  2739726 developer-years
>         divide  32  years (since 1960) ~=  85616 developers
> 
> or about 86 thousand Fortran-coding speed-demons continuously
> employed since 1960 for every trillion of those trillions of lines.
> 
> Impressive.

Wait, did you count comment lines?

> ( Yes, Kelly was probably being hyperbolistic... )

My mother has told me a trillion times not to exaggerate.

> On a more serious note, I tend to disagree that Fortran should
> necessarily be taught to all CS students.  It depends strongly
> what those CS students intend to specialize in.  Certainly
> bit bummers, toolsmiths, graphics gurus and other specialties
> would find Fortran relatively useless.  Certainly we don't teach
> our electrical engineers all about the properties of concrete,
> nor find it a travesty that this is not done.

Agreed.  I should qualify my statements better.  Those that intend to work
in scientific industry (or research) should have the exposure.  Perhaps a better
point here is that we should have more career electives.  Although the problem
there is that many CS majors don't necessarily have well defined career targets
("Why, I can go pretty much anywhere...right?").

In general, however, I like the idea of CS majors getting as much exposure to
different languages as possible.  Do this in one or two semesters if you must,
but do it if at all possible.  The most popular languages should be emphasized
most because they are the ones that CS majors will likely run into after graduation.

Oh, well.  Enough rambling.  I don't suppose you will ever get anyone to agree
completely on what should comprise a CS degree.  I definitely respect most of the
comments I have seen in this thread.  We have managed to get a lot of different
perspectives...

Kelly
-- 
Kelly D. Crawford             | Amoco Production Research | These are my own
kcrawford@trc.amoco.com       | 4502 East 41st Street     | opinions, not
phone: (918) 660-4043         | Tulsa, OK  74102          | Amoco's...
          >>> *** This line intentionally left blank *** <<<
From: bohy6489@iscsvax.uni.edu
Newsgroups: comp.edu
Subject: Re: Small Language Wanted
Date: 28 Aug 92 13:32:37 GMT
Followup-To: comp.edu
Distribution: na
Organization: University of Northern Iowa

In article <8749@amsaa-cleo.brl.mil>, mcohen@amsaa-cleo.brl.mil (Marty Cohen) writes:
> In Fortran 77 there is no way to code a while loop without using a GOTO.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

First off, the arguement was about *computed* GOTO's, which are *nothing* like
your average everyday GOTO.  Secondly, there are these really cool things
called COMMENTS (excuse the shout) that allow you to do things like:

C       while (i <= 3) do

      5 IF (I .LE. 3) THEN GOTO 10
        GOTO 20
     10 (insert your favorite thing to do if I <= 3 here)
        (more loop body)
        GOTO 5
     20 CONTINUE

C       Isn't that cool?

In fact, even though I have taught FORTRAN in the past using VMS FORTRAN (which
has DO WHILE loops), I use this.  It helps people *SEE* just how these loops
work, rather than drawing a bunch of arrows on the board or whatever.  I always
followup with DO WHILE, and encourage them to use DO WHILE.

> -- 
> Marty Cohen  mcohen@brl.mil  {uunet|rutgers}!brl!mcohen
> Custom House Rm 800, Phila. PA 19106 (215)597-8377 Fax (215)597-2240

===============================================================================
Jim Bohy                                        | "If you have to ask, you'll
Graduate Student - Computer Science Education   |  never know..."
University of Northern Iowa                     | 
Cedar Falls, IA  50614                          | - Louis Armstrong, when asked
bohy@att1.uni.edu                               |   what jazz is.
===============================================================================
Xref: sparky comp.edu:1417 comp.lang.fortran:3296 comp.lang.misc:2816 comp.arch:9101 sci.math:10728
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Rice University, Houston
Date: Tue, 1 Sep 1992 19:30:52 GMT

shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:

> 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.

I think your analogy is fairly accurate; but the word _unfortunately_
is perhaps unwarranted.

Programming is a skill.  Many people can learn to program, many people
can learn to read and write, and many people can learn to do algebra.
Further, I believe that many people _should_ learn to program so they
can get their work done in a timely manner.

A physicist who can program is useful, a chemist who can program is
useful, a musician who can program is useful; but a programmer with no
other ability is fairly useless.

Think of programming like reading and writing.  If someone comes to
you for a job, claiming they can read and write, you're usually
unimpressed.  You'd say: "Of course, so do we all.  What do you do
that I would pay you for?"

Computer scientists are different beasts entirely.  Some study
computer architecture, some study compilers, some study algorithms, so
study logic, and some even study how to program.

For many computer scientists, applications are not a goal; rather,
applications (real world programs) are a source of interesting and
important problems to attack.

In my case, I sometimes look at the output of optimizing compilers.
If I see inefficiencies in the generated code, I try and figure out
why the compiler did such a poor job and how it can be improved.  If
I find an improvement, then I tell people about it (i.e., give a talk
and/or write a paper).

Preston Briggs
Xref: sparky comp.edu:1492 comp.lang.fortran:3387 comp.lang.misc:2897 comp.arch:9178 sci.math:10894
From: meyer@dbsun.uucp (Don Meyer)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Keywords: uppity.uppity.uppity
Date: 2 Sep 92 19:40:11 GMT
Organization: BioMerieux-Vitek, St. Louis Mo.

[Begin uncalled for sarcasm]

On behalf of all the mere programmers, CS types etc. in the entire
world we grovel at the feet of the magnificent Physicists who condescend
to gift us with their presence.

[End uncalled for sarcasm]

Blech.  Sorry, but I've been following this conversation and finally
overloaded! :-)

The
 "We X's could learn how to do what you Y's do very easily, but
 it would be very hard for a Y to become an exalted X."
viewpoint gets old *real* fast.  I've heard this same argument applied
to hardware vs. software engineering, martial arts styles, etc. etc.

A good physicist worked hard and needs intelligence to do his thing.
A good programmer/analyst/computer scientist also works hard and
needs intelligence.  Each can learn enough of the other's field
to be as dangerous, competent, or expert as they desire.

Apologies to any realisticly egotistical physicists out there. ;-)

Don Meyer


-- 
-------------------------------------------------------------------------
meyer%dbsun.uucp@wupost.wustl.edu        |||     I am at two with nature.
Opinions expressed are personal.         |||       -- Woody Allen
Xref: sparky comp.edu:1409 comp.lang.fortran:3282 comp.lang.misc:2805 sci.math:10699
From: kers@hplb.hpl.hp.com (Chris Dollin)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 4 Sep 92 14:40:56 GMT
Distribution: na
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Followups-To: comp.lang.misc

In article ... fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

   C++ allows you to overload existing operators, although to make compiler
   writer's jobs easier, it does not allow you to introduce new operators.

Make that ``trivially easier''. So far as I am able to tell, the difficulty of
allowing the user to add new operator definitions is rather close to zero, so
long as this is taken into account *before* designing the language and
compiler. (C++ has the problem of trying to incorporate the lexical structure
of C.)

[I've attempted to divert followups to comp.lang.misc. If I've screwed it,
could other repliers please take my intentions into account? It doesn't seem to
have much to do with fortran, edu, or match now, and I'm dubious about the
architectural connection.]
--

Regards,    | Applicants must also have extensive knowledge of Unix,    | MIT
Kers.       | although they should have sufficiently good programming   | job
            | taste to not consider this an achievement.                | ad.
Newsgroups: comp.edu,comp.lang.fortran
From: fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: scientists as programmers (was: Small Language Wanted)
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 26 Aug 1992 15:25:21 GMT

john@spectre.unm.edu (John Prentice) writes:

>My final comment is my stock one about Fortran.  Continuing to
>debate the pros or cons of Fortran 77 is a cheap shot, not worthy
>of serious discussion.  Fortran 77 is out of date, everyone agrees
>with that.  Fortran 90 is a modern language, with certainly as much
>claim to that title as languages like C.  You can argue the merits
>of some of what is in Fortran 90, and I would welcome such a
>discussion.  But at least we would then be debating where the
>scientific programming community is today, not where it was 20
>years ago.

Continuing to debate the pros or cons of C is a cheap shot, not worthy
of serious discussion. C is out of date, everyone agrees with that.
C++ is a modern language, with certainly MORE claim to that title
than languages like Fortran, even Fortran 90. You can argue about
the relative merits of C++ vs Fortran 90, and I would welcome such a
discussion. But at least we would then be debating the languages of 
today, not those of 20 years ago.

:-) :-) :-)

P.S. At my institution, Fortran is taught in from 2nd year onwards,
while C++ is not taught at all. However they still teach Fortran 77,
and we do not have any Fortran 90 compiler. In contrast despite C++
not being taught at all we have not one but two C++ compilers.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.edu,comp.lang.fortran,sci.general,sci.math
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Department of Chemistry, University of Toronto
Date: Thu, 27 Aug 1992 15:48:23 GMT

In article <1992Aug26.192410.6523@ultb.isc.rit.edu> jsvrc@rc.rit.edu
(Doctor FORTRAN) writes:
>In article <1992Aug25.154501.8654@colorado.edu> ejh@khonshu.colorado.edu
>(Edward J. Hartnett) writes:
>> [. . . . ] I think that
>>what you are seeing is not that FORTRAN lends itself to rotten code,
>>but that scientists usually write bad code, in whatever language they
>>use. No offense to scientists, but I have rarely if ever seen a
>>scientist who was a good programmer.
>
>But I must disagree when you characterize
>scientists as bad programmers. That's bigotry, and a stereotype to which I
>must strenuously object.

     It's not bigotry, it's a sociological generalization applicable to
the vast majority of scientists who write computer programs.  You should
see the things I've seen...
     Edward wasn't trying to insult anyone.  He correctly identified the
source of the problem:  Scientists think that any code that executes
correctly and quickly is OK.  What it looks like and whether it would
meet with the approval of CS weanies is completely irrelevant
to us.  Of course, that also means that our "one-shot" code had better
never need to be tweaked.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca
Xref: sparky comp.edu:1500 comp.lang.fortran:3396 comp.lang.misc:2906 comp.arch:9185 sci.math:10912
From: rons@hardy.u.washington.edu (Ronald Schoenberg)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 3 Sep 92 02:03:55 GMT
Article-I.D.: u.1992Sep3.020355.20338
Distribution: na
Organization: University of Washington, Seattle

In article <MIKE.92Sep2100445@majestix.cs.uoregon.edu> mike@majestix.cs.uoregon.edu (Michael John Haertel) writes:
>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.)

Yeah, but in C++ if you don't like the implementation you can write
your own.  Would you be able to do that in Fortran 90?
Xref: sparky comp.edu:1408 comp.lang.fortran:3281 comp.lang.misc:2804 sci.math:10695
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: scientists as programmers (was: Small Language Wanted)
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Wed, 26 Aug 1992 11:32:15 GMT
Organization: University of Auckland, New Zealand.

schuette@wl.com (Wade Schuette) writes:

>Suppose you can get 45 minutes of time, and hold a seminar on What every
>scientist should know about computing but probably doesnn't... or some such.

[...]

>Or maybe, this: if you had ONE thing you could try to get across, that would
>make sense to that audience in that time frame, what would it be?

Probably, the one thing I would try to get across is: If you have that
problem, chances are other people have stumbled across it before. See
wether you have part of the solution already handy, in the shape of
NAG, IMSL, or Netlib, or somewhere in your own department. Make sure
that software which gets written is reusable; make the writers DOCUMENT
their stuff.

Oh yes, and make the people use either straight SI units (without any
multiplicators) or dimensionless numbers. I recently had to wade through
a lot of subroutines which were calculating phyiscal properties of
substances; unfortunately, the author had neglected to write down the
dimensions. He had used kJ, diffusion coefficients in cm^2/s,
temperatures in both Kelvin and deg C, pressure in bar, ... wading
through all that almost took as much time as rewriting it from scratch.
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
Xref: sparky comp.edu:1422 comp.lang.fortran:3299 comp.lang.misc:2818 comp.arch:9103 sci.math:10735
From: miller@diego.llnl.gov (Patrick Miller)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers
Date: 31 Aug 92 16:28:36 GMT
Followup-To: comp.edu
Organization: Lawrence Livermore National Laboratory

|> davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
|> ... To do this even competently is a skill which
|> conspicuously eludes most people who don't write code for a living, and
|> to do this with consummate skill requires training, practice, and a
|> natural talent given to only a few people. 

In steve@hubcap.clemson.edu ("Steve" Stevenson) writes:
|> My experience is that most computer science types would not know the best
|> numerical algorithm because they don't understand the science. The problem
|> continues to be that scientific codes are meant to deal with nature and
|> that takes someone who understands the problem. ...
------------------------------------------------------------
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_.

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.
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
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
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).

-- 
Pat Miller				 Computing Research Group
patmiller@llnl.gov                   Lawrence Livermore Natl Labs
Opinions are my own, and don't necessarily reflect the views of the Lab.
Xref: sparky comp.edu:1490 comp.lang.fortran:3384 comp.lang.misc:2895 comp.arch:9177 sci.math:10885