Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple, correct, fast: in that order

drewdevault.com

Post reply on HN
Print view View original

301–310 of 349 posts

Re: Simple, correct, fast: in that order

#301

Post by icc97 »

KirinDave wrote: post #153
kibwen wrote: post #136

Earlier quoted context omitted.

If that's the case then the author is attacking a straw man, because nobody (besides Dijkstra) is suggesting that we rewrite all the software in the world in Coq in order to 100% eliminate bugs at the cost of simplicity.

That's not what Coq would do, and a misrepresentation of Dijkstra's position. We certainly could use tools like TLA+ to assist us with existing code. Folks are using "simple" and "easy" interchangeably here. That's probably inappropriate.

> Folks are using "simple" and "easy" interchangeably here. That's probably inappropriate.

Agreed, see Rich Hickey's "Simplicity Matters" presentation on the difference [0].

Simple-Complex vs Easy-Hard

[0]: https://www.youtube.com/watch?v=rI8tNMsozo0

Re: Simple, correct, fast: in that order

#302

Post by h0p3 »

Correct, [Simple|Fast]: In That Order.

The above is definitely the correct algorithm. Surely you don't think it is wrong! Come at me, bro!

If you aren't trying to make your representation correct, then why bother? Correctness is either the telos or closest of these in the pursuit of the telos (the assumed intrinsic purpose). To make it simple and fast are the instrumental (and heuristical) means to increasingly correct versions of that correctness end(s). You can only ever simplify a representation (hello, Kant!) because you never have complete (hello, Gödel!) access to the thing-in-itself directly.

