[Beowulf] Scientific computing's future: Can any coding language top a 1950s behemoth ?

[Ellis H. Wilson III]

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.

Best,

ellis

-- 
Ph.D. Candidate
Department of Computer Science and Engineering
The Pennsylvania State University
www.ellisv3.com