HDTenEightyP/NetNews huggingface dataset:
From: ajayshah@almaak.usc.edu (Ajay Shah)
Newsgroups: comp.edu
Subject: Re: Small Language Wanted
Date: 26 Aug 1992 10:39:57 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: almaak.usc.edu

pawlak@vxdesy.desy.de writes:

>In article <WVENABLE.92Aug26154731@algona.stats.adelaide.edu.au>, wvenable@algona.stats.adelaide.edu.au (Bill Venables) writes:
>> 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?

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

Case is a valuable tool for revealing the structure of the
code on screen.  You will quickly evolve rules of thumb for
when uppercase is used.  Different people choose different
rules, but the point is: combined with good rules of thumb,
case sensitivity is an excellent policy for making code more
readable on screen.

The rules I use, for example are:
- all caps only (and always) for #defines
- all typedefs start with first capital letter (like K&R)
- otherwise almost never use uppercase anywhere.

With these rules in hand, my code is easier to take in with
case sensitivity than without.

        -ans.
-- 
Ajay Shah, (213)749-8133, ajayshah@usc.edu
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.edu
Subject: Re: Are programmers Computer Scientists?
Date: 4 Sep 1992 04:20:57 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: anarres.cs.berkeley.edu

I can't believe people are still discussing this trivial question.
This is *worse* than whether C is better than Fortran, or whether
physicists can program.

I mean, really.  "Are firefighters peace officers?"  "Are stenographers
white collar workers?"  "Are computer scientists scientists?"
"Are performance artists artists?"  "Is rap music?"  Who cares?

People used to talk about substantive questions in this group, like
what should we teach to whom, and how can we use technology effectively.

Oh well, at least I learned about the K command.
Newsgroups: comp.edu,comp.lang.misc
From: esh@curly.tekbspa.com (Edward S. Hirgelt)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Direct Interfaces Corporation @ Teknekron
	<1992Sep3.112944.20996@dbsun.uucp> <Bu08uF.HBC@mentor.cc.purdue.edu>
	<Bu0DI1.KFA@rice.edu>
Distribution: na
Date: Thu, 3 Sep 1992 19:35:23 GMT


On 3 Sep 92 15:25:12 GMT,
sabry@rice.edu (Amr Sabry) said:

Amr> In article <Bu08uF.HBC@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
Amr> |> There is generally no single algorithm optimal on all machines, so the
Amr> |> hardware considerations at least have to be known to the programmer.

Amr> Don't forget: you also need to know about the design of your car to
Amr> drive it optimally, the design of your fridge and oven are also
Amr> crucial, so is the design of your TV.

I suspect that Amr means this humorously. However, there is a kernel of
truth in it. Herman is talking about optimal, wringing the last ounce of
performance out of an algorithm. To do the same to your car, you better
know that you ought not exceed 6500 RPM on the engine (or whatever the
limit is for your engine/transmission combination) or that your
car or truck wasn't designed to tow a 8000 pound trailer.

The point in many of these and related discussions is knowing when you
need to be truly optimal. If you're pushing the limits with your
algorithms and/or problems, you need the fastest solution. Sometimes
that requirement exceeds the need to be portable or to be readable.

When solving a problem, know what the problem is first, then you can
decide on the tools to solve it and evaluate the trade-offs involved.
Sometimes that takes a software developer, sometimes that takes a
scientist, sometimes it takes both. It also takes a good knowledge of
the tools that are available that might be applicable to the problem.

Ed
--
Ed Hirgelt			esh@tss.com
Direct Interfaces Corporation
San Jose, Ca.
Newsgroups: comp.edu
From: 22731@church.mitre.org ()
Subject: Re: programming languages, education, unanswered questions, loose threads
Organization: The MITRE Corporation, McLean, VA
Date: Fri, 28 Aug 1992 15:56:51 GMT

In article <1992Aug28.003249.2349@beaver.cs.washington.edu>, pattis@cs.washington.edu (Richard Pattis) writes:
> 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.  

1500 introductory students each year?  Are you graduating 1500 CS BS degrees
every year, or are you weeding like mad?  Perhaps that explains why you've 
chosen to teach Ada as a first language?  :-)

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

So you consider the learning curve for Ada to be equivalent to that of Pascal?
That surprises me a lot in that Pascal is a substantially smaller subset of
Ada, and ought to be less to learn.
 
> 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. 

I can appreciate the advantages of teaching ADTs using an Ada, C++, Eiffel,
etc.  I've seen most schools faced with the difficult decision, "How to
teach ADTs in a language which is appropriate as a first language?"

