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

321–330 of 349 posts

Re: Simple, correct, fast: in that order

#321

Post by AstralStorm »

taneq wrote: post #315
kungtotte wrote: post #272

Earlier quoted context omitted.

I have a hard time seeing how profilers don't at least point you in the right direction. Or are we using different definitions of the word? They tell you how much time is spent in any given section of your program. If 80% of the time is spent in 20% of the code, it's usually a safe bet that's where you should start looking!

Generally I agree, but after you've picked off a few low hanging fruit, you'll end up with the profiler pointing at the function which does most of your grunt work, at which point you'd expect that to take up most of the time. Once you've got this pretty optimized and it's still taking up the lion's share of your execution time, you have to look elsewhere (probably changing your overall approach or applying some high…

Yes, at that point you typically get to apply far reaching architectural changes or switch out the algorithm.

Sometimes it is quicker to start with just that instead of "polishing a turd". You can get it to be shiny but still nowhere near as shiny as gold.

Hope the code is testable and reasonably easy to modify. Otherwise it's going to be a rewrite.

The profile is then useful as a benchmark on real data. If you have enough time, you can turn that into a high level performance test.

Re: Simple, correct, fast: in that order

#322

Post by AstralStorm »

AnIdiotOnTheNet wrote: post #131
theandrewbailey wrote: post #11

Earlier quoted context omitted.

Agreed. Software that does what it's supposed to is better than software that is simple (or fast), but buggy.

Which is why everyone uses OpenBSD instead of making a tradeoff with a different OS that isn't designed as securely.

Users go for usability features first, with an OS that is good enough. Good looks second. They can tolerate a few weirdness and quirks as long as they can get the job done without cursing the thing. They will even tolerate non critical crashes sometimes (no or little data loss).

OpenBSD is not bug free at all, it is just security oriented in the implementation.

Windows got traction because it has even better hardware support, a bunch of backroom OEM deals and nice UI features (at the time of 95), then went far on software availability.

Re: Simple, correct, fast: in that order

#323

Post by AstralStorm »

SamuelAdams wrote: post #70
lopatin wrote: post #26

Earlier quoted context omitted.

I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones.

I agree - UTC is the way to go. The point of the example was to illustrate how simple could be detrimental to a significant portion of your userbase. How about another example? You're building an android application. Let's pretend there's an API in the latest version of Android that reduces a dozen lines of code down to one function call - ShinyNewMethod(). You can use that ShinyNewMethod() call. It's certainly simpl…

This results in funny things like android support library.

Re: Simple, correct, fast: in that order

#324

Post by josmala »

The Amdahl's law applies here also, if your code is slow everywhere, making the slowest part faster isn't going to help much, so there needs to be some basic minimal consideration given the performance throughout the project. Or better yet, have well performing default ways of doing things and avoid badly performing ways.

In worst case failing to do that will require write entire project from scratch because basic data structures and structure of code is antithesis for performance and there is not a point that you can optimize. A reasonable default is using vectors over linked lists. A more complex choice is using struct of vectors rather than vector of structs. And neither of those choices are easy to do for data structures that really matter late in the project.

Re: Simple, correct, fast: in that order

#325

Post by AstralStorm »

cbsmith wrote: post #86
michaelcampbell wrote: post #32

Earlier quoted context omitted.

The old yarn I'd heard for years is close to this. Make it work. Make it work right. Make it work fast. In that order. Now it could be argued that "work right" can be read as "make it (work right)", or "(make it work) right", or both, but I think the point of this saying is that the "fast" part should always come later.

The make it work fast portion isn't controversial. Premature optimization and all that... The "make it work" implies a level of correctness & performance that is acceptable, which is why any subsequent steps are after thoughts.

The missing part is "make it workable". By that I mean reasonably easy to modify. This may or may not involve simplicity but usually involves modularity and lack of hard impingement interdependencies - weak coupling.

If you skip that, you will relatively quickly reach the point of a full rewrite.

Re: Simple, correct, fast: in that order

#326

Post by AstralStorm »

coryfklein wrote: post #241
SamuelAdams wrote: post #2

I would argue that correct is more important than simple. Consider timezones: it's simpler to pretend there's 24 time zones, one for each hour. But the correct assertion is there's 37 time zones (as of this writing). So, the simple solution results in a third of your potential user base having issues. Other issues to pick: accessibility, cross-browser compatibility, legacy device compatibility... the list goes on.

I don't think what you're saying is in conflict with the OP: > The complex problem comes later, and it’ll be better served by the composition of simple solutions than with the application of a complex solution. Complicated problem domains can be made into simple ones by breaking them down into their constituent components. You can solve time zones by having 5000 Rube-Goldberg-esque lines of if/else-if statements, or…

Or you can end up with a mishmash of components instead of statements.

Premature abstraction is a kind of premature optimization, except you're not buying performance.

Bad abstractions tend to stay in for a long time.

What matters is clear delineation between functional components and weak binding, so that internals can change, and that the interfaces are relatively minimal.

Re: Simple, correct, fast: in that order

#327

Post by AstralStorm »

tacon wrote: post #298
ddellacosta wrote: post #64

I can't really understand the equivocating tone a lot of folks are taking in response to this, and more importantly I can't wrap my head around how you could make such a statement in the first place: without correctness you've got nothing. Stating authoritatively that correctness comes after...anything is incomprehensible to me. It's possible to have a correct solution that is neither simple nor fast, and it can be w…

I am reminded of this classic snark from The Elements of Programming Style (1974)[0]: "Some compilers allow a check during execution that subscripts do not exceed array dimensions. This is a help … many programmers do not use such compilers because “They’re not efficient.” (Presumably this means that it is vital to get the wrong answers quickly.)" (Page 85) [0] https://en.wikipedia.org/wiki/The_Elements_of_Programmin…

Usually the real reason is that such checks are pointless as they do not pinpoint the bugs. They are too late. You need a real stack trace to begin debugging such issues.

Languages like Ada Spark or Rust tend to rarely use or need such runtime checks. (they are available as an option to check unsafe code)

Others like Python and Java do check and give you traces. Not for free though.

And then you probably want something more powerful, such as a virtual machine like Valgrind; full sanitization of Address Sanitizer, etc.

Re: Simple, correct, fast: in that order

#328

Post by AstralStorm »

wellpast wrote: post #309
cromano wrote: post #284

Earlier quoted context omitted.

> 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 _spec…

Sometimes you just want a hammer, not a swiss army knife.

And sometimes it is good to have a replaceable head on the hammer.

Re: Simple, correct, fast: in that order

#329

Post by AstralStorm »

shoo wrote: post #14
MikeTaylor wrote: post #5

This title is misleading. The post actually says that the reason "simple" comes first is because without it you can't have "correct" (nor "fast", not that that matters so much). So he's not saying simple is most _important_, just that it comes first chronologically, and has the other two as consequences.

e.g. Gall's law > A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Surprisingly to some, this is neither a law nor true.

A complex system with a good workable and testable architecture will work, starting with passing the tests down to satisfying the user...

Such systems are not designed in detail but in general, and usually start with a single, simple but powerful overarching idea, which is actually quite complex to implement, but ends up working evidently well once even halfway done.

Examples would be message passing architecture, event driven programming, time tracking, microservices, reactors, literate APIs, contract programming, Model-View-* and more... Note how half of those deal with reducing coupling by adding complexity.

Re: Simple, correct, fast: in that order

#330

Post by sethrin »

kungtotte wrote: post #319
sethrin wrote: post #280

Earlier quoted context omitted.

Profilers have limitations like anything else, and it's possible to be pointing the flashlight in the wrong place. I probably wouldn't include that as a list item. By the by, is there more than one kungtotte on the Internet? It took me a minute to think why that name was so familiar, but then I remembered watching a few hundred Beaglerush videos.

There must be more than one, because I've never heard of Beaglerush. I've used this handle for a long time though (20 years or so), so it's all over the internet.

Kk, thank you for indulging my curiosity. Beaglerush is a very humorous Aussie who is notable for a video series on the Long War mod for the game XCOM. Long War turns a moderately challenging game of thirty or forty hours into an extremely complex, impossibly difficult ordeal of at least 400 hours per game. Beagle apparently often uses the handles of his friends as character names, and one of the best/worst parts of XCOM is that it's really good at making you care about the little blobs of pixels you order into virtual mortal peril, so to me kungtotte is like, the hero of 100 missions :)

If you're into strategy games, XCOM is good, and Long War is matchless. However, Beaglerush is actually surprisingly entertaining even if you don't care for his subject; the girlfriend is still not much into the game, but after the first couple episodes she insisted on watching the other hundred-thirty-odd videos. It's probably not everyone's cuppa, but it could be a thing.

Post reply on HN