HDTenEightyP/NetNews huggingface dataset:
From: jacobsd@prism.cs.orst.edu (Dana Jacobsen)
Newsgroups: comp.edu
Subject: Re: Are programmers Computer Scientists?
Date: 4 Sep 92 01:36:49 GMT
Article-I.D.: CS.1992Sep04.013649.14393
Organization: Oregon State University, Computer Science Dept

In <1992Sep3.174548.29169@ulowell.ulowell.edu> wex@cs.ulowell.edu (Paul M. Wexelblat) writes:
>The (quite valid) question raised is whether Fortran should be
>taught to CS students.

  I think all CS students should have the opportunity to learn FORTRAN,
but I won't argue that they must.  If they go into fields where they
work with engineers (traditional) or hard sciences, they will encounter
it.  If they have a decent CS background, they won't be too slowed down,
but it would help.

>My question is: 

>	Just because someone programs (is required to program)
>	a. Is that person a Computer Scientist
>	b. Should that person be called a Computer Scientist.

>	-or- 
>	are all programmers Computer Scientists?
>	[are all programming courses CS courses?]

  If I am required to pour cement, can I call myself a Civil Engineer?
(Well, of course -- I can call myself God, but that doens't mean I'll
get live sacrifices!  You know what I mean!)  The point is that to me
(a Computer Scientist), programming is the applied part of the field,
but there's more to it than that.  I programmed for many years before
I went to college, but I wouldn't have called myself a computer scientist.
That involves having a background in data structures, algorithms, some
idea of how hardware and software interact (ie numerical analysis),
software engineering, etc.  Just because I can give you an appendectomy
doesn't mean I'm a Medical Doctor.  There's a little more to it.

  Are all programming courses CS courses?  No.  Often other departments
will offer "applied programming" courses, which might be of more benefit
to students in their field.  CS classes will talk about how the features
of this language relate to others, and how to fit your problem to the
style of this language, and other theoretical things, which someone who
just wants his DiffEQ solved could care less about!  Of course not all
CS classes are CS classes... :-)
--
Dana Jacobsen                       I that wes in heill and gledness
jacobsd@cs.orst.edu                   am trublit now with gret sikness
jacobsd@solar.cor2.epa.gov              and feblit with infirmetie
Computer Sciences Corporation             Timor mortis conturbat me.
Xref: sparky comp.edu:1428 comp.lang.fortran:3309 comp.lang.misc:2825 comp.arch:9108 sci.math:10753
From: sog@craycos.com (Steve Gombosi)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 31 Aug 92 20:44:26 GMT
Organization: Cray Computer Corporation

In article <1992Aug31.170849.11927@mprgate.mpr.ca> mcvey@mpr.ca (Iain McVey) writes:
>In article <1992Aug31.144045.11416@hubcap.clemson.edu> steve@hubcap.clemson.edu ("Steve" Stevenson) writes:
>>The problems keep getting
>>worse as more university dumb-down the CS curriculum.
>
>
>Getting people who can function in more than one discipline is more than
>half the battle these days.

Getting people who can read and write is half the battle these days.

>Finding BSc's who even know what a vector processor is can be a
>hard enough battle.  

Having recently encountered honors graduates in "Computer Science" who were
not entirely sure exactly what an assembler is makes me despair of finding
BSc-s who understand vector processing. Perhaps things are better in
Canada...

Steve
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math,sci.edu
From: pattis@cs.washington.edu (Richard Pattis)
Subject: Re: programming languages, education, unanswered questions, loose threads
Summary: Knocking Ada
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Fri, 28 Aug 92 00:32:49 GMT

In article <1992Aug27.164424.249@linus.mitre.org> crawford@church.mitre.org (Randy Crawford) writes:
>...  Ada is too complex and few compilers are available/affordable on personal
>computers.

It isn't too complex for 1,500 introductory students/year at University of
Washington to learn.  And 50 or so other schools start with Ada also. Sure our
students struggle - about the same amount as I saw them struggle with Pascal.
We look at Ada as an improved and stardardized version of Pascal. In the first
quarter, students learn to read/write packages, handle exceptions, and use
unconstrained arrays, to name a few interesting Ada features. Oh, they actually
use these features in programs too: like writing a portfolio manager that
monitors simulated trends while buying and selling stocks.  In the second
quarter they learn to instantiate and write generic packages that export
private types.  This supplies them with a concrete way to implement, use, and
reimplement ADTs. 

