HDTenEightyP/NetNews huggingface dataset:
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
Organization: UIUC SCS
Distribution: na
Date: Mon, 14 Sep 1992 12:50:45 GMT

In article <1992Sep14.090213.18722@uklirb.informatik.uni-kl.de> kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:

>>>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
>> 
>If one wants to see and USE a language with user definable operators:

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

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.


What you describe adds no new capabilities to the language. You would
still need assembler to access the full capabilities of the machine.
Remember that **NO** langauage can ever add capabilities to assembler,
because assembler can do anything. HLLs  can only prevent use of 
things assembler can do.

Doug McDonald
Xref: sparky comp.edu:1546 comp.lang.fortran:3441 comp.lang.misc:2943 sci.math:11029
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,sci.math
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
From: ecmtwhk@ccu1.aukuni.ac.nz (Thomas Koenig)
Date: Sat, 5 Sep 1992 01:20:04 GMT
Organization: University of Auckland, New Zealand.

bwallet@apssgi.nswc.navy.mil (Brad Wallet) writes:

>I used to think that the software engineers needed to understand the
>math and physics of the problems being solved.  I am not so sure anymore.
>They have theirs hands full as it is.  No, I guess they need some familiarity
>with the material, but they do not need to be experts.

I'm not too sure on that point. Take an example: implementing an
equation of state for a pure fluid and adjusting parameters. Suppose I
gave the basic formulas and data points, which specify the problem
completely, to somebody with a CS and/or maths background and told him
to write a program to adjust the parameters via least - square fit
numerically.

Would that person know that any result where the fugacity coefficient of
the dew line rises with rising pressure is clearly wrong in one way or
the other?
-- 
Thomas Koenig, ecmtwhk@ccu1.aukuni.ac.nz, ib09@rz.uni-karlsruhe.de
The joy of engineering is to find a straight line on a double logarithmic
diagram.
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Wed, 9 Sep 1992 08:21:35 GMT
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.edu
Distribution: na
Followup-to: comp.lang.misc

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

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

Well, in that case there are several next-to-impossible compilers out there,
all compiling Algol68. And, depending on what you mean by ``table-driven
parsing'', ``next-to-impossible'' is a gross over-statement. All it takes is
feedback from the semantic analysis to the lexical analyser, telling it what
the current precedence of operator tokens is. You may have religious objections
to this technique; I know I do.

But in any case, the difficulty lies with *precedence*, not *spelling* (the
latter being ``knowing what an operator looks like''). If you're prepared to 
give user-defined operators a fixed precedence level, then the problem goes
away. I'd rather have user-defined operators with a fixed precedence level
(assuming the designer is sane enough to choose a sensible value) than not have
them at all.

As for the parser knowing what an operator looks like, it has the same problem
as knowing what an indentifier looks like, or a string, or a keyword; to wit,
none. Assuming, that is, that you construct operator symbols from an alphabet
of operator characters in a uniform way -- just as identifier symbols are
constructed from identifier characters (usually letters, digits, and the odd
special character).

Now I've exposed my hidden assumptions, you mat accuse me of cheating.

[I've adjusted followups to comp.lang.misc. I hope.]
--

Regards,    | "You're better off  not dreaming of  the things to come;
Kers.       | Dreams  are always ending  far too soon." - Caravan.
From: ovrskeek@matt.ksu.ksu.edu (I am the OVER-skeek!)
Newsgroups: comp.edu
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 8 Sep 1992 15:57:29 -0500
Organization: Kansas State University
NNTP-Posting-Host: matt.ksu.ksu.edu

jac@ds8.scri.fsu.edu (Jim Carr) writes:

>The main prerequisite for being a good programmer is a good grounding 
>in the specification of a logical and complete solution to a problem. 
>Without this, one can still be trained to write beautifully structured 
>code, but the chances of the code giving a correct answer are zip.  Given 
>this, both training and experience are needed as you point out. 

>What is missed is that physicists and other scientists, by virtue of 
>their training in their discipline, are likely to have the prerequisites 
>for being a good programmer.  The preparation of computer scientists in 
>mathematics (consider PDEs for example) cannot be assumed. 

The main prerequisite for being ANYTHING is a good grounding in the
specification of a logical and complete solution to a problem. Without
this, you are up a creek!

What is missed is that (good) computer scientists, by virtue of their training
in their discipline, are likely to have the prerequisites for being a good
physicist. (I.E. They are good at solving problems). The preparation of 
physicists in (Data Structures/Algorithms/Languages/Ect.) cannot be assumed.

Only 1/2 :-).

