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,misc.education
Subject: Preparation for programming
Date: 6 Sep 92 13:03:31 GMT
Organization: Purdue University Statistics Department

In article <1992Sep04.222529.29814@digibd.com> rhealey@dellr4.digibd.com (Rob Healey) writes:
>In article <BtwJGC.1F1@ux1.cso.uiuc.edu>, ceblair@ux1.cso.uiuc.edu (Charles Blair) 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.

>	Data gathering skills, observation skills, statistical analysis
>	of data taken skills. All needed in many programming areas
>	where you are controlling or monitoring something. How do you
>	construct a test to see if your code handles all inputs with
>	proper outputs? Experience in labs can help with this skill even
>	though on the surface it seems like a stretch.

Experience may or may not help.  Experience with routine problems is of
limited utility, and that is what one gets in undergraduate lab science
courses.  Much of the lab experience would be just as effective if it
were videotaped.

>	Overall, people are good or bad developers/engineers because
>	of the efforts they make to go BEYOND what teachers regurgitate
>	at them in class. 95% of what I do on a daily basis is similar
>	to experiences I exposed myself to OUTSIDE of classes or school
>	per say.

>	People who just study books and ace tests make poor
>	business employees but fairly good academics, i.e. LOT'S of
>	theory but little experience to back that theory up.

They may make popular teachers, but they are only good at teaching the
details and methods without understanding.  What is needed is conceptual
understanding, and this is not being taught, and is resented by the
brainwashed students.  It is not skills which are needed, but the understanding
to acquire them, and to recognize when they should or should not be used.

There are those "purissima" scholars who do not even wish their work to be
applied, and scholars who do not wish to apply their knowledge to "practical"
situations.  But the one who understands can uaually easily learn to apply.
It is the one taught, "This is the way to do it," who can do nothing else.
-- 
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.misc
From: crawford@church.mitre.org (Randy Crawford)
Subject: Re: Programmers
Organization: The MITRE Corporation, McLean, VA
Date: Thu, 10 Sep 1992 04:38:15 GMT

In article <BuBBoJ.un@rice.edu> sabry@rice.edu (Amr Sabry) writes:
>
>Based on courses here at Rice University, here is a minimum list of
>*concepts* that a real programmer should know:

OK.  I'll bite.

[ several points deleted ]

>- Continuations and continuation-passing style.
>
>- Macros: hygienic expansion.
>
>- Time pre-emption and light weight processes.

Did you perhaps omit anything?  No assembly language, compound data structures,
algorithms, architecture, operating systems, databases, logic, discrete math,
or theory (machines, grammars, etc)?

Does Rice really place a higher priority on continuations and lightweight
threads over _any_ of the subjects I mentioned.  If so, then Rice grads will
experience a rude awakening after graduation when they enter industry.

>A person that understands the above concepts can design or implement
>any programming language. Furthermore, they can code an algorithm in
>any existing programming language efficiently. Finally, learning any
>new language amounts essentially to learning a new syntax.

Nah.  Prolog is fundamentally different than scheme (the preferred Rice PL,
I've heard).  Knowing scheme and (for example) C will _not_ lead to an 
immediate understanding of Smalltalk or APL.  And a program's efficiency 
suffers greatly when the programmer doesn't know of garbage collection
and algorithmic complexity, neither of which were mentioned in your list.

It also helps to know a little about architecture or assembly language or
linker/loaders or system services before constructing compilers/interpreters.

:-)

--
Randy
crawford@mitre.org
-- 

| 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
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: The definition of algorithm (was: Programmers)
Organization: Los Alamos National Laboratory
Date: Tue, 15 Sep 1992 17:03:53 GMT

In article <1992Sep12.043133.6177@linus.mitre.org>, crawford@church.mitre.org (Randy Crawford) writes:
|> >[...]
|> >- The libraries have a routine called qsort, [...]
|> 
|> This is an algorithm, not math theory.  [...]

