HDTenEightyP/NetNews huggingface dataset:
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
Date: 13 Sep 92 02:28:30 GMT
Article-I.D.: CS.1992Sep13.022830.2046
Distribution: na
Organization: Oregon State University, Corvallis Oregon

In article <135691@lll-winken.LLNL.GOV>
blair@lll-crg.llnl.gov (Gary Blair) writes:
>In article <KERS.92Sep4154056@cdollin.hpl.hp.com>
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''. So far as I am able to tell, the difficulty of
>>allowing the user to add new operator definitions is rather close to zero, so
>>long as this is taken into account *before* designing the language and
>>compiler. (C++ has the problem of trying to incorporate the lexical structure
>>of C.)
>
>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.  

That last statement is _wrong_.  It is _easy_ to add user-defined operators to
a language.  The attributes sufficient to make it easy are:

   operators must be lexically distinct
      just like identifiers are not predefined, but are lexically distinct,
      so too can operators be lexically distinct
   the operator precedence relationships must be static
      this is true in languages like C where all the operators are fixed,
      and therefore all the precedences are fixed
   the operator precedence must be lexically determined
      this is easy if you incorporate symbol table information into the
      lexer so that on finding an operator, it looks up the precedence

I designed and implemented a simple language that permits user-defined
infix and postfix operators and built the parser with lex and yacc.  My job
was a little simpler than the above in that all operators had equal
precedence, which meant that my symbol table only had to identify the operator
as defined (like an identifier) and did not have to provide a precedence.
Adding a precedence is simple.

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
Xref: sparky comp.edu:1590 comp.lang.misc:2979
From: sabry@rice.edu (Amr Sabry)
Newsgroups: comp.edu,comp.lang.misc
Subject: Programmers
Date: 9 Sep 1992 13:19:30 GMT
Reply-To: sabry@rice.edu (Amr Sabry)
Organization: Rice University
Originator: sabry@datura.cs.rice.edu


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

Based on courses here at Rice University, here is a minimum list of
*concepts* that a real programmer should know:

- Inductive definitions.

- Parsing.

- Types: Unsafe, dynamically typed, and statically typed languages.

- Constructed data: data representation independence.

- Lexical scope and procedures: implementing (call-by-value and
call-by-name) closures.

- Store: assignements, static scope versus dynamic extent, garbage collection.

- Paramter passing techniques: by reference, copy-in-copy-out, by value.

- Object-oriented languages: objects, classes, inheritance ...

- Local control: Iteration via tail recursion.

- Non-local control: errors, exits, coroutines, goto ...

- Continuations and continuation-passing style.

- Macros: hygienic expansion.

- Time pre-emption and light weight processes.


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.

-- 
Amr Sabry				       sabry@cs.rice.edu
----------------------------------------------------------------
"Why take time to learn when ignorance is instantaneous" -Calvin
From: schuette@quip.eecs.umich.edu (R. Wade Schuette)
Newsgroups: comp.edu
Subject: Teamwork vs Theory and Skills
Date: 14 Sep 92 18:15:31 GMT
Organization: University of Michigan EECS Dept., Ann Arbor, MI

Seems like the debate over what to include in a CS curriculum 
reflects the transition from a time when one could "know everything"
to a time when there is so much to know , as in medicine, that one
has to specialize.

Let me propose the idea that, instead of picking as the next item
to master something like FORTRAN or theory or algorithms, we should
encourage people to learn how to work as teams and to know how and
when to recognize the limits of their knowledge and when to seek
assistance from a specialist.  And how to seek that assistance.

A physicist is only going to spend so long mastering Computer Science
and vice versa.  I suspect there are some very useful people who may
not know NP-complete from the Pistons, but who do know how to work the
corporate system and get decent systems in place, even with blemishes.

As Henry Ford once said, more or less -- Why on earth do I need to 
know that?  I just press that button and an expert in the area comes
and helps me with it.   

I'm just putting forward the idea that everyone can't know everything,
and before stuffing more technical details into one's brain, maybe, for
some people, the next thing they really need to learn is how to 
collaborate and how to draw on the skills that others spent so long to
acquire. 

Wade

