[Beowulf] Re: about clusters in high schools

[Andrew Piskorski]

On Sun, Jan 29, 2006 at 04:01:08PM -0800, Jim Lux wrote:

> I'd even go so far as to say, many engineers SHOULD BE PROHIBITED from 
> programming in their professional career (unless they're in the software 
> development business).  Better they should learn how to write effective 

An interesting thought, and I think I agree - in the context of
programming fundamental to their engineering responsibilities.  (E.g.,
"design this widget", "calculate the parameters of this process".)
But the ones who should be banned from such programming are the ones
who took a good programming class and didn't get it.  If at all
possible ALL engineers should be exposed to it.

And remember, a lot of work - and computer programming - engineers do
is NOT fundamental to their responsibilities - it just makes day to
day tasks, problem solving, and friction fighting a hell of a lot
easier.  More on that below.

> specifications and test cases so that someone else can do it better.  Yes, 
> being an engineer means you're, by nature, a jack of all trades, and we're 
> justly proud of it, BUT, from a business standpoint, machinists should 
> machine, artists should art, and engineers should engineer.

Except that I have heard plenty of stories of an engineer not being
allowed to just go in and spend an hour machining some damn one-off
part he needs, because the union rules say, "Only machinists are
allowed to machine, nobody else."  Instead, write up a work order,
then wait for two weeks.  And the engineer who DOES know at least the
basics of machining has an advantage, and in many cases is simply a
better engineer because of it.

Computer programming is analogous - but more so, because computing is
much more widely applicable than machining...

> All should know what the other one can do and how they do it(and
> should have done a bit, so they understand WHY they shouldn't be
> doing it).

Yes, absolutely.  But when it comes to computer programming, most of
the working engineers I met did not even reach that basic level of,
"Know enough of the basics to know when and how to call in an expert."

> >> Learning effective use of one or more higher level languages, on the
> >> other hand, would serve them EXTREMELY well.  A scripting language
> >> like Tcl, Perl, or Python would certainly be useful, but a math or
> >> statistically oriented language like Octave or R probably has better
> >> synergies with the rest of the engineering curriculum.
> 
> I'd be happy if engineering students all learned english grammar and 
> spelling and could write an effective 2 page essay.

Except that's not properly part of an engineering education at all, it
is a PRE-REQUISITE for an engineering education (or for any university
level education at all for that matter).  If an engineering program
must teach how to write an effective two page essay, it's engaging in
remedial education because grades 1 to 12 have completely dropped the
ball.

And yes, I agree, if undergraduates are arriving at engineering
schools so poorly prepared that remedial classes in reading, writing,
or arithmetic are required, then fixing those is the top priority.
Compared to those computer programming is mere fluff.

But we weren't talking about that, we're talking about teach computer
programming to engineernig students, and about the wisdom of DROPPING
computer programming entirely in order to make room for instruction on
"teamwork" and "presentation skills".

If that is in fact actually occuring at some university somewhere (no
specific examples have been given, only generalities), then I suggest
that it has absolutely nothing to do with better teaching engineers
what they really need to learn, and everything to do with lowering
standards and dumbing down the curriculum.

> I would run in fear if someone popped up at a design review for a 
> production system and said "hey, I've got this nifty piece of code I wrote 
> back when I was a sophomore, let's use that".

But that's silly.  Reality is much more like, the new engineer adapts
some code he wrote in school to help him protype and idea or figure
out some problem.  And if he HADN'T learned to program and written
that code, he probably wouldn't even have any IDEA about how to
proceed.

Learning a programming language ** and environment ** is NOT just
about writing code.  It's also about learning to use and integrate
what's already there - and there is a LOT of high-grade open source
code already there.

Open source is the friend of education in ways that closed source code
simply can't be, therefore educatuion should be somewhat biased in
favor of selecting open source programming langauges and other tools,
where feasible.

> >> Ages ago when I was a Process Engineer, I wrote a whole bunch of
> >> Bourne shell, sed, and Awk code (plus a touch of Perl later on), but
> >> although I knew some C (and was learning more), I never touched it
> >> once on the job, and never had any reason to either. If I'd actually
> >> learned one or more of Tcl, Python, Perl, Matlab, Octave, S-Plus, or
> >> R, they DEFINITELY would have been useful to me.  C, Fortran, or Java,
> >> no.