OK, enough cheerleading here. I'm not advocating anyone use Ada, but I also
want to clear the record, at least from one school's perspective, about the
complexity of Ada. Sure we don't teach many parts of Ada (tasking) but it
doesn't get in the way. Our students write solutions to the same assignments
we assigned when we taught Pascal, and do so with less effort.

Our students buy Meridian and Alsys PC compilers; the former is available for
$60 through a site license (regularly $89, I think). The latter is available
to students for a little over a hundred dollars. There is a free DOS and Unix
Ada interpreter from NYU. They are also creating a GNU product.

Rich Pattis
-- 
------------------------------------------------------------------------------
  Richard E. Pattis			"Programming languages are like
  Department of Computer Science	 pizzas - they come in only "too"
    and Engineering			 sizes: too big and too small."
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: jimr@col.hp.com (Jim Rogers)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: Mon, 31 Aug 1992 14:22:33 GMT
Organization: HP Colorado Springs Division

jesup@cbmvax.commodore.com (Randell Jesup) writes:
> 	Not every language is appropriate for every job, which is what I
> think people told you last time this came up.  If there are specific problems,
> give examples.  Also, I suspect that a large part of it is that (not
> suprisingly) scientists don't want to learn N languages, they want a kitchen-
> sink that does it all, AND they want it to be simple, AND they want it to
> generate the tightest code theoretically possible.  This is like the old
> cliche: fast, small, soon, pick any 2.  Those requirements are pretty close
> to contradictory (certainly wanting all of them will greatly increase to
> cost to produce any such compiler, if it can be done at all).
> 
Since we are speaking to Physicists we might remind them that the
Heisenberg Uncertainty Principle applies to language design as well as other
facets of reality.
-- 
Jim Rogers
Hewlett-Packard Company

jimr@col.hp.com
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: ak45ldp@Texaco.com (Larry D. Pyeatt)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Texaco
Date: Mon, 31 Aug 1992 18:48:05 GMT

In article <1992Aug31.144045.11416@hubcap.clemson.edu>, steve@hubcap.clemson.edu ("Steve" Stevenson) writes:
|> davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
|> 
|> >  No optimizer will ever replace using the right algorithm to solve the
|> >problem, no programming tool will ever generate meaningful names, no
|> >automated indenter or pretty-printer will ever generate useful comments
|> >or truly readable code. 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 consumate skill requires training, practice, and a
|> >natural talent given to only a few people. 
|> 
|> 
|> My experience is that most computer science types would not know the best
|> numerical algorithm because they don't undertand the science. The problem
|> continues to be that scientific codes are meant to deal with nature and
|> that takes someone who understands the problem. The problems keep getting
|> worse as more university dumb-down the CS curriculum.

I am afraid that I have to agree.  There is very little consensus about 
what courses a CS degree should require.  For my own degree, we were 
required to take Calculus III, Physics, Chemistry, EE and other science and
engineering courses.  However, I have seen many CS graduates from other 
schools who are little more than glorified COBOL programmers.  It really
annoys me to be lumped in with them.  There is a wide variation in  the
quality of CS degrees.  If you are unhappy with CS graduates, you need
only look to another university.

|> To paraphrase Mark Twain, comments written by someone who doesn't know
|> the science is not likely to be interesting.
|> -- 
|> ===============================================================================
|> Steve (really "D. E.") Stevenson           steve@hubcap.clemson.edu
|> Department of Computer Science,            (803)656-5880.mabell
|> Clemson University, Clemson, SC 29634-1906

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.
Newsgroups: comp.edu
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Computer Science, University of Melbourne, Australia
Date: Wed, 2 Sep 1992 23:37:09 GMT

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

>In article <1992Sep2.090541.29304@st-andrews.ac.uk> ajtd@honey.st-and.ac.uk (Tony Davie) writes:
> > In addition, many of the best non-numerical algorithms seem to be neglected.
> > Bubble sort STILL seems to be the most used sorting method, for instance.
>
>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.