It seems to me though that too many schools are choosing an overly difficult
first language (Ada or C++) only in part to teach ADTs.  But I see another 
motive here -- culling out the overload of freshmen who enroll in CS programs.
Am I wrong (not necessarily at U Washington, but in general)?

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

Unless you are handing them pre-written packages to use as stacks, queues,
trees, etc, I still don't see how Ada can solve any programming problem with 
less effort than Pascal.  OO programming languages demand _more_ from their
programmers unless there is code reuse going on. 
-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7525 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: zweben@linguine.cis.ohio-state.edu (Stu Zweben)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: The Ohio State University Dept. of Computer and Info. Science
Date: Tue, 1 Sep 1992 00:09:10 GMT

In article <1992Aug31.184805.10913@texhrc.uucp> ak45ldp@Texaco.com (Larry D. Pyeatt) writes:
>
>                                      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.
>


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 two other courses in science or with a strong emphasis
in quantitative methods.  Calculus is also required, as are core courses in
the major that balance coverage in several areas.  To date, over 100 
undergraduate CS programs have been accredited.   While no set of criteria
is perfect, the accreditation process does address Larry's concerns.

Stu Zweben
Ohio State University


Xref: sparky comp.edu:1334 comp.lang.fortran:3166
From: ajayshah@almaak.usc.edu (Ajay Shah)
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: scientists as programmers (was: Small Language Wanted)
Date: 25 Aug 1992 19:33:54 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: almaak.usc.edu

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

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,sci.general,sci.math
From: steve@hubcap.clemson.edu ("Steve" Stevenson)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Clemson University
Date: Thu, 27 Aug 1992 12:44:17 GMT

jsvrc@rc.rit.edu (Doctor FORTRAN) writes:

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

>Nevertheless, you do have a point. Software specialists will argue about the
>best data structure to use for a problem, and still be trying to dope it out
>while the scientist has the whole thing already coded. That's because the
>scientist will see the program as what it truly is: a means to an end, rather
>than as an end unto itself. If computing is an end unto itself, it cannot
>be of practical consequence. (Didn't Hamming like to say that the purpose of
>computing was insight, not numbers?)

Yes, Hamming wrote this in the frontespiece of the first edition of his
{\em Numerical Methods for Scientists and Engineers}.

> But I must disagree when you characterize
>scientists as bad programmers. That's bigotry, and a stereotype to which I
>must strenuously object.

I'm in the language biz and I accept your criticism...CSers seem to think that
programs are an end in themselves. There are lots of underground anecdotes
about scientists who learn that the problem they're computationally trying
to solve has an analytic solution---they immediately trash the program.
At the recent SHPCC conference we had a session on education and computational
science. One of the computer science types got himself into trouble by having
the program-is-everything view.

steve
-- 
===============================================================================
Steve (really "D. E.") Stevenson           steve@hubcap.clemson.edu
Department of Computer Science,            (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: meyer@dbsun.uucp (Don Meyer)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: BioMerieux-Vitek, St. Louis Mo.
Distribution: na
Date: Fri, 4 Sep 1992 11:47:20 GMT

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.

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

Okay by me. :-)

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

Ummm, so?

Don



-- 
-------------------------------------------------------------------------
meyer%dbsun.uucp@wupost.wustl.edu        |||     I am at two with nature.
Opinions expressed are personal.         |||       -- Woody Allen
Xref: sparky comp.edu:1370 comp.lang.fortran:3207
From: nikhil@crl.dec.com (R.S. Nikhil)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: DEC Cambridge Research Lab
Date: Fri, 28 Aug 1992 20:39:12 GMT

I couldn't find previous articles in this thread, so pardon me if I'm repeating
this:  I once found the following amusing quote by Bill Gosper in an issue of
Science (vol 255, page 1150):

    ``An exciting thing was happening at Livermore.  They were building a
    supercomputer, and I will certainly confess to being a cycle junkie.
    Computers are never big enough or fast enough.  I have no patience at
    all with these damned PC's.  What I didn't realize when I went over to
    Livermore was that as long as physicists are running the show you're
    never going to get any software.  And if you don't get any software,
    you're never going to get anywhere.  Physicists have the most abysmal
    taste in programming environments.  It's the software equivalent of a
    junk-strewn lab with plug boards, bare wires and alligator clips.
    They also seem to think that computers (and programmers for that
    matter) are the sorts of things to which you submit punched card decks
    like you did in the mid-sixties.''

    --- Bill Gosper, in ``More Mathematical People: Contemporary Conversations''
                    (Donald J. Albers et. al., Eds.; Harcourt Brace Jovanovich)

