News for hackers. Stuff that matters.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by rrradical on Monday July 18, 2016 @02:58PM (#12117324)
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)
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by dahart on Monday July 18, 2016 @07:41PM (#12118627)
> 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)

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by edejong on Monday July 18, 2016 @08:31PM (#12118793)
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.

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by joe_the_user on Monday July 18, 2016 @04:24PM (#12117846)
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/

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by skybrian on Monday July 18, 2016 @05:01PM (#12118038)
Great link! But also, the mean is itself an imperfect summary of some distributions. Any single-number summary will be misleading in some cases.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by bradleyjg on Monday July 18, 2016 @05:13PM (#12118095)
Anscombe's quartet is a great illustration of that.

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

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by fbonetti on Monday July 18, 2016 @07:42PM (#12118629)
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.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by Retra on Monday July 18, 2016 @08:24PM (#12118768)
Floating point isn't really the baseline for great mathematical structure, it's just a pervasive hardware standard.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by cwbrandsma on Monday July 18, 2016 @04:26PM (#12117864)
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.

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by jungrothmorton on Monday July 18, 2016 @06:20PM (#12118368)
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.

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by cwbrandsma on Monday July 18, 2016 @06:26PM (#12118383)
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.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by betenoire on Monday July 18, 2016 @06:34PM (#12118419)
yes you have. you've moved it into the subjective by requiring pleasing aesthetics
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by khedoros on Monday July 18, 2016 @07:31PM (#12118602)
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.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by betenoire on Monday July 18, 2016 @07:41PM (#12118626)
right, flaws are subjective. I'll try that one on my QA team next time they file a bug report ;)
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by snovv_crash on Tuesday July 19, 2016 @04:18AM (#12120525)
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?

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by rjbwork on Monday July 18, 2016 @07:12PM (#12118538)
>has tabs

>literally trash

Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by vorotato on Monday July 18, 2016 @04:38PM (#12117931)
Why have the word perfect then?
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by aurelianito on Monday July 18, 2016 @05:04PM (#12118046)
For the same reason we have the word infinity.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by fallo on Monday July 18, 2016 @05:36PM (#12118193)
But infinity does exist...?
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by ChristianBundy on Tuesday July 19, 2016 @12:19AM (#12119620)
Infinity exists the same way that perfection exists. Abstractly.
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by abakker on Monday July 18, 2016 @04:54PM (#12118004)
idealism?
Re:Code Is Never “Perfect”, Code Is Only Ever “Good Enough” by Retra on Monday July 18, 2016 @08:33PM (#12118801)
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.