Hacker News Reader

Comment by sidlls | Hacker News Reader

Yep. Most of my programming classes were either in pascal or c when I was in undergrad, but in my physics courses, all the way through my graduate education, I used FORTRAN. It's because physics doesn't change that much over the years, FORTRAN code that is time-tested and that works exists and there's no need to re-invent the wheel in another language when more interesting and important problems exist to solve.

View on HN

David Baker's Rosetta code, which made him a pile of money, is IMO a spectacular example of craptastic C++ written by people who really didn't understand C++ but didn't let that deter them from using every single feature of the language, badly. Some years back we tried to port it to CUDA but there were so many levels of indirection, dereferencing, and virtual functions that it was nearly impossible to make any progress.

In contrast, porting the 30+ year old molecular Dynamics package AMBER to CUDA took about 3 months and probably established me as a CUDA expert. In my opinion its well-maintained Fortran 90 code was far easier to understand and refactor.

While my primary languages today are C++ and CUDA, there is something clean about Fortran when it comes to understanding underlying algorithms. I have a similar opinion about well written C code.

That's the whole trick. Good code makes complex stuff look simple. Bad code makes simple stuff look complex.

That quote should be the metric by which code/languages are judged.

How do you measure the complexity of the code, and most importantly, of the problem that the code is solving?

Complexity analysis.

I wonder if you can formalize this. Assume TDD, and then measure the compressed size of the codebase vs. the compressed size of the test suite. Code is "worse" when it requires more "stuff" (informational entropy) to do less "stuff" (pass test cases.)

The compression would presumably remove the redundancy of the language itself as a factor (including differences in idiomatic cyclomatic-complexity "depths" of various stdlibs), and also remove any redundancy in the way the test cases were specified. So it'd be down to a measure of how much circumlocution and over-engineering you did in the process of implementing the solution.

I'd worry slightly that code-golf solutions would be rewarded, though. Maybe pass everything through an obfuscator + linter before computing the metric, so that things like identifier lengths and spaces aren't considered.

> using every single feature of the language

I constantly run into code where someone takes an obscure corner case in the language, and builds an entire edifice around it.

> which made him a pile of money

May I ask how? I don't see ads or any other obvious monetization channels.

Rosetta is a protein folding bit of software: https://els.comotion.uw.edu/express_license_technologies/ros...

GP is not talking about http://rosettacode.org/wiki/Rosetta_Code

Its a product of the UW, so no surprise the quality is crap. IMO their Cybersecurity course (which is mandatory for CS students) is the biggest load of shit I've ever seen in a class.

The head of information security at the UW calls the PSTN bulletproof secure, but VOIP insecure, then babbles on about how he shares classified info with his buddies casually (happens to be a felony to share said info).

Needless to say, UW's Avaya phone system barebacks the internet, with no regard for using silly security things like TLS or SRTP.

Oh, you're that Scott Grand? Allow me to thank you for the work you did on pmemd.cuda, my old research group wouldn't be where they are now without you.

You're welcome, it was ironically based on ideas drawn from a C Port of the Amber potential function I wrote back in grad school. While I'm not proud of the code these days, I put it on sourceforge a long time ago.

https://sourceforge.net/projects/folderol/

Why write the port in the first place? Because back in the days of yore, I was doing the equivalent of adversarial search to try and design a better potential function for predicting protein tertiary structure. I ultimately arrived at the result that there were too many adversaries to make linear models and single hidden layer neural networks work.

And unfortunately, my postdoctoral advisor at the time didn't consider this publishable research.

Maybe it's simply the fact that the C++ code was object-oriented?

OO allows you to make a much worse mess than procedural programming in my experience.

Reply on news.ycombinator.com