------------------
ovrskeek@matt.ksu.ksu.edu
Newsgroups: comp.edu,comp.lang.misc
From: dclason@dante.nmsu.edu (Dennis Clason)
Subject: Re: Programmers
Summary: Syntactic correctness isn't necessarily idiomatic correctness.
Organization: New Mexico State University, Las Cruces, NM
Date: Thu, 10 Sep 1992 21:08:03 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:
>
>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.
>
In the narrow sense of syntactic correctness, I'll agree with
your last assertion.  I take issue with the claim immediately
preceding it.  Users who don't understand the primitives in a
language are liable to overuse (and even invent) inefficient constructs.
I've seen this happen many times when programmers whose exposure has
been limited to procedural languages (e.g. PL/I) are exposed to a
nonprocedural language with similar syntax (i.e., SAS).  These
programmers then proceed to reinvent the wheel.  I saw one case where
the programmer went through several tortuous steps to do a simple
linear regression.  All beautiful PL/I code, but horribly inefficient.
She said "Oh, I can't be bothered to learn about the procedure
library."

I've also seen this happen with scalar language programmers who
start to pick up a vector language, e.g., Gauss, IDL.  You look
at the code, and they loop through vectors right and left,
ignoring operators and functions.  The stuff is syntactically
correct, but idiomatically WRONG!  APL tends not to suffer from
this problem as much -- I think that's because APL syntax is so
foreign it forces your thoughts into new constructs.


Newsgroups: comp.edu
From: crawford@church.mitre.org (Randy Crawford)
Subject: Re: The definition of algorithm (was: Programmers)
Organization: The MITRE Corporation, McLean, VA
Date: Tue, 15 Sep 1992 19:40:08 GMT

In article <1992Sep15.170353.8665@newshost.lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:
> In article <1992Sep12.043133.6177@linus.mitre.org>, crawford@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.

I'm not so sure of the difference.  All descriptions of Quicksort use
a natural language (English), a PDL, or an implementation language.
Any of these may incorrectly specify how to do a Quicksort, but none 
is more essentially `Quicksort' than any other.

The abstract procedural/mathematical idea `Quicksort' is based as much 
in _some_ language as qsort is.  qsort is simply a specific description
of a Quicksort (in C ?).
-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7525 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102
From: nevin@apple.com (Nevin ":-]" Liber)
Newsgroups: comp.edu
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 15 Sep 92 22:57:22 GMT
Followup-To: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Organization: Apple Computer, Inc.

In article <1992Aug31.135937.5801@dcc.uchile.cl>, pchris@dcc.uchile.cl
(Chris Perleberg) wrote:
> They found CS programmers to
> be useless: "....it's easier to teach a PhD en Physics how to program then
> to teach a CS programmer Physics...." 

May you have to maintain that code for the rest of your life.

> There is a hell of a lot of truth in
> that statement.  Most PhD's in Physics are reasonably intelligent and 
> programming is not really a difficult challenge.

To get something barely working, I agree.  To make a piece of code that
will be useable, modifiable, and maintainable for years and years, good
luck.

> And scientific code often naturally structures itself.

I hope I never get stuck touching this code.

> They did hire one programmer and basically she couldn't do much useful 
> programming in the nuclear codes (anyway, a BS in CS is going to tell a
> Doctor in Physics how to structure his code? ;-).

It sounds like these physicists aren't very good, since their egos are too
big to let them condescend to using an expert just because that expert has
less formal education than themselves.  I wonder where these physicists get
all the time to become expert software engineers.
___
NEVIN ":-)" LIBER, RISC Porting Specialist/Blue Meanie, Mac System Software
 email:     nevin@apple.com        paper:  Apple Computer, Inc.
 voice:     (408) 974-MIX1                 20525 Mariani Avenue, MS: 81-GC
 AppleLink: BADENOV                        Cupertino, CA 95014
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: asd@sage.cc.purdue.edu (Doug McClure)
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Programmers
Date: 10 Sep 92 17:28:21 GMT
Organization: Purdue University

In <1992Sep10.142205.16217@merlin.dev.cdx.mot.com> lezz@merlin.dev.cdx.mot.com (Lezz Giles) writes:

>[lots deleted including some responses adding things like OS and database
> to the list...]

>Following this further, if you start as a programmer then the original
>list seems reasonable (with maybe a few omissions) for a basic reasonably
>proficient programmer.  It is nowhere near a complete list for a
>software engineer and there is almost nothing on it for a computer scientist
>(for example, a computer scientist isn't concerned with "parsing" - but
>he knows about grammars).

Indeed!  I have found that the biggest problem, here at college, is
that Computer Programmer is NOT a major.  It's not even a minor!
Instead, I get to be a Computer Scientist!  I don't want to be a
Scientist!  I want to be a Computer Programmer, or a Software
Engineer.  Leave all that numerical computational math theory bullshit
to the academics.  I could really care less.  But I want to be able to
work!  I want to know how to write a server, custom engineer a system
for a client, or write super fast code for a device driver.

