Hacker News Reader

Comment by rrradical | Hacker News Reader

I see things a bit differently. Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.), while in others it may be much harder (the file uploading example he mentions). To me a good aim of writing code is to move bits and pieces from the latter camp to the former, so that more and more of your codebase is well understood (and perfect!). That usually involves finding the mathematical meaning of the abstractions you're using. (Shameless plug- I wrote a little blog post on the subject: http://asivitz.com/posts/programming_in_haskell)

View on HN

> Some domains are well understood and it's relatively easy to write perfect code (e.g. mathematical functions, list manipulating functions, etc.),

Those are good examples of things that seem easy to write perfectly until you change some requirements that seemed like they would never change.

Take your list manipulating library and throw in a requirement that all node allocations have to be pooled, or that it needs to work in a multi-threaded environment. All of a sudden you have to rewrite them all. (for example, see: STL vs EASTL)

Someone already mentioned floating point, but math can definitely get tricky if you have to be exact. An example from my own past experience - it's really easy to write code to cut a 2d triangle using an arbitrary line as the cutting axis. It almost always works, and it usually works flawlessly. Until you get close to degenerate cases, skinny triangles or overlapping vertices. Throw in a requirement that degenerate cases must resolve correctly, and suddenly you have to start over and use a different representation of numbers. Make it a little more general to handle 4+ sided polygons, and before you know it, you spend a decade trying to get it right. (for example: http://www.complex-a5.ru/polyboolean/comp.html)

Certainly the requirements change and we modify the foundations of our systems all the time to reflect this. However, there are those useful abstractions which seems to survive a certain amount of time so as to allow us to study them, and then there are the yearly hypes.

That list manipulating library might still be based on concepts which are understandable and communicable to their users, allowing us to reason at different levels on their internal and external behavior. This in turn allows us to say, at a certain abstraction level: this code is complete. Thinking of Occam we might continue: given our preconditions, our abstractions, our algebra: this is the simplest.

It is fair to believe that 'perfect' means that all unnecessary complexity is removed. But, I would like to argue againts its usage, as the word carries too much emotional baggage in this context.

Actually, I'd say writing perfect code in the mathematical domain is extremely hard - floating point types are a minefield and infinite-precision arithmetic is a minefield also if you consider the possibilities for running-times exploding. For example, code for the mean of a list of numbers is a hard problem when looked at in its full generality [1] - and that's using forgiving definition of "perfect" - alway correct and terminating, running at a reasonable speed.

[1] http://hypothesis.works/articles/calculating-the-mean/

Great link! But also, the mean is itself an imperfect summary of some distributions. Any single-number summary will be misleading in some cases.

Anscombe's quartet is a great illustration of that.

https://en.wikipedia.org/wiki/Anscombe%27s_quartet

That's really cool! Btw, I'd love to drop that line into casual conversation some time. "Anscombe's quartet" has a nice flow to it.

Floating point isn't really the baseline for great mathematical structure, it's just a pervasive hardware standard.

I get really twitchy when I read statements like yours. But I am completely unreasonable in my definition of perfect -- it is really beyond extreme. Perfect is an absolute, so by definition it is unobtainable. Perfect means you have gone beyond the notion of executes correctly every single time, but MUST also be aesthetically perfect. Perfect names, perfect formatting, perfect location etc. No one can meet my criteria for perfect and never will (I can't).

In that sense, there is no perfect code, nor will there ever be. There will only EVER be good enough.

Why have the word perfect then?

idealism?

For the same reason we have the word infinity.

But infinity does exist...?

Infinity exists the same way that perfection exists. Abstractly.

You’ve created a concept and attached the word “perfect" to it. Your concept is different than the shared definition. This leads to disagreements, misunderstandings, and (as you said) twitching.

The purpose of words is to share information. If you have write a paragraph describing your definition when you use a word, use a different one.

Not really. When I look up the definition, it is 'completely free of faults or defect'. I don't think I've strayed past that meaning.

yes you have. you've moved it into the subjective by requiring pleasing aesthetics

>has tabs

>literally trash

Perfection is subjective because flaws are subjective. Aesthetics are part of the code. If a piece of code is functionally perfect but ugly or inelegant by some measure, then it is imperfect by that measure.

right, flaws are subjective. I'll try that one on my QA team next time they file a bug report ;)

There is more than one class of flaw. Some are objective, ie. fail to meet spec. Some are subjective, typically where the spec doesn't cover.

If software functions correctly but is unnecessarily hard to use due to (eg.) bad layout, would you still call it perfect?

The real problem with what you've said, is that "finding the mathematical meaning of the abstractions you're using" is an incredibly hard processes, and almost nobody succeeds at it. And even then, you have to map these abstractions to hardware in a way that doesn't leak. And the only way to do that is to implement the machine itself (or a special hard-to-find-subset of it). Those are the only abstractions capable of leak-free modeling.

Reply on news.ycombinator.com