Hacker News Reader

Comment by balabaster | Hacker News Reader

Mostly it's inspiring because most people sit back and say "It can't be done, it's impossible" or "wow, they must have had a shit ton of luck to get this out of the door" instead of looking for solutions or ways to circumvent or exploit the million little problems along the way that seek to obstruct the endgame.

Kudos to these guys for sticking at it long enough and persevering to achieve their vision.

View on HN

I guess different people see different things in such projects. What I see:

  - *massive* success of coordination and cooperation
  - illustration of potential humanity has
  - that careful and methodical approach can make even such monsters of recursive complexity work

Luck does not enter the picture. Will and determination do though.

You'd be surprised how often will and determination is more of a factor of success than luck.

[Your level of surprise may vary]

My inspiration from massive science projects is more like: "With that in mind, debugging this 1500-line function is nothing!"

Dude... refactor that shit. There is no place in today's development world that a 1500 line function is okay :P

Indeed. It will save you from needing inspiration to debug it as well. It's much less cognitive load when you break those crazy things into understandable parts.

The potential speedup on those old F2C routines is amazing. The ability to use much more memory, understand cache levels, etc. have a huge impact.

When was the last time you've seen pure Assembly? Also, JavaScript namespacing shenanigans & stuff... :P.

I make 3rd party/unsanctioned mods for video games in my free time, which involves plenty of Assembly :)

Not all functions are refactorable. A 'purely hypothetical' scenario: a numeric routine of several klocs on length, that takes in 20 parameters with 1-3 letter obscure variable names, was written 30 years ago in fortran, was f2c:d 20 years ago into c and has been doing it's 'stuff' correctly ever since somewhere in the bottom of mission critical code in a codebase of millions of lines. Commercial codebase. Only a handful of developers. Management expect new features and expedient, safe bugfixes that do not change end user functionality.

That's actually simple. All you need is to npm yeoman to generate a proper skeleton for grunt and gulp to work using Mockito.js, C2F.js and Fortran.js, then you can auto-generate unit tests that will be paralelly distributed over AWS.

More seriously though, the kind of code you described will be what I imagine the first subject of study of the software archeology field in the future.

http://akkartik.name/post/deepness

The scenario you describe is a disaster waiting to happen.

Refactor it, preferably yesterday - but make a "shadow deploy". For each set of input / output parameters run both functions and compare them. If they differ, use the old one and go back to figuring out where it went wrong. After some time you can be quite sure that the new clean function works as it should - then you just switch.

I am not sure the above idea is mentioned by Michael Feathers in his amaze book "Working Effectively with Legacy Code" but it is a great idea, and combined with the things that Michael does cover will do you a lot of good!

http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-F...

It's a legacy system developed by someone who is lucky he lives 4300 miles away!

I've been working at the system to free it from that subsystem with an eventual replacement. There are all kinds of single-letter variables and Russian words, refactoring wouldn't be economical or sane.

Reply on news.ycombinator.com