It would be silly to invest time in implementing ANY sorting method!
A much simpler, easier, and usually more efficient method is to simply
call the sort routine in the standard library... <flame bait follows>
or don't you Science types know anything about code re-use?
<end flame bait> ;-)

-- 
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,comp.lang.misc,comp.arch,sci.math
From: declrckd@rtsg.mot.com (Dan J. Declerck)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Tue, 1 Sep 1992 18:56:22 GMT

Some of the students with the highest GPA's could barely get the 
projects done to pass the class. Real-world aptitude is sometimes rare
to find. 

Another area I find students lacking is in formal large project communication
experience (basically software engineering in large teams). Universities
should teach more software engineering/design engineering.
How this relates to comp.arch is in the process of design where concurrent 
engineering can take place. 

Maybe some of our esteemed colleagues in the processor design fields can
shed some light as to how much concurrent engineering is done on a project.

A good example would be C compiler developers building code generators while
silicon has not been built. Then to run the compiled code on some sort of
gate-array prototype for conformance testing.
-- 
=> Dan DeClerck                      |  EMAIL: dand%isdgsm@rtsg.mot.com   <=
=> Motorola Intl Subscriber Group    |                                    <=
=>                                   |  Phone: (708) 632-4486             <=
----------------------------------------------------------------------------
Xref: sparky comp.edu:1537 comp.lang.fortran:3430 comp.lang.misc:2936 comp.arch:9233 sci.math:11001
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: 4 Sep 92 17:23:46 GMT
Article-I.D.: mentor.Bu2DnM.J4E
Distribution: na
Organization: Purdue University Statistics Department

In article <1992Sep4.114720.25228@dbsun.uucp> meyer@dbsun.uucp (Don Meyer) writes:
>In article <Bu08uF.HBC@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>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.

>If you don't have floating point hardware, or if the precision need
>surpasses that of your floating point hardware you will almost
>certainly have a subroutine call made by the compiler anyway.
>This is an optimization/compiler-quality issue as opposed to
>a pure "language" issue IMHO.

This is not necessarily the case.  At least on some machines, one can
handle twice that precision without calling a subroutine for floating
point operations.  For integer even triple and quadruple precision 
often should be programmed without a subroutine call.

-- 
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)
Xref: sparky comp.edu:1337 comp.lang.fortran:3169
From: langston@memstvx1.memst.edu (Mark C. Langston)
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: scientists as programmers (was: Small Language Wanted)
Date: 26 Aug 92 00:02:05 -0600
Distribution: world
Organization: Memphis State University

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.

I don't think one could segregate along *.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

I think there is a trend towards scientists in general starting to write
code.  Whether it is _good_ code, however, is another subject.  But, if
these scientists are going to have to re-use, modify, adapt, or port their
code, they will soon learn that some techniques are cleaner than others.

True, many scientists haven't taken the time to take a programming course.
But then, isn't experience the best teacher?  How many wonderful programmers
do you know that got that way without years of personalo problem-solving
code development?

And, being a good programmer has never been a prerequisite for being a
good scientist...just makes it easier, sometimes.  And the more computer-
literate scientists there are, the more scientists with good programming
skills will emerge.


-- 
+--------8<------Cut Here------8<------Cut Here------8<------Cut Here---------+
  Mark C. Langston   |  "Secrecy is the beginning of tyranny."                 
  Psychology Dept.   |  "Always listen to experts.  They'll tell you what can't
  Memphis State U.   |     be done, and why.  Then do it."                      
      "Pftph!"       |           -From the notebooks of Lazarus Long         
Xref: sparky comp.edu:1328 comp.lang.fortran:3150
From: xrcjd@resolve.gsfc.nasa.gov (Charles J. Divine)
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: Small Language Wanted
Date: 25 Aug 92 18:52:54 GMT
Organization: NASA Goddard Space Flight Center, Greenbelt MD

In article <1992Aug25.034553.2990@linus.mitre.org> crawford@church.mitre.org (Randy Crawford) writes:
>I don't believe it's possible to write modular FORTRAN code:
>at least, I've never seen it.  And unless FORTRAN 90 eliminates constructs
>like computed gotos, FORTRAN code will never become structured or modular.