> But that's somewhat specific to the job and environment.  If you had toiled 
> away learning tcl, then you might have wound up at a place that used only 
> perl, etc.

No, actually it's not.  What you say may often be relevent to someone
** working as a programmer **, but I'm not talking about those folks.

I'm talking about engineers, especially those who will never write
code because they've either never learned any programming at all, or
because their "Scientific Programming in Fortran" class didn't get
very far in one semester, and they don't see how to possibly apply
Fortran to the problem at hand with any reasonable amount of effort
anyway.

Non-professional programming in industry?  Here's a true and I believe
largely typical example:

"We've had downtime and scrapped wafers because the damn ASML stepper
locks up sometimes if we copy updated lithography recipe files to it
while it's running (and it's running all the time, 24/7 if we can).
The manual procedure we've slapped in place to avoid the lockups is
onerous, drives the engineers crazy, and is tempting to circumvent.
Find a better solution."

I assure you, my boss could not have cared less whether the script I
wrote was in Boure shell, Perl, Tcl, or Cobol, as long as it worked.
But of course, I was never ASSIGNED such a task at all.  No, I was one
of the people maintaining those recipes, and the problems and risks
were obvious.  I wrote the script, tested it, sent some emails, and
then we put it into use.  Problem solved.

(For the curious, the ASML software folks back at their corporate
headquarters could not turn off the "feature" that was causing the
problem, but they COULD provide a utility program on the stepper,
callable via rpc, which would answer the question, "Is it safe to
update recipe file X right now?"  The script to solve the problem
stems immediately from that fact - check yes/no, if yes copy over NFS
to the stepper, if no queue for later retry.)

Don't have any engineers that can program?  Well, just talk to the IT
guys over in the other building, they probably have somebody who can
do it.  Except, uh, they're pretty backed up, and this isn't really
their responsibility.  Maybe they can get to it in three months - or
six.

And even getting external folks like the IT guys (or consultants,
contractors, etc.) involved is only an option for a problem that is
recognized, and can be spec'd out.  Many problems amenable to attack
by programming skills are those which a non-programmer won't even
THINK of solving that way.

- Make the same single change to 100 different but similar text files?
- Track revisions to those 100 files over time, retrieve any version
  at any time, and show the differences between any two versions at
  will?  (Ever heard of "CVS"?)
- Fit a statistical model?  Do designed experiments and crunch numbers
  on the results?
- Do a throughput model for manufacturing equipment?

These are all tasks that someone with programming skills is much
better equipped to attack than someone without.

> Gotta pick somthing, so you might as well pick something that is
> reasonably stable and widely known.  Hence the popularity of Latin
> in classics instruction.

Uh, but that seems to be arguing that when teaching basic programming
to folks who most likely will NEVER take another programming class,
since we've usually done it in C, Pascal, Fortran, or Java before, we
should just keep doing it that way - even though the results are
demonstrably worse than if they use some language better suited to
rapid development.  Sorry, I disagree.  Teaching in Fortran (or C or
Java) is demonstrably worse than teaching in Python, but "worse" in
what terms?

1. In terms of what students can readily accomplish with their
newly won programming skills - definitely true.

2. In terms of understanding programming principles and techniques,
non-specific to any particular programming language - harder to
demonstrate, but AFAICT also true.

> >These codes are written in C, C++ and FORTRAN and simulate complex
> >physics.
> 
> And, today, these codes get written in matlab, and work just as 
> well.  Matlab just saves you the hassle of having to explicitly call the 
> "MATMUL" routine, or worry about coding up yet another LU solver.

Yep.  Intro level programming should be taught in the highest level
(easiest and fastest to code in) programming language which is broadly
useful and widely used for solving real world problems.  There are, of
course, many such languages, but it's been a LONG time since C or
Fortran was one of them.

-- 
Andrew Piskorski <atp at piskorski.com>
http://www.piskorski.com/