-- 
======================================================================
R. Wade Schuette        | 
+1 (313) 996-7479       |   "This sentence no verb." 
schuette@eecs.umich.edu |
Xref: sparky comp.edu:1564 comp.lang.fortran:3465 comp.lang.misc:2963 comp.arch:9269 sci.math:11096
From: davidc@panix.com (David B. Chorlian)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 7 Sep 92 23:59:32 GMT
Organization: PANIX Public Access Unix, NYC

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

This sounds like the argument that in order to read/write English,
you should study Latin.  Clearly the relevant parts of the study of
Latin, the etymology and the comparative grammar, could be studied
on their own.  The reason for studying Latin is to learn another
language/culture, and thus one could study any other language.

So if studying lab science is to help you with certain CS skills/
requirements, you'd be better off studying them directly.  The
reason for studying a lab science is to learn a DIFFERENT "culture".
That's a good reason.

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

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

>		IMHO,

>		-Rob


David B. Chorlian
Neurodynamics Lab
SUNY/HSCB 
davidc@panix.com

-- 

David B. Chorlian
Neurodynamics Lab
SUNY/HSCB 
Newsgroups: comp.edu,comp.lang.misc
From: sabry@rice.edu (Amr Sabry)
Subject: Re: Programmers
Originator: sabry@datura.cs.rice.edu
Reply-To: sabry@rice.edu (Amr Sabry)
Organization: Rice University
Date: Thu, 10 Sep 1992 16:48:39 GMT


In article <1992Sep10.043815.4175@linus.mitre.org>, crawford@church.mitre.org (Randy Crawford) writes:
|> Did you perhaps omit anything?  No assembly language, compound data 
|> ...
|> Does Rice really place a higher priority on continuations and lightweight
|> threads over _any_ of the subjects I mentioned.  

I was just describing *one* course about the semantics of programming
languages. They *are* other courses about architecture, O/S,
algorithms, complexity theory, compilers, and even AI. 

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

The mentionned course is taught *in* Scheme. Scheme is the tool not
the goal.  I don't want to get into "my language is better than your
language" wars, but Scheme is a descent tool to teach concepts. So you
can teach students about objects and message passing (Smalltalk),
continuations and how to implement intelligent backtracking (Prolog),
and memory allocation and garbage collection, and almost anything you
want.

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

Of course but this is a different level of abstraction. 





-- 
Amr Sabry				     	    sabry@cs.rice.edu
---------------------------------------------------------------------
Man will occasionally stumble over the truth, but most of the time he
will pick himself up and continue on.-- Churchill's Commentary on Man
Newsgroups: comp.edu,comp.lang.misc
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Programmers
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Fri, 11 Sep 92 16:56:39 GMT

In article <peterd.716085594@pjd.dev.cdx.mot.com> peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
>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.
>
>>Based on courses here at Rice University, here is a minimum list of
>>*concepts* that a real programmer should know:

Hmmm. There are several concepts that people who claim to be
university graduates in CS have been failing to know, at least in
recent interviews I've conducted (1985-now):

a. Ability to spell.
b. Ability to write simple, complete sentences in any language.
c. Ability to communicate what they claim to know.

These deficiencies (Yes, I KNOW they aren't concepts, but the idea
is to deal with reality here...) are, as someone who hires 
programmers, MUCH more important on a day to day basis, than
ability to design syntax analyzers, etc., even for someone in
the compiler/interpreter-building biz.

Bob



Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Xref: sparky comp.edu:1558 comp.arch:9255 comp.lang.misc:2955
From: dlhpfm!dlh@NCoast.org (daniel lance herrick)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math,misc.education
Subject: Re: Preparation for programming
Date: Sun, 06 Sep 92 19:37:15 EDT
Organization: dlh Performance Marketing

> 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.
> 
Herman Rubin
> >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 understand
> >to acquire them, and to recognize when they should or should not be used.

A story from my youth:

My first year out of college I was teaching at the Home Town Junior
College.  I still didn't have the MS, so I wasn't doing the Calculus,
but I was doing the Calculus based Physics.

There was a girl taking the Calculus and also taking Physics from me
who was president of the church youth group I participated in.  One day
she and another girl stayed after the physics class and she asked me if
I could help her with a calculus problem.  Of course!