Perhaps we have different understandings of the words structured and
modular.  But the place I worked at for most of the 80s insisted that
FORTRAN programs be structured and modular.  After several years of 
trying to fix code that _was_ a rat's nest, management opted for the
structured, modular approach.  Since this place was hardly cutting
edge, I assumed they took their ideas from elsewhere.  Yes, computed
gotos are a mess -- but programmers, analysts and management can
choose to not use them (which is what has happened at many places).

>I think the real advantage that C has over FORTRAN (and Pascal has over C) is
>especially among undisciplined numerical programmers, where the "better" 
>language allows sufficient expressiveness to solve the problem, yet less 
>opportunity to write bad code.  And it's easier for "part-time" programmers to 
>write bad code in FORTRAN than in C.

In many ways FORTRAN is more forgiving than C.  For people who are
writing smaller programs (most of the programs I see here are written
by scientists and engineers and are quite small), the limitations of
FORTRAN are no real problem.  Learning a new computer language can be
quite daunting for the part timer.  I've written some elegant C
programs -- but then I make my living at it and I had the time to
really learn C.  I still remember both how much freedom I had when
I began writing in C -- and how often I made subtle errors that 
produced results at variance with what I wanted.

A colleague compares C to a high performance sports car -- brilliant
performance, no brakes.



-- 
Chuck Divine
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
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: 1 Sep 92 21:33:31 GMT
Organization: Purdue University Statistics Department

In article <BtwJGC.1F1@ux1.cso.uiuc.edu> ceblair@ux1.cso.uiuc.edu (Charles Blair) writes:
>zweben@linguine.cis.ohio-state.edu (Stu Zweben) writes:

>>This is one of the main reasons that the Computing Sciences Accreditation
>>Board was formed by ACM and IEEE-CS in the mid-80s.  Programs that are
>>accredited through CSAB must require 2/5 of a year of science (four courses,
>>including the equivalent of a two-semester sequence in a lab science for
>>science majors, and ...

>   I do not see why somebody intending to programming work, even in a real
>world setting, needs two semesters of lab science.

This tendency to teaching people weak subject matter so that they can see
"applications" is ubiquitous.  Taking 20 courses of a lab science will not 
make them any better programmers even in that science.  Even if they know
the problem, will they know the numerical analysis (I consider the current
courses as too weak, although they may be the best that an undergraduate
can get; but there is no book for a numerical analysis course for those
who understand mathematics), and will they know the problems in arranging
operations into code?  Right now, they get neither, and I do not know of
any school which gives the necessary material.

Mathematicians can become efficient programmers much faster than programmers
can become mathematicians.  But it is even difficult to find programmers who
can assist the one who has the ideas.
-- 
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,comp.lang.misc,comp.arch,sci.math
From: mcvey@mpr.ca (Iain McVey)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Mon, 31 Aug 92 17:08:49 GMT

In article <1992Aug31.144045.11416@hubcap.clemson.edu> 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 undertand the science. The problem
>continues to be that scientific codes are meant to deal with nature and
>that takes someone who understands the problem. The problems keep getting
>worse as more university dumb-down the CS curriculum.

Oh there are those who do, but they tend to stay in research or get
snapped up by institutions with big budgets.

Getting people who can function in more than one discipline is more than
half the battle these days.

'Computing Science types' who truly understand accounting should write
better accounting packages, shouldn't they?

If you are used to hiring MIS computing science types, then it is no
small wonder you have a problem getting complex code out of them, in my
mind.  On the other hand, you would probably not want to hire an OS
programmer to write your user interface for your next greatest PC program.

Finding BSc's who even know what a vector processor is can be a
hard enough battle.  So perhaps you will have to either lower your
expectations, or raise your stakes and get someone qualified to do the
job.

- Iain -
-- 
Iain McVey (mcvey@mpr.ca)    | Kodachrome, gives us those nice, bright colours,
Software Designer            | Gives the greens of summers,
MPR Teltech Ltd.             | Makes you think all the world's a sunny day.
8999 Nelson Way, Burnaby, BC | - Paul Simon
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math