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

[Prentice Bisbal]

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