She showed me an exercise in the text and, after I had read it, I
walked up to the chalkboard and proved the thing it asked for a proof
of.  The two of them were furiously writing.

It took me years to understand the following conversation:

she "Do you have all these things memorized?"

me "No, I never saw that before.  I just proved it for you."

I don't think either of us understood what the other was saying, but I
think I do now.

dan  of dlh Performance Marketing  POBox 1419  Mentor Ohio 44061
         NCoast.org!dlhpfm!dlh or ab.com!dlhpfm.uucp!dlh 

Newsgroups: comp.edu
From: farrell@coral.cs.jcu.edu.au (John Farrell)
Subject: Re: Are computer "scientists" really scientists? (was: Are programmers Computer Scientists?)
Organization: James Cook University
Date:  8 Sep 92 08:25:29 GMT

In <1992Sep8.045156.6935@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu (Don Gillies) writes:
>In my opinion, the core of the C.S. discipline is concerned with
>speeding up computers.

>The alternate core of C.S. is concerned with making computers easier
>to use.  This covers everything user interface to language design to
>O/S research to network design, and so on.

  I don't agree entirely with either view. Neither fast nor easy to use
computers are much use if you've got bugs in your program. I suggest that
computer science is just as much about finding a way to write correct programs
despite human failings, as anything else. There are certainly enormous
economic benefits to be had if you can be sure that your program is correct!

John
From: awakefie@norfolk.vak12ed.edu (Alice Wakefield)
Subject: Re: Computer Based Education : Journal List
Organization: Virginia's Public Education Network (Norfolk)
Date: Thu, 10 Sep 92 12:38:06 GMT

I will be an eager reader of this news category.  Good luck. 

Alice Wakefield
Xref: sparky comp.edu:1576 comp.lang.misc:2971
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 8 Sep 92 17:59:35 GMT
Distribution: na
Organization: Purdue University Statistics Department

In article <135691@lll-winken.LLNL.GOV> blair@lll-crg.llnl.gov (Gary Blair) writes:
>In article <KERS.92Sep4154056@cdollin.hpl.hp.com> 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''. So far as I am able to tell, the difficulty of
>>allowing the user to add new operator definitions is rather close to zero, so
>>long as this is taken into account *before* designing the language and
>>compiler. (C++ has the problem of trying to incorporate the lexical structure
>>of C.)



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

What you have just said is that if it is not taken into account before 
designing the language and compiler, it is hard to take into account
later.  This has not been disputed.

Far too much emphasis has been placed on the problem of precedence.  For
combinations other than the usual arithmetic ones, and precedence for 
unary operators over n-ary, programmers who do not know for sure should
use parentheses, or even transient values rather than concatenating the
operations.  Unless rewriting is allowed using algebraic (even in the
extended sense) properties, the compiler has to do this anyhow.   And
even if the rewriting is done, it will still have to do this.  So let
the programmer in on the act.

Similar problems occur with operations which naturally return a list of
values.  There is much anguish about calls having side effects; this is
due to a function call producing results, or changing results, besides
the explicit output value.  These are far from uncommon.

What is the purpose of a language/compiler combination?  To enable the
USER to write better code faster.  It is not for the convenience of the
compiler writer or language designer.  The same holds for language 
design principles; it is not the beauty or the purity of the product
which counts, but how well it does the job.
-- 
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)
From: kxs5829@ultb.isc.rit.edu (K.X. Saunders )
Newsgroups: comp.edu
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 3 Sep 92 17:40:29 GMT
Organization: Rochester Institute of Technology
Originator: kxs5829@ultb

