HDTenEightyP/NetNews huggingface dataset:
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc
Subject: Re: sagans of lines of Fortran?
Date: 2 Sep 92 20:03:15 GMT
Organization: Purdue University Statistics Department

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.

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

Not by too large a factor.  I would not be surprised it more than 10,000
students were writing Fortran at each of the 100 largest universities in
this country.  This would give a good million developers.  With that 
number of people writing Fortran, the other figures could be relaxed.
-- 
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: schuette@wl.com (Wade Schuette)
Subject: Re: scientists as programmers (was: Small Language Wanted)
Organization: Warner Lambert / Parke-Davis
Date: Wed, 26 Aug 1992 10:27:35 GMT

In article <1992Aug25.202307.12365@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>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
>...[stuff deleted]
>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.


OK, so having gone back and forth, maybe we have a sense now that there
are scientists who write good code and scientists who don't, perhaps in
a different ratio than people who spend more time focusing on programming
issues. 

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.

One shot.  The room is impatient. The top people are late. (the projector
doesn't focus.) Now what?  This is a serious question, as I'd like to do
precisely this, for an audience of primarily biological / chemical 
researchers.  Software Engineering 101, extremely applied, for people
heavily into Fortran and "getting results today."

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?

 
-- 
==================================================================
R. Wade Schuette         schuette@wl.com    Ann Arbor, MI, USA
Newsgroups: comp.edu,comp.lang.functional,comp.lang.misc,comp.parallel
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: Small Language Wanted
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Tue, 25 Aug 1992 22:53:01 GMT
Organization: University of Auckland, New Zealand.

ejh@khonshu.colorado.edu (Edward J. Hartnett) writes:

>I never use common blocks myself, ditto global variables (are their
>global variables other than in common blocks?).

I take it you never use any NAG, IMSL or similar routines, then. If, for
example, you want to call a general - purpose root finder, you will have
to pass it the function to be solved, via an EXTERNAL argument. If you
you want to communicate with that function, COMMON (which is indeed the
only kind of global variable FORTRAN supports) is the only way to do it.
-- 
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.
Newsgroups: comp.edu,comp.lang.fortran
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: scientists as programmers (was: Small Language Wanted)
Organization: UIUC SCS
Date: Wed, 26 Aug 1992 13:39:22 GMT

In article <l9lrciINNb7b@almaak.usc.edu> ajayshah@almaak.usc.edu (Ajay Shah) writes:

>jlg@cochiti.lanl.gov (Jim Giles) writes:

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

>I agree with the original poster -- in general good scientists are
>focussed on their application areas and simply don't invest in knowing
>about computers.  Long experience often makes them good coders, but
>rarely good programmers.

That's an odd thing to say. If you write good code, you by definition 
**are** a good programmer!! As the code **is** the program.


>Look at the accent on fortran, for example:
>how could a good programmer possibly use fortran? 
Why not? It (i.e. Fortran 77) is just fine for most scientific calculation
purposes. Its not really good, it is true, for complex user interaction 
tasks. But if your particular computer has calls to non-blocking input
and c-style output, its still doable.

Doug McDonald




 It has to be the
>case of a person who wants to get a job done and doesn't take interest
>in the means.

>There are exceptions, of course.  Generally coinciding with the trend
>away from fortran.

>No .edu bias that I can see in this phenomenon.

>        -ans.


>-- 
>Ajay Shah, (213)749-8133, ajayshah@usc.edu
Newsgroups: comp.edu,comp.lang.fortran
From: schuette@wl.com (Wade Schuette)
Subject: Re: scientists as programmers 
Keywords: supercomputer Fortran self-modifying-code AI Japanese Supercomputing
Organization: Warner Lambert / Parke-Davis
Date: Wed, 26 Aug 1992 02:24:58 GMT

In article <1992Aug25.202307.12365@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>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....


I'd pick up on that last point with a tangent on supercomputer and 
parallel computer compilers and languages, including Fortran.
Japan apparently is far ahead of the US in terms of making complex
technology friendly to mortals. This may have changed (?), but as
of a few years ago the percent of Japanese scientists who used 
supercomputers was WAY ahead of the percent in the US, and the 
reasons seemed to be that the Japanese didn't expect the _SCIENTIST_
to have to learn how to parallelize his/her code, as the compiler
did that. So the physicist or biologist could work on their work,
not spend weeks in sessions on learning how to write paralle fortran.




Has that changed?

For that matter, does anyone know if the current supercomputer
compilers are bright enough to watch their own output actually run
and learn from it so on their NEXT pass they can stop guessing and 
make better decisions as to how to optimize the data-dependent sections
of code?  Or are humans still supposed to do THAT as well?  I never
could understand why code intended to be run ten million times couldn't
watch its own work a little and adjust bad decisions made in earlier
compiles.  Sometimes it wouldn't converge, but I'd think a lot of 
programs run almost identical jobs (just as poorly) over and over and 
over on almost identical data sets. 

Seems like a small amount of applied AI could have a large impact on 
such code.  Also seems that the supercomputer is the only thing around
smart enough to watch itself and handle this adjustment, and not only
no scientist outside the field, but almost no human inside the field 
could track the algorithms to do this by hand after the fact. 


 

Comments?
-- 
==================================================================
R. Wade Schuette         schuette@wl.com    Ann Arbor, MI, USA
From: kling@ics.uci.edu (Rob Kling)
Subject: Re: wanted: handout on basics of scholarly writing
In-reply-to: Your message of 31 Aug 92 21:24:50 +0000.
             <1992Aug31.212450.21427@cybernet.cse.fau.edu>
Newsgroups: comp.edu
Date: 31 Aug 92 22:19:37 GMT


Hi .... I sympathize w/your predicament. If these are PhD students, -
they could usefully invest in a copy of the Chicago Manual of Style.
It's hardcover ... and costs over $25 I believe,  but would be a solid
reference book that would be useful for well over 10 years ....

The American Psych Assn has a less expensive style manual ... that is also_
much less general.

I'd be interested in learning what you end up using.

Best wishes,

Rob Kling
UC-Irvine
From: giber@pollux.cs.uga.edu (Carolyn Giberson)
Newsgroups: comp.edu
Subject: lab science requirements for programmers
Date: 1 Sep 92 14:34:16 GMT
Organization: University of Georgia, Athens
Originator: giber@pollux


The comment I'm responding to is the question about why somebody
intent on a programming career needs 2 semesters or quarters of
a lab science.  As a teacher at a small college, I think every
person with a college education needs to be exposed to a lab
science at some point in her/his academic career for several
reasons:  [1]  for a well-rounded education;  [2]  technology is
moving so rapidly, we're having trouble "keeping up" with the
rapid pace of changes in the world and society.  Citizens are
going to be asked (at the ballot box) to make decisions on the
future of technologies like genetic engineering, nuclear power,
etc.  A person needs some background in the sciences to make
well-considered choices on issues like this;  [3]  many computer
applications deal with scientific issues;  without understanding
the underlying principles/concepts, it would be difficult for
a programmer to program the "best" or "most efficient" solution
to a problem.  (Please note that the same argument can be applied
to other necessary disciplines such as math, English, etc.)

As a chemist pursuing a degree in computer science, I can see both
sides of this issue.  But I find blanket generalizations like "scientists
think/act/program this way" not useful at all.  Please don't group
all scientists together like this and decide how we behave!  Some
of us enjoy combining disciplines and consider a well-written,
well-structured, well-documented program a thing of beauty!

Carolyn Giberson
giber@pollux.cs.uga.edu
University of Georgia
Newsgroups: comp.edu,comp.lang.fortran
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Modern languages: F90, C++, etc... (Was: scientists as programmers)
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 27 Aug 1992 05:11:37 GMT

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

>I think a more interesting issue is not C++ versus F90, if one wants
>to frame it as a versus sort of issue, but rather the general idea 
>of OOPS versus conventional languages.

Actually I think that C++ would be a good language to use even if you
*didn't* use any of the OOP features, ie. just using C++ as a better C.
Just grab M++ or some other class library off-the-shelf and then
use C++ like a conventional language.

Then the extra features of C++ are available if you need them.

>I happen to think there is alot of merit in OOPS and I think it has an
>unquestioned place in scientific computing.  However, I also think it
>is overhyped very often.

Yes, any new techniques in computer science are ALWAYS over-hyped.
OOP is not a panacea that will suddenly make programming complex systems
easy. However it *is* a significant improvement in the same way that
structured programming was a significant improvement over previous methods.

>For example, one of the common claims for OOPS being the method
>of choice for parallel computing is that you can easily hide the 
>underlying machine architecture from the programmer.  This is said
>to be good because it relieves the programmer of having to worry about
>that architecture and promotes portability.

If these are your goals, then it is can be good for these purposes.

>The problem is that it
>also promotes code inefficiency since the programmer, who understands
>the data and logic structure of his code very well, is not able to
>direct the computer to exploit that structure as efficiently if he
>can't get to the underlying parallelization software.  The idea of
>hiding the nature of the computer from the programmer is not a bad
>one for users doing small computing, but it is not acceptable when each
>of your calculations takes 50 hours of Cray Y-MP or CM time.

If minimizing machine cycles is your goal, then of course programmers
will have to program at a lower level.

>So it is not that OOPS is bad, it is just that like everything, it has
>a time and a place.

Absolutely.

-- 
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
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Thu, 3 Sep 1992 22:40:03 GMT
Organization: University of Auckland, New Zealand.

dik@cwi.nl (Dik T. Winter) writes:

>Surprise, also Bubble sort has its place!  I once did code for the
>singular value decomposition.  At the end of the routine the singular
>values are sorted (because most people expect this).  I deliberately
>chose Bubble sort because the code is short.  That its order is n^2
>is not important as the order of the decomposition is n^3 for square
>matrices.  It would be silly to invest time to implement better sorting
>methods at that place.

Argl. There are better n^2 algorithms out there, for example insertion
sort, and that is as short to implement.
-- 
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:1371 comp.lang.fortran:3209
From: pawlak@vxdesy.desy.de
Subject: Re: Small Language Wanted
Followup-To: comp.edu
Organization: (DESY, Hamburg, Germany)
Date: Wed, 26 Aug 1992 15:18:18 GMT

In article <WVENABLE.92Aug26154731@algona.stats.adelaide.edu.au>, wvenable@algona.stats.adelaide.edu.au (Bill Venables) writes:
>>>>>> "Michal" == pawlak <pawlak@vxdesy.desy.de> writes: 
> 
> Michal> ... about 70% of the C code I had to work with was 
> Michal> badly written because of:
> Michal> - ...
> Michal> - making use of case sensitivity (i.e. symbols 'value' and 'Value' in the
> Michal>   same program)
> Michal> - ...
> 
> I'll accept all the other points, but NOT this one.  The concept of "case"
> is a printing artefact and makes no sense in this context.  What's wrong
> with using all 52 letters in the character set?  What could be more natural
> than using "x" for a singly indexed array and "X" for a doubly indexed one?
> 
> Most versions of Fortran now do allow mixed case input (thank goodness -
> otherwise you would go deaf reading the stuff) but then to regard "i" and
> "I" as the *same* is a absolute gotcha.
> 
> It's case INsensitivity that is the real syntactic curse in any language
> (or operating system for that matter).

Did you ever try to DISCUSS your code with someone? How do you pronounce
capital letters then? Some people have 'verbal' memory (me for instance)
- I remember the word, not its graphical representation (therefore I also
have a lot of trouble if 'unnatural' identifiers are used). What to do
with such people? They will guaranteed mix such symbols... MixeD cASe
inPUT? YES! cASe seSitIviTy? NO!

Besides, with 31 letters allowed in identifiers I have 26^31 possible
identifiers (forgetting $, _, digits, shorter ones, etc). I don't really 
feel I need more so urgently...

						Michal
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Dept. of Chem, Barnard College, Columbia U, New York
Date: Mon, 31 Aug 1992 19:55:40 GMT
X-Posted-From: avogadro.barnard.columbia.edu
X-Posted-Through: sol.ctr.columbia.edu

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

	-P.
-- 
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb*************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027
(212)854-1418    shenkin@avogadro.barnard.columbia.edu   shenkin@cunixf.BITNET
******************** The singular of "media" is "medium". ********************
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 15:59:46 GMT

In article <l9lrciINNb7b@almaak.usc.edu>, ajayshah@almaak.usc.edu (Ajay Shah) writes:
|> [...]
|> I agree with the original poster -- in general good scientists are
|> focussed on their application areas and simply don't invest in knowing
|> about computers.  Long experience often makes them good coders, but
|> rarely good programmers.  Look at the accent on fortran, for example:
|> how could a good programmer possibly use fortran?  It has to be the
|> case of a person who wants to get a job done and doesn't take interest
|> in the means.

A good programmer *can* use *any* language and always picks the one
best suited to his task (Fortran in the case of scientific/numerical
work).  A good programmer would *never* even use the argument that
language choice is a measure of *programmer* quality.

-- 
J. Giles
Xref: sparky comp.edu:1332 comp.lang.fortran:3158
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: Small Language Wanted
Date: 25 Aug 92 20:44:19 GMT
Article-I.D.: geech.BURLEY.92Aug25164419
Followup-To: comp.edu
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: tholen@galileo.ifa.hawaii.edu's message of 25 Aug 92 09:56:23 GMT

Presumably people complaining about Fortran's "computed GOTOs" really mean
_assigned_ GOTOs, right?  I mean, computed GOTOs are fairly easy to figure
out; they're just a SELECT CASE with automatic "GOTO label" filled in for
each case from 1 to N.  Assigned GOTOs, on the other hand, as in "GOTO I",
are really bizarre and hard to read and maintain, and often are used to
implement "inline subroutines" and the like.

Given SELECT CASE in F90, one doesn't really need computed GOTOs, but they
aren't really bad for readability.  But assigned GOTOs are really a pain
for everone, programmer and implementer both!
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
Xref: sparky comp.edu:1403 comp.lang.fortran:3271 comp.lang.misc:2798 sci.math:10684
From: bwalker@nosc.mil (Beth Walker)
Newsgroups: comp.edu
Subject: Re: Keyboarding
Date: 26 Aug 92 15:28:41 GMT
Organization: Naval Ocean Systems Center, San Diego

In article <25AUG199215042556@deimos.ucc.umass.edu> 
s8486534@deimos.ucc.umass.edu (PRESCOTT SMITH) writes:
>    Can't imagine anyone's doing "straight" typing anymore, even with a
>word processor, let alone emacs or other text editors which most of us have
>to use on a mainframe.   School children are into logo and pascal!
>
Still, if you are writing a book report, essay, etc., the majority of
the effort will be in typing the text, not in using special key 
sequences.  (Of course, I use a MacIntosh for most of my work so I 
don't need to learn funky key sequences for special editors like Emacs
(little smiley)).  I do program, or at least I do when they let me, 
but the 'special' sequences are often done with the mouse - not the
keyboard.  Yes, Copy and Paste can be keyboard functions, but these
sequences will be different for every editor you use (unless its a 
Mac).  

If you are addressing these types of special sequences, I can't see
any use in 'teaching' them to students, since they will have to use a
variety of editors.  I was simply speaking about the enhanced speed
a student who knows touch typing will have over a pure hunt n peck
typist for typing in text.
Newsgroups: comp.edu