Alas it is not to be.  I know, now after my five years hear at Undue
Perversity, that there ARE schools out there that teach you how to
program, who teach you how to be a software engineer.  Schools that
give you skills so that you could graduate and be ready to work from
day one.  I'll be able to, to some degree, mainly because I've spent
many hours of my own time teaching myself what I needed to know.  And
ya know what, not one minute of that time was spent on numerical
analysis.

Schools need to offer a complete and seperate Computing divison
school.  Under that they should offer degrees of Computer
Technology/Programer, Software Engineer, Computer Engineer, and
finally Computer Scientist.  And if you want to be a CompSci, then you
can be.  But if you want to instead be taught computers from the
perspective that you are going to be an worker some day and need good
solid programming, software engineering concepts, then you should be
able to get them, instead of having to pick it all up on your own.

Sorry bout the verbosity.  This is a subject that really pisses me
off.  I picked a college that was supposedly a great place for folks
who wanted to get computer degrees, and found that they didn't want to
give me knowledge about how to work, but wanted to turn me into a
scientist, possible grad student.

-dsm
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Los Alamos National Laboratory
Date: Tue, 15 Sep 1992 16:56:12 GMT

In article <1992Sep14.141559.601@crd.ge.com>, davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
|> 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. [...]

Yes, but that still leaves the problem of where to find a programmer.
The other discussions on this group are revealing the fact the CS
departments do not (at least, not universally) regard the training
of *programmers* to be their purpose.  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?

-- 
J. Giles
Newsgroups: comp.edu
From: gillies@m.cs.uiuc.edu (Don Gillies)
Subject: Re: Are computer "scientists" really scientists? (was: Are programmers Computer Scientists?)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sat, 12 Sep 1992 22:10:34 GMT

schuette@wl.com (Wade Schuette) writes:

>"programming"?  Bah. That's like saying Mathematicians are "adders".

Actually, mathematicians are concerned with O(1) algorithms (known as
theorems 8-)).  Computer scientists are concerned with all the
algorithms in the universe with greater time complexity.  8-) 8-)

Don Gillies - gillies@cs.uiuc.edu - University of Illinois at Urbana-Champaign


--
From: gus@prism.gatech.EDU (gus Baird)
Newsgroups: comp.edu
Subject: Re: collaborative work
Date: 5 Sep 92 12:55:15 GMT
Organization: College of Computing, Georgia Institute of Technology

In article <20161@plains.NoDak.edu> kmagel@plains.NoDak.edu (ken magel) writes:
 >
 >  What is your opinion with regards to the value or harm in having student 
 >work together on programming projects?  

It depends on the objective of the exercise.  If you're in a lower-division
course where the objective is learning the basic skills, then group projects
are counterproductive.  If it's to learn "higher" skills then group projects 
can help or hinder, depending on how students are allowed to break up the job.
If the objective is learning how to work in groups then group projects are
exactly right. 

Analogy: if you send a team out to do labor, then the guy with the strong 
legs will do the leg-work.  The ones with weak legs won't develop their 
legs by doing that job, because that would hinder completion.  

Letting students work together in groups on projects where they're to learn 
basic skills tends to result in each student getting more practice in what 
he's already good at and discourages students from filling in the gaps in 
their skills sets, because of the students natural tendency to view the 
objective as being to get the program working.  We don't need the *program*, 
we need them to benefit from the exercise.  
-- 
gus Baird, College of Computing
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!gus
ARPA: gus@cc.gatech.edu
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
From: rhealey@dellr4.digibd.com (Rob Healey)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: DigiBoard Incorporated, Eden Prairie, MN
Date: Fri, 04 Sep 1992 22:25:29 GMT

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.

	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
Xref: sparky comp.edu:1598 comp.lang.misc:2985
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: Preparation for programming
Organization: UIUC SCS
Date: Sun, 6 Sep 1992 15:11:07 GMT

In article <Bu5qxv.Gn0@mentor.cc.censored.edu> (Censored by
JDM)@pop.stat.censored.edu (censored) 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.

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

Sounds like Herman Rubin talking to me. Herman may have a recognizable
broken-record style, but, folks, he is 100% on the mark here, and its
a **very** important point.

I would add that these poeple will make neither good business employees
nor good academics except in special cases. They **will** be valuable
business employees in a certain circumstance: as members of a Japanese-
style "development team". The Japanses educational system turns out
tons of these people, an as long as a few real-world people get out somehow
to get on these teams, the people who are the kind the original poster
describes as "test-acers" will be valuable on those teams.

However, note that the deep thinkers may also ace tests.
 
>Herman Rubin, 

Yep, its Herman.

Doug McDonald
Xref: sparky comp.edu:1554 comp.lang.fortran:3450 comp.lang.misc:2951 comp.arch:9251 sci.math:11048 misc.education:3303