6 ms·
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
by rrradical 10y ago
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 http://asivitz.com/posts/programming_in_haskell)
- joe_the_user 10y agoActually, 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/ http://hypothesis.works/articles/calculating-the-mean/
- skybrian 10y agoGreat link! But also, the mean is itself an imperfect summary of some distributions. Any single-number summary will be misleading in some cases.
- bradleyjg 10y agoAnscombe's quartet is a great illustration of that. https://en.wikipedia.org/wiki/Anscombe%27s_quartet https://en.wikipedia.org/wiki/Anscombe%27s_quartet
- fbonetti 10y agoThat'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.
- Retra 10y agoFloating point isn't really the baseline for great mathematical structure, it's just a pervasive hardware standard.
- cwbrandsma 10y agoI 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.
- vorotato 10y agoWhy have the word perfect then?
- abakker 10y agoidealism?
- aurelianito 10y agoFor the same reason we have the word infinity.
- fallo 10y agoBut infinity does exist...?
- ChristianBundy 10y agoInfinity exists the same way that perfection exists. Abstractly.
- jungrothmorton 10y agoYou’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.
- dahart 10y ago> 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 http://www.complex-a5.ru/polyboolean/comp.html)
- edejong 10y agoCertainly 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.
- Retra 10y agoThe 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.