The representation is the only thing you can consciously (the Daseinic emergent result of the non-conscious [that you know of: problem of other minds, OOO, dualist's hard problem of consciousness, etc.] aspects of your brain using language to talk to itself) attend to; it's the only way to tell and retell these stories to yourself. How correctly can you recursively represent correctness? I can only begin to meaningfully compute by starting with a meaningful notion of correctness as my foundation (however flawed it may objectively be), else it is meaningless. What does it mean to correctly tell yourself about an object if you don't assume the concept of correctness in how you tell yourself about an object?

In a sense, you beg the question of the Ontological Proof (hello Kantian idealist vs Gödelian realist in dialectic!), the reality of the possibility of the goodiest good of your program (and I suggest even beyond), in thinking about the telos of your program (and, clearly, you change your mind about what counts as that).

Simplifying and/or optimizing a representation already begs the question of having something to be correct about. "Simplify" according to what standard? The pursuit of correctness is the necessary precondition to having a reason to take the means. Epistemic justification in coding computers (be they silicon or brains) is inevitably tied to this telic processs and metanarrative. We do not escape the chain of sublations. Be a transcendental coder! I believe in you, folks. I know you care about correctness, deep down. Don't you want to be correct about this code too?

It's dangerous to go alone! Take this: https://plato.stanford.edu/entries/dialetheism

------------------------------

https://philosopher.life/

Re: Simple, correct, fast: in that order

#303

Post by whack »

ben509 wrote: post #253
whack wrote: post #140

Earlier quoted context omitted.

Sure, specific optimizations in specific markets may not be worth the cost they incur. Or they may not be valuable enough to overcome other weaknesses in the project. And yet, if someone tried to sell a server CPU today that was not pipelined, not OOO, and didn't have branch prediction, it would absolutely tank in the marketplace. I never said that performance optimizations should always be implemented. Just that per…

> And yet, if someone tried to sell a server CPU today that was not pipelined, not OOO, and didn't have branch prediction, it would absolutely tank in the marketplace. You could sell it as a niche product for high security applications, since OOO execution is a nasty side-channel.

That's an interesting idea. A "so simple it can't have bugs" design would never win over the mainstream-market, but it might be able to find a niche among extremely security-conscious users. This might be a great project for the open-source community to take on.

Re: Simple, correct, fast: in that order

#304

Post by asragab »

AstralStorm wrote: post #243
asragab wrote: post #199

I think to those that are asserting that correctness comes first are somewhat missing the point. One, a simple solution is still a solution, that is if your code doesn't solve the problem, you can't stop. I think the author is suggesting that truly _correct_ code (code that produces the correct output under all circumstances) is only attainable iteratively, and if your code is not simple (and let's also remember here…

In practice of many years, I haven't found iterative approach to produce either simple or easily maintainable code. If tends to grow rings instead. Each layer is relatively simple but altogether neither it is performant nor simple. The simple code of present was almost always written by someone who understands the problem domain really well in one or two tries.

Yeah, maybe iterative as a concept is too facile a concept to contain what is meant here. Maybe "fractal", or recursive is better. Maybe though that's the point, it is hard after "multiple rings" to make code simple anymore, so better start off trying to optimize for simple first. Correctness requires exposure to cases you didn't know you didn't know (unknown unknowns).

This is one of the reasons why I am suspicious about the long-term saliency of so-called "smart contracts" on the blockchain. The immutability of code, while super amazing for digital assets, seems like a horror-show of a liability for dApps.

Re: Simple, correct, fast: in that order

#305

Post by msla »

DannyB2 wrote: post #89
karma_fountain wrote: post #85

Earlier quoted context omitted.

Seen this several times when someone refactors. The code is much simpler and easier to read, but does not actually work for several important test cases anymore. I've never thought of simplicity adding upfront cost. That's probably true, but also true that it pays dividends later on in the project.

If it no longer works then I don't consider that to be "refactoring" but "rewriting". I think of refactoring as a series of SIMPLE transformations that clearly do not have any effect on the correctness (or incorrectness) of the code. That is, there is no possible change in behavior. And think of the word "factoring" as in high school algebra. or rather "factoring out" something. I have a dozen examples of this calcul…

> I think of refactoring as a series of SIMPLE transformations that clearly do not have any effect on the correctness (or incorrectness) of the code. That is, there is no possible change in behavior.

This kind of transformation is precisely what the person who coined the term meant: Taking code which works and turning it into easier-to-read code which works precisely as well, because refactoring never introduces a change in behavior.

To quote Martin Fowler and Kent Beck:

> A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs.

[snip]

Not a direct quote this time:

> Fixing any bugs that you find along the way is not refactoring. Optimization is not refactoring. Tightening up error handling and adding defensive code is not refactoring. Making the code more testable is not refactoring – although this may happen as the result of refactoring. All of these are good things to do. But they aren’t refactoring.

https://dzone.com/articles/what-refactoring-and-what-it-0

Re: Simple, correct, fast: in that order

#306

Post by wellpast »

swsieber wrote: post #296
wellpast wrote: post #290

Earlier quoted context omitted.

The world, from software’s perspective at least, isn’t growing in complexity. What leads one to that?

The world growing more complex from the software's perspective. And by that I mean, it has to account for more scenarios or do additional things... unless your software is growing in complexity while you're only removing features... Bugs in software come from thinking we're simplifying the world in one way though the program, while in reality it receives a slightly different picture.

A well-built software system doesn't have to grow in complexity over time. More features does not equal more complex in the true sense of Simple.

Faulty data models and system designs -- that aren't fixed -- lead to ever-increasing complexity. But that is the fault of the data model/designer.

I.e., there is a way to build (and grow) systems w/o linear increase in complexity -- but it takes a particular rare skill set.

Re: Simple, correct, fast: in that order

#307

Post by makapuf »

aidenn0 wrote: post #168
kibwen wrote: post #144

Earlier quoted context omitted.

Simplicity (however it is vaguely defined) is desirable, but at the end of the day it is a vehicle for correctness, and hence necessarily subordinate to it. Correctness is the destination of any piece of software (ultimately the goal of any piece of software is to work), and simplicity is just one route to it.

> Correctness is the destination of any piece of software "Good enough" is the destination of any piece of software. Sometimes that means correct, but more often it means "oh yeah, sometimes it starts acting funny, just restart it when that happens"

Seems a bit like the "worse is better" philosophy :

    It is slightly better to be simple than correct.
See https://en.m.wikipedia.org/wiki/Worse_is_better

Re: Simple, correct, fast: in that order

#308

Post by torstenvl »

DannyB2 wrote: post #71

When I was in school in the 70's. (That's NINTEEN seventies.) There was this book called The Psychology of Computer Programming. This predates the microcomputer era as we know it. Punched cards were still common when the book was written. A computer was to control a new assembly line for a car company. They couldn't get the software to work. They called in an outside insultant. The outsider developed a program that w…

You cannot have correctness without simplicity.

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system." - John Gail

Re: Simple, correct, fast: in that order

#309

Post by wellpast »

cromano wrote: post #284
wellpast wrote: post #251

Earlier quoted context omitted.

Anyone who has spent any time developing anything but a tiny software system knows that the biggest impediment to productivity (feature delivery, bug fixing, etc) is the complexity of the system at hand. In a sense, this post is simply stating the obvious. The biggest differentiator of skilled software practitioners is the ability to construct simple systems. To call this claim panglossian or meaningless is to hold t…

> The biggest differentiator of skilled software practitioners is the ability to construct simple systems. I would say it's to construct simple enough systems, and the hallmark of skill is a developer's ability to define enough .

I believe you're conflating simplicity/complexity with flexibility.

_One_ hallmark of developer ability is the discretion/wisdom/experience to know how flexible to make the thing. (How to prioritize and limit feature-creep, etc.)

But this is different than Simplicity. A general purpose programming language or database -- highly flexible/generic systems -- for example, can be built well/simple. But so can highly _specific_ systems.

In both cases though, one can build something that is decoupled and manipulable or one can build something that is coupled and rigid -- and the ability to do so is a function of skill set _not intrinsically_ a function of time. In other words, a skilled developer doesn't have to "take time" to deliver a Simple capability.

Re: Simple, correct, fast: in that order

#310

Post by everybodyknows »

marcosdumay wrote: post #66
s3m4j wrote: post #54

Earlier quoted context omitted.

In my experience, it's been easier to push UTC time all the way from the db to the user javascript and operate on time then, than trying to manipulate time before sending to the user. YMMV, and it's only web dev.

There are many kinds of data that get saved as time. For some, yes, it's better to add and remove the TZ at the interface. For some the TZ carries meaning by itself, and it must be stored and keep constant everywhere. For some the TZ carries meaning, but the time must be converted for display. Know your data, and most of your problems get easy.

Yes, that's the crucial distinction -- whether the TZ, with its coarse encoding of the geography of origin, carries significance to the consumer of the data.
Post reply on HN