NO.  Quicksort is an algorithm.  The routine `qsort' is a program
which *maybe* implements quicksort correctly.  Since this is comp.edu, 
we should make an attempt - at least here - to recognize that an
algorithm is an abstract mathematical concept and not any specific
program.

-- 
J. Giles
Xref: sparky comp.edu:1641 comp.lang.fortran:3537 comp.lang.misc:3049 comp.arch:9386 sci.math:11337
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Learning to Program (was: Scientists as Programmers (was: Small Language Wanted))
Date: 13 Sep 92 02:35:39 GMT
Article-I.D.: CS.1992Sep13.023539.2311
Organization: Oregon State University, Corvallis Oregon

In article <1992Sep9.061933.28304@news.eng.convex.com>
culter@convex.com (Brad Culter) writes:
>In article <Bu9FB3.BDK@world.std.com>
>jkenton@world.std.com (Jeff Kenton) writes:
>>As a physicist by training (MS, almost a PhD) and a programmer for
>>over 20 years, it's clear to me that it is difficult to teach anyone
>                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
>>to program.  Everyone picks up the basics in their first class, but
> ^^^^^^^^^^
>
>	Why? This has been a long-standing question for me, and one
>        for which I have yet seen adequate theory. I can recall actually
>	"learning" calculus, biochemistry, and physics, 
>	etc., but I cannot recall "learning" to program in the same
>	way. My experience, not unlike others I've met, was that
>	programming came more naturally to me than walking did.
>	It was more like breathing, i.e., almost a "reflex" to
>	the situation of being given a problem to solve and a tool
>	(computer language) to solve it. 

Learning to program is much like learning to write.  We only know vague
generalities about what constitutes good writing.  We know it when we see it,
but can't tell you how to do it.  Like writing, all we can do is make students
program, look at good programs, and hope they get the idea.

Learning (introductory) calculus, biochemistry, and physics is much like
learning an algorithm, and then applying the algorithm.  (Sort of like getting
a new program for your wetware.  :-)  For writing and programming, we don't
have an algorithm for producing good work.  (The same is true of art, I think.)

>>Some people are just better than others.
>
>	Again, why? Although, knowing the answer will probably
>	do nothing but satisfy my curiosity.

Answer this question, and I think you'll have earned a PhD in Psychology.

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
From: adamsd@crash.cts.com (Adams Douglas)
Subject: Re: Programmers
Date: 12 Sep 92 23:02:17 GMT

In <BuBBoJ.un@rice.edu> sabry@rice.edu (Amr Sabry) writes:


>Many people on this net implied that whoever can write a matrix
>multiplication subroutine in Fortran is a programmer.

I think your definitions fit what I and many of my collegues would call
a 'programmer' but don't fit what I would consider a present-day versatile
computer professional.

I feel a broad knowledge of hardware is a _must_. This does not interfrere
with one's ability to write portable code. On the contrary, it enhances it.
In order to write really portable code you must be familiar enough with your
hardware and other possible hardware to know what is portable _but_optimal_
and what isn't.

I spent 7 years at NASA's Deep Space Network at JPL upgrading a majorrs. 
subsystem. I don't think a day went by when I wasn't hooking probes to the
CPU board and logic analyzers to the IEEE-488 interface to see what my code
was doing. I was employed by a contract service (Telos) which called me a
"Software Design and Coding Engineer." I don't know if that's a better, more
well-rounded word than 'programmer' but I think it's more descriptive of 
what someone who wishes to succeed in this industry today needs.

Xref: sparky comp.edu:1612 comp.compilers:1534
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Newsgroups: comp.edu,comp.compilers
Subject: Introducing new operators (was: Re: Scientists as Programmers)
Keywords: parse, design
Date: 8 Sep 92 17:49:50 GMT
Reply-To: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Followup-To: comp.compilers
Organization: Computer Science, University of Melbourne, Australia

blair@lll-crg.llnl.gov (Gary Blair) writes:

>kers@hplb.hpl.hp.com (Chris Dollin) writes:
>>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''. ...
>
>Wrong.  If your compiler uses ANY kind of table-driven parsing scheme, it is
>next to impossible to allow programmer-defined operators.  The parser must
>know what an operator looks like, and what precedence it has  with respect
>to all other operators.  This is usually predetermined, at
>compiler-generation time.  

I think that "next to impossible" is perhaps overstating the case a
little.  If you have a small number of precedence levels (eg. Haskell has
only 10 or 16 I think), then it is quite possible to code up each of these
precedences as a production in the grammar. The difficulty with knowing
what precedence a given operator has, or indeed exactly which characters
constitute an operator, is then exactly analagous to the "typedef" problem
in C (determining whether an identifier is a type name or not), and can be
handled with the same sort of hack (feeding information from the parser
back into the lexer).

All the same, it is not trivial. If you also have to worry about backwards
compatability with C, it becomes very difficult indeed, I suspect.
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.edu:1650 comp.lang.fortran:3548 comp.lang.misc:3066 comp.arch:9405 sci.math:11402
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 14 Sep 92 14:15:59 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Sep10.165629.28124@searchtech.com>, johnb@searchtech.com (John Baldwin) writes:

|    Absolutely.  I've seen scientific programs written by self-taught
|    scientists which could result in floating point results where precision
|    could be destroyed in 1-3 operations.  They couldn't figure out WHY they
|    would occaisionally get screwy results from some data, and not from
|    others.  The blame was placed on a compiler bug.  Hrrumph.

  I think this is a good example of why a programmer is needed to write
good programs. With all their training in {physics or whatever} most
scientists don't get a good foundation in numerical analysis. Another
favorite is to add a bunch of small numbers in a loop, get an overflow,
change the total variable to float, and wonder why the result "doesn't
look right" when adding a few million little numbers.

  There are some programmers who would do this, too, but that's a
question of technical competence rather than training. A good programmer
should know some numberical analysis.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Xref: sparky comp.edu:1610 comp.lang.misc:3000
From: asd@sage.cc.purdue.edu (Doug McClure)
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Programmers
Date: 10 Sep 92 17:14:06 GMT
Organization: Purdue University

In <peterd.716085594@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:

>There are a few missing, as far as I can tell:

>- introduction to complexity theory. There are a lot of software
>  engineers out there who don't know what O(N) means, and it's 
>  usually not their fault.

I know what Big O means, after having it rammed down my throat class
after class, but it hasn't made me a better programmer.  All it's
given me is a severe dislike for those classes.  Hell, if I want
something to run fast, I look up algorithm's in a book, or profile my
program, etc.  I seriously doubt I'll sit down and figure out what the
Big O of it is, I've yet to do so for anything (except the classes I
had to).

>- fundamental ideas of computer architecture, so that you know how
>  registers, stack frames, and memory (cache & virtual) work, or at
>  least how fast they are.

Yes, I will agree!  This kinda stuff really gave me a better
understanding of how computers work.  Took some of the mystique away,
which was good.

>  A lot of schools require an assembler course. IMHO, a course 
>  specifically targeted towards architecture (e.g. MIT 6.004) would
>  be better.

Probably.  I know that the VAX assembler course I HAD to take was
interesting and worthwhile, but I really could say I could effectively
program in assembly, and it would be fairly worthless as nowadays most
computers are not VAX'es.

>- possibly an introduction to databases.

Probably.  It depends on if you are into information services like
that.  I took it and got a LOT out of it.  Others never do.

>- numerical methods / analysis.

No way.  414, the Numerical Analysis course here at Purdue, is
worthless.  They shove tons of this stuff at you, totally confusing,
totally meaningless, as if we were grad students, and expect us to
just understand it.  None of what they teach can be looked at and said
to directly apply to anything in real life, and most of the
assignments are figuring up some algorithm that works in O(nlogn) time
to compute some nonsense sum.  I've yet to hear ANYONE here who said
they liked the course.  I've yet to NOT hear anyone say that it's just
a course you get through and get a grade so you can graduate (D for
Diploma).  That kind of course is NOT what we need.  If we must be
taught it, then figure out a way to integrate it with pratical life
instead of leaving it totally in the realm of mathematical theory.
I'm in computers folks, I'm not a grad math theory major.

-dsm
Xref: sparky comp.edu:1656 comp.lang.fortran:3551 comp.lang.misc:3071 comp.arch:9418 sci.math:11433
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
Date: 14 Sep 92 20:53:23 GMT
Article-I.D.: CS.1992Sep14.205323.8577
Distribution: na
Organization: Oregon State University, Corvallis Oregon

In article <mcdonald.299@aries.scs.uiuc.edu>
mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
>In article <1992Sep14.090213.18722@uklirb.informatik.uni-kl.de>
>kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
>>Take Pascal-XSC. It is available on all unix machines since it compiles to
>>standard C. It allows users to define operators monadic and dyadic, and it
>>comes with many of them for interval, vector, matrix, complex etc.
>>computations.
>
>However, the results will be no faster .... and almost surely slower,
>than simply coding in C.

This is not necessarily the case.  Compilers can better optimize code knowing
that an operator is "matrix multiplication" and one of its arguments is
"identity matrix" than it can "bunch of loops and assignments" and "array with
some ones and zeros".  Higher level operations _can_ reduce execution time,
particularly for parallel computers.  They can also make things worse.

>What you are describing is **NOT** user definable operators in the sense that
>they are **needed**!! What is needed is the ability to define operators
>that map one-to-one to the exact machine operations that are present,
>to give the fastest possible results.

Well, that depends on your goal.  If your goal is speed at the cost of ease of
development, you do what you want.  If your goal is ease of development, with
only modest efficiency, you do something else.

>What you describe adds no new capabilities to the language.

Yes, it does add capability.  What it doesn't add is computational power.  But
almost all programming languages are equivalent from that standpoint.

>You would still need assembler to access the full capabilities of the machine.

True, but there is a cost to accessing the full capabilities.

>Remember that **NO** langauage can ever add capabilities to assembler,
>because assembler can do anything.

Computationally, yes.  Expressively, no.

>HLLs can only prevent use of things assembler can do.

Preventing things is also a reasonable goal, if software quality is important
enought to justify a loss in speed.

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
Newsgroups: comp.edu
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Preparation for programming
Organization: Motorola Codex, Canton, Massachusetts
Date: Thu, 10 Sep 1992 00:31:00 GMT

dlhpfm!dlh@NCoast.org (daniel lance herrick) writes:

>> Somebody else wrote:
>> 
>> >>      People who just study books and ace tests make poor
>> >>      business employees but fairly good academics, i.e. LOT'S of
>> >>      theory but little experience to back that theory up.

Funny, my impression was that such people tended to succeed in the
commercial world, but had a hard time making it through college to get
there. Sheer persistence will accomplish a lot of things as a manager
or marketer or some other MBA-oriented professional, but it won't prove
a theorem.

It's sort of frustrating to realize that that student who could never
figure out calculus but was president of 5 different campus
organizations is probably going to be your boss someday.

				Peter Desnoyers
-- 
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: jkenton@world.std.com (Jeff Kenton)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Kenton Systems Corporation, Weston MA
Date: Tue, 8 Sep 1992 12:42:39 GMT

In article <1992Sep3.123432.18806@bony1.bony.com> richieb@bony1.bony.com (Richard Bielak) writes:
>Someone said earlier in this thread that "It is easier to teach a
>physics student to program, than it is to teach CS student physics."
>
>This is just the kind of thing a physicist would say :-).
>
>A computer scientist would say that "It is easier to teach physics to
>a CS student, than it is to teach a physics student to program."
>


As a physicist by training (MS, almost a PhD) and a programmer for
over 20 years, it's clear to me that it is difficult to teach anyone
to program.  Everyone picks up the basics in their first class, but
few get really good.  Even the stars take a while.  They may claim to
have written a whole compiler in their first semester, but you wouldn't
enjoy reading the code.  And some CS students write code that looks
like it came from the physics department, even after 10 years of work
experience.

Some people are just better than others.


-- 
-------------------------------------------------------------------------
=			Jeff Kenton	(617) 894-4508			=
=			    jkenton@world.std.com			=
-------------------------------------------------------------------------
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Thu, 10 Sep 1992 14:11:15 GMT
Subject: Re: Programmers
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.edu,comp.lang.misc

In article <1992Sep10.043815.4175@linus.mitre.org> (and three apparently
identical copies!), crawford@church.mitre.org (Randy Crawford) writes:

   Does Rice really place a higher priority on continuations and lightweight
   threads over _any_ of the subjects I mentioned.  If so, then Rice grads will
   experience a rude awakening after graduation when they enter industry.

   >A person that understands the above concepts can design or implement
   >any programming language. Furthermore, they can code an algorithm in
   >any existing programming language efficiently. Finally, learning any
   >new language amounts essentially to learning a new syntax.

   Nah.  Prolog is fundamentally different than scheme (the preferred Rice PL,
   I've heard).

Odd you should say that; there's a rather pleasant mapping between Prolog
clauses and the use of continuations that should make Scheme programmers who
have been exposed to continuations find several aspects of Prolog very simple;
the unification and backtracking (possibly Prologs most distinctive features)
being the most obvious.

Orwells pigs.

--

Regards,    | ``"I can't suit myself," said Weinbaum, a little petulantly.
Kers.       | "I work for the Government".'' - Blish, "The Quincunx of Time".
Xref: sparky comp.edu:1672 comp.lang.fortran:3574 comp.lang.misc:3090 comp.arch:9434 sci.math:11509
From: mark@kraken.ucsd.edu (Mark Anderson)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 15 Sep 92 21:21:52 GMT
Followup-To: comp.edu
Organization: W.A.S.T.E.

In article <1992Sep15.165612.7661@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>In article <1992Sep14.141559.601@crd.ge.com>, davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
>Indeed, most recent CS graduates
>I've met *also* don't know anything about floating point arithmetic.
>
>|> [...]          With all their training in {physics or whatever} most
>|> scientists don't get a good foundation in numerical analysis. [...]
>
>Since the computing "science" departments don't provide such a foundation
>either, where do we turn?
>

We turn to the library.  

Part of why college graduates are more useful than
trade school graduates is (if you have hired the 
right ones) that they can assimilate the material 
in a text book.

Sad to say, but I will admit, the CS graduates I 
encountered are probably the weakest of all technical 
majors in learning new material from books.  

mark
From: kmagel@plains.NoDak.edu (ken magel)
Newsgroups: comp.edu
Subject: CSAB and ABET accreditation
Date: 15 Sep 92 14:47:04 GMT
Article-I.D.: plains.20345


Organization: North Dakota Higher Education Computing Network
Keywo