Why Our Genome and Technology Are Both Riddled with “Crawling Horrors” | Hacker News Reader

Why Our Genome and Technology Are Both Riddled with “Crawling Horrors”

nautil.us

30 pointsdnetesn15 comments

Nothing's really jumped out to me yet, but tools need to raise flags about the complexity of code. A pre-commit hook that recognizes long functions, classes with more than ten member variables, classes that program to an implementation rather than interface? Could it check to see that classes that can be easily unit-tested are?

The world expects programmers to make clean code, but we've not really advanced our tools much outside of Java and C#. I'm always envious of what the refactoring tools can do in those languages.

I never understood many people's fixation with avoiding long functions/methods. I would much rather have that hook check long call stacks. I have never went "wtf" as I dove into a new code base because of long functions, but I do it all the time when five levels of inheritance is used to provide all the magic necessary to "shield" me from whatever the code is actually doing.

I definitely _have_ gone "wtf" when dealing with some long functions. A 380 line switch/case comes to mind. I have also had to deal with the 5 level deep inheritance that was equally difficult in its own way. Figuring out where to balance between length and depth is one of the more difficult parts of programming in my opinion.

After many years maintaining my and other people's code, I do tend toward shorter methods. On the other hand, splitting up a method into several methods just to keep under a hard line limit causes more problems than it solves.

Sure, of course I prefer shorter code. But I'd much rather read a hundred straightforward lines than wrap my head around yet another abstraction (of which there are thousands in any non trivial codebase).

I must disagree on the switch statement. A main loop with an rather large switch statement is a perfectly normal way to write a trivial interpreter. C provides a nice way of doing it, and as long as you declare your constants properly it's all perfectly readable. A lot of excellent code bases are structured that way. (Awk comes to mind, IIRC, and it's very easy to read and extend.)

Keep in mind - a function shouldn't contain more than one level of abstraction really. Having a 50+ line function, the code is telling you that you have a class in there struggling to get out.

Also - you may be superior to others and able to understand a 50 line function. But what about your colleagues?

The average cognitive limits of are well known. I doubt we will evolve to beyond these flaws in my lifetime.

Code Climate is a service that does this for Ruby code. I'd much prefer something running locally, though.

most of codeclimate's metrics come from things you can run locally (eg they blog about this here http://blog.codeclimate.com/blog/2013/08/07/deciphering-ruby...):

http://ruby.sadi.st/Flog.html http://ruby.sadi.st/Flay.html http://brakemanscanner.org/

What makes codeclimate useful is the polish/ease of use on top of these tools. It also makes it easier for me to get projects to adopt new tools - if they're in CC already, and CC start doing bundler-audit reports...we get them for all projects.

The things that cause real problems aren't local (like long functions, big classes, etc).

They are global, like hidden assumptions about the stuff you interface with. Requirements regarding order of invocations of some methods of seemingly unrelated classes. Code that shouldn't really be needed, but stuff breaks when you remove it. Esoteric automaticaly generated code driven by xmls or .xlsx, that nobody really understand, but copy-paste when you need another special-case.

I still believe in a future where programming-by-specification and advanced theorem proving systems result in the ability to make systems that are provably without a certain class of bugs. Then it would be possible to upgrade systems effortlessly by simply proving that they satisfy the same primary specifications.

Then of course writing the spec is the hard part, but I'd at least be interested in seeing what those challenges turn out to be like.

is there any difference between a sufficiently rigorous spec and actual programming?

Depends on what you mean by "sufficiently rigorous". There's a sense in which an algorithm description is just a more detailed spec, but if a spec is just "specify all properties of output", that can be described in predicate logic. The spec language doesn't necessarily have to be turing complete (I think).

At the end of the article, the author wants us to treat artificial complex systems as living things. I believe this is a mistake. This mind set leads you to believing that parts of a program or process are Just Too Hard To Understand. You'll end up supplicating the system, instead of working with it.

"If our brains were simple enough for us to understand them, we'd be so simple that we couldn't."

I guess this can be applied to any system. An advanced system and one that can be understood easily don't seem to be compatible.

The road to the stars passes through a refactoring of the human genome. That will be possible before a re-implementation of life.

I'm not sure that refactoring our genome is going to be enough. We need bodies that can survive cosmic radiation as well as maintain structural integrity for the thousands of years required for most interstellar trips. We probably also need a psychology that doesn't recoil in horror at the thought of 10,000 years in space. And frankly, we probably aren't smart enough to do space travel well, even if we did have radiation-hardened bodies with million-year lifespans.

Even saying "we need a rewrite" doesn't cover it, as that still implies the same design goals. We need to rethink ourselves from first principles to have any chance. To draw upon the IRS example from the article, this isn't a matter of slapping a web front-end on software from the 60s. This is more like trying to adapt 50 year-old tax return software commissioned by the US government, to run the server for your new MMO (and, I suppose, reworking that web front-end to act as the client, heh). There is not a single thing about the human body adapted to space travel including our brains - why would there be?

Reply on news.ycombinator.com