Nikhil  (nikhil@crl.dec.com)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: jfjr@mbunix.mitre.org (Freedman)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: The MITRE Corporation, Bedford, MA
Date: Tue, 1 Sep 1992 12:09:01 GMT

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:
>>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?
>

   I probably shouldn't comment since this is no longer about computer
architetecture but I can't help myself. The trend in CS these days is
to view it as an end in itself - "It doesn't matter what your code is
trying to do just as long as you follow X design/maintenance
principles" I heard a CS type involved in a comm simulation say "whats
propagation speed, that's not my problem, its yours" Needless to say
the simulation failed. Its like teaching car mechanics how to keep
their tools clean, how to tighten bolts, check timing but not
bothering to have them drive.
Xref: sparky comp.edu:1405 comp.lang.misc:2802
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 29 Aug 1992 06:46:11 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

bevan@cs.man.ac.uk (Stephen J Bevan) writes:
: In article <BtpAIn.EE5@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
: 
:    Handling the syntax problem alone would make for great improvement,
:    but I see nothing in this direction, and have asked for software to do
:    this single job.
: 
: And many have asked you for a decent specification of what you want.
: If you can't tell us what you want, there is not much chance of us
: coding it is there?  So come on Herman, play the game, tell us
: what you want so we can finally be rid of this old chestnut.

I have no idea what Mr Rubin really wants but here are a couple of 
easy ones of the top of my head:

result1, result2 <-  function_that_returns_two_values (NOT a structured type);
E.g:

 P, D, Q <- singular_value_decomposition(A);

Array index notation:

for all i <= j: a(i,j) <- sum over (k) ( b(i,k)*c(j,N,k) )

(Thank god for Connection Machines)

I won't bore you with the obvious complex numbers, exponentiation, etc.

: bevan


--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
From: erspert@athena.mit.edu (Ellen R. Spertus)
Newsgroups: comp.edu
Subject: Re: how many usa comp sci grads per year?
Date: 4 Sep 92 00:01:42 GMT
Distribution: usa
Organization: Massachusetts Institute of Technology

In article <1992Aug24.201247.12857@rosevax.rosemount.com> craig@bunsen.rosemount.com (Craig Taylor) writes:
>Approximately how many people graduate from US 4 year
>schools with computer science degrees each year?  I guess
>this includes other programs with similar names.

In 1986 (the most recent year for which I have statistics handy),
42,195 people received CS bachelor degrees in the United States.  The
number has gone up every year since 1976 (the first listed in the
table), when 5,664 degrees were awarded.  Presumably, this includes
related majors.

This information is from the 1990 NSF report, _Women and Minorities in
Science and Engineering_.  (Answers to questions you didn't ask are
36% went to women, and the average salary of someone going into
industry with a BSCS was $28000.)

If you multiply the number of graduates by the average salary, you get
a whopping $1,181,460,000.

					Ellen Spertus
Newsgroups: comp.edu,sci.edu
From: domik@Informatik.TU-Muenchen.DE (Gitta Domik)
Subject: An Agenda for Education in Scientific Visualization
Organization: Technische Universitaet Muenchen, Germany
Date: Fri, 28 Aug 1992 12:43:57 GMT

                       Call for Participation
                       half day workshop on
          "An Agenda for Education in Scientific Visualization"
                to take place at Visualization '92, 
                 October 20 (Tuesday afternoon), 
                          Boston, MA.

The purpose of this workshop is to develop guidelines for courses in
"Scientific Visualization". Together with a small group of workshop
participants I would like to draw from first experiences of teaching 
visualization courses. Questions we hope to answer are:
 - what should be considered "core topics" in a visualization course?
 - what are essential reference articles for these topics?
 - is there public domain software and data that should be recommended
   to instructors?
 - can we create/collect data for classic visualization models?

Participation in this workshop is limited to individuals with actual 
experience in teaching a visualization course. If you intend to be
an active participant, please submit a short statement of interest
(1 paragraph), outline of the visualization course(s) taught, your
name, preferred email address and affiliation to:
 domik@informatik.tu-muenchen.de and cc: domik@cs.colorado.edu

Deadline for position statements: September 6, 1992

Notification of acceptance: September 11, 1992

I will be in Munich, Germany, for the next month, so please send any
regular (air-)mail to:
 Gitta Domik
 Schwanthalerstrasse 143
 D-8000 Munich 2
 Germany
 Tel. ++49/89/50-54-98

(Allow for the extra delivery time from non-European countries to Germany!)
There will be a 50 $ fee to be paid on-site at the conference in order
to participate in any Visualization '92 conference. 

Looking forward to a productive workshop!

Gitta Domik
University of Colorado at Boulder
domik@informatik.tu-muenchen.de (until mid-September)
domik@cs.colorado.edu (after mid-September)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math