In article <Btwnr3.4AB@encore.com> epeterso@fenix.encore.com (Eric Peterson) writes:
>In article <BtwJGC.1F1@ux1.cso.uiuc.edu> ceblair@ux1.cso.uiuc.edu (Charles Blair) writes:
>>   I do not see why somebody intending to programming work, even in a real
>>world setting, needs two semesters of lab science.
>
>Because most of what your average programmer does during the course of
>development (software engineering principles aside) is experimentation.
>You formulate and test hypotheses about what is going on inside of a
>complex hardware/software system all the time.  You have to be able to
>interact with the real world when theory breaks down (ie, "The man page
>[or standard] says it should do this, but it doesn't!  Why?!").

	It's called problem solving.  Two semesters of lab courses isn't going
to teach it.  And if you don't have decent problem solving skills from the
start, you might try something other than programming.

	- Kyle

-- 
+-"Remember, [MS]DOS is sort of a UNIX deviant already" - dmoscny@piglet.-----+
|    // Only /\          kxs5829@ultb.isc.rit.edu                 cincinatti. |
| \ //      /--\MIGA     kyle@nick.csh.rit.edu                    oh.us       |
| \X/ SQLdb - $40 rdbms  Rochester Institute of Technology                    |
Xref: sparky comp.edu:1547 comp.lang.fortran:3443 comp.lang.misc:2944 comp.arch:9243 sci.math:11034
From: kxs5829@ultb.isc.rit.edu (K.X. Saunders )
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 3 Sep 92 17:33:11 GMT
Organization: Rochester Institute of Technology
Originator: kxs5829@ultb

In article <1992Sep1.115849.13522@relay.nswc.navy.mil> bwallet@apssgi.nswc.navy.mil (Brad Wallet) writes:
<As I have said previously, you are getting computer scientists and 
<software engineers confused.  Software engineering is the discipline
<concerned with writing good code.  Software engineers study the design
<process, design philosophy, testing, life style management, reliability,
<and all that other stuff that defines good code.

	Um, no.  Software engineering is a practice that should be applied
by a good programmer, but it is not a separate discipline.

	- Kyle

-- 
+-"Remember, [MS]DOS is sort of a UNIX deviant already" - dmoscny@piglet.-----+
|    // Only /\          kxs5829@ultb.isc.rit.edu                 cincinatti. |
| \ //      /--\MIGA     kyle@nick.csh.rit.edu                    oh.us       |
| \X/ SQLdb - $40 rdbms  Rochester Institute of Technology                    |
Newsgroups: comp.edu,comp.lang.misc
From: peterd@pjd.dev.cdx.mot.com (Peter Desnoyers)
Subject: Re: Programmers
Organization: Motorola Codex, Canton, Massachusetts
Date: Thu, 10 Sep 1992 00:39:54 GMT

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.

>Based on courses here at Rice University, here is a minimum list of
>*concepts* that a real programmer should know:

[... deleted ...]

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.

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

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

- possibly an introduction to databases.

- numerical methods / analysis.

[you know, if we flame long enough we'll probably come up with ACM's
model curricula. Why don't I just go and pull out my back issues and
look it up? Because we just moved, and they're in boxes, that's why...]

				Peter Desnoyers
-- 
Newsgroups: comp.edu,comp.lang.misc
From: schuette@quip.eecs.umich.edu (R. Wade Schuette)
Subject: Re: Programmers
Organization: University of Michigan EECS Dept., Ann Arbor
Date: Sat, 12 Sep 1992 10:09:43 GMT

In article <18rl1sINNhme@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Sep11.165639.24682@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>>a. Ability to spell.
>>b. Ability to write simple, complete sentences in any language.
>>c. Ability to communicate what they claim to know.
>
>These skills are useful for everyone, not just computer professionals, and
>lack of these skills is rampant in most engineering discliplines.  Since
>this discussion is taking place in comp.* groups, let's try to focus on the
>problems specific to computers.  I don't think we have any hope here of
>solving all the problems of the education system, but we might be able to
>make some inroads into the issues unique to computer science.
>Barry Margolin

I'll agree that focus is good, but if skills are necessary for the field,
they seem relevant even if they are also necessary for other fields.

Somewhat in that category I'd also add:
d.  ability to function as part of a team
e.  ability to take criticism of one's work constructively
f.  ability to constructively criticize other team members work

In some ways these seem a unique requirement of any serious development
project, regardless of language and methodology.  If you can't participate
in a group walkthrough of your design, analysis, and implementation I
don't want you on MY team.

Wade


-- 
======================================================================
R. Wade Schuette        | "Have you ever noticed that if you think
+1 (313) 996-7479       | about a problem at 2am, and then again at 
schuette@eecs.umich.edu | noon, you get two different answers?" snoopy
Newsgroups: comp.edu,comp.lang.misc,sci.math,comp.lang.fortran,comp.arch,alt.folklore.computer