[Beowulf] Scientific computing's future: Can any coding language top a 1950s behemoth ?
Ellis H. Wilson III
ellis at cse.psu.edu
Tue May 13 16:48:29 PDT 2014
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.
Department of Computer Science and Engineering
The Pennsylvania State University
More information about the Beowulf