On 05/13/2014 07:48 PM, Ellis H. Wilson III wrote:
On 05/13/2014 01:57 PM, Peter St. John wrote:
But I'd ask (extending the analogy) if I build an addition to my
parents' house, should I use pex or copper? Should I use copper because
the old part of the house uses copper?
Me 5 years ago: "Well, obviously, you'll want to run multiple lines
of pex to take advantage of the manifold system in the basement and
the main features pex brings, but this house is so crusty and old the
walls are too thin to actually contain the requisite number of pipes.
Therefore the only choice is to burn down the entire house, remove the
foundation so it can be replaced with an insulated variety, regrade
the entire yard so storm water runoff is better managed and reroute
the driveway to save one one-millionth of an ounce of gas every time
you park."
I would do about half of those things, decide in fact the plot
actually owned was not sufficiently sized/proportioned/whatever, douse
everything in gasoline, light it up, and live on the streets to
maintain my idealism.
Me today: "Pex sounds cute. Maybe next life."
This is a major failure of the CS educational system in my honest
opinion. I NEVER received a project in undergrad or grad where they
gave me a large (i.e., 50k lines or more) body of code (ideally it
should be in multiple languages and hook into numerous libraries) and
told "there is a bug in this area of the code, write the perfect patch
for it and submit" or "feature X needs to be added to this code,
inspect only the necessary components in the code to implement it,
measure your time spent, and report." Instead, in the BEST case I was
given 100-2000 lines of code, which I could easily refactor in as many
heinous ways as I so chose, and I was graded not on pragmatic
capabilities in real code-bases but on my ability to write hyper-OOP
java crud that would never be used in any real fashion because it was
so terribly slow and verbose as a result of the hyper-OOP mindset.
That being said, I would counter my own deeply ingrained cynicism at
this point by stating that I still reserve some fraction of my former
idealism and try to clean up code as I work on it. Far too many who
have been working in these huge code-bases in the past are totally
comfortable with leaving large chunks of commented code around,
leaving poorly documented routines poorly documented, and working
around old interfaces in nasty ways instead of spending a little time
to rethink cleaner but minimally impacting ways of reimplementing them.
Wrapping this back into the original issue (next-gen HPC languages), I
think the core issue is non-programmers programming. <begin
generalization> They don't really want to program. They're doing it
as a means to an end. They'd be more than happy to write equations in
lieu of routines, as the article alludes to. <end generalization>
Therefore, maybe, instead of continuing to attempt to create the
"perfect language" that fits their needs, maybe the better solution is
to teach them the tenets of proper programming so they can grasp the
process and instruct them on ways to write very clean and elegant
design documents. Sure, in some cases that may take as long just to
get the design doc done as it would for them to just code it, but in
the long run if said code gets wrapped into a larger project (or grows
into one) it will result in far less maintenance and complexity than
having 10 physicists and 10 CS folks both playing with the code
simultaneously.
Just my 2c though -- though the cynicism is great in this one, I still
admit I have comparably limited experience in real environments where
these things are at play.
Cyncism? As someone who's been an HPC system admin a while now, your
generalizations pretty much hit the nail on the head. You are wise
beyond your years.
--
Prentice
--
Prentice
_______________________________________________
Beowulf mailing list, [email protected] sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
