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

141–150 of 349 posts

Re: Simple, correct, fast: in that order

#141

Post by bluetomcat »

mindB wrote: post #127

Interesting that he hit on the top three points in the pony philosophy[1] but in a very different order than they chose. For pony, the order is: 1. Correctness 2. Performance 3. Simplicity 4. Consistency 5. Completeness I think I tend to agree with that order more. While simplicity tends to be helpful with performance and correctness, there are very few cases where you'd sacrifice correctness/performance for simplici…

Incorrectness for a minority of inputs can also be tolerated if it allows for a vastly more efficient and simple implementation, provided that the environment or driven machinery has failsafe mechanisms and wouldn't be able to cut an arm or a leg in case of an error.

For example, think about a game that runs quickly and is playable but crashes occasionally, versus one that lags all the time but never crashes.

Re: Simple, correct, fast: in that order

#142

Post by dredmorbius »

masklinn wrote: post #137
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 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. That's a flagrant example of "simple and wholly incorrect". If you don't store timezones, your future dates will eventually turn out incorrect when timezone offsets change e.g. create a meeting at 9AM local,…

The UTC example allows the user to translate output using localised tools.

The solution isn't incorrect, it is modular.

Re: Simple, correct, fast: in that order

#143

Post by gkya »

DannyB2 wrote: post #38
martingxx wrote: post #12

Earlier quoted context omitted.

Correctness (and any other kind of change in behaviour) is easier to achieve if things are simple. Changes are not necessarily easy or even possible to make safely if things are correct but not simple. "Simple" is a proxy for "can be changed safely" and so IMO is the most important quality to have.

I think you do whatever it takes to achieve correctness. If simplicity helps achieve correctness, then great. But correctness is not always simple. Most people think there is a leap year every four years. They are wrong.

I don't think simple means discard if complex. It means using the simplest and most obvious tools (algorithms, libraries, &c) possible in order to achieve a correct enough software. So it does not mean discarding intricacies of timekeeping, but implementing it with the clearest, simplest use of abstractions and methods possible.

Re: Simple, correct, fast: in that order

#144

Post by kibwen »

Dylan16807 wrote: post #92
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…

> If the program doesn't have to work, I could make it read 100 cards per second. > Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness. Correctness isn't binary. Roughly no software today is 100% correct, but for most purposes you'd still pick the current version over a highly complex, slower, more-correct version. Simplicity can save you a lot of cost as…

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.

Re: Simple, correct, fast: in that order

#145

Post by whack »

Sir_Cmpwn wrote: post #56
whack wrote: post #41

The OP's advice, if applied in CPU industry, would be disastrous. Modern desktop/server CPUs are incredible complex... in order to drive maximum performance. Pipelining, OOO execution, branch prediction and speculative execution: these are all features that introduce tremendous amount of architectural and design complexity. In many cases, they also harm correctness, because they can lead to functional and security bu…

The attitude of the CPU industry in this regard led to some recent well-publicized, very bad, and nigh-unfixable security vulnerabilities, as you might have heard.

And yet, I don't see you or anyone else committing to buy ultra-simple non-pipelined non-OOO desktop/server CPUs.

If you insist on only hiring chauffeurs who drive at 100mph, you can hardly complain when they get into a few accidents.

Re: Simple, correct, fast: in that order

#146

Post by masklinn »

dredmorbius wrote: post #142
masklinn wrote: post #137

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. That's a flagrant example of "simple and wholly incorrect". If you don't store timezones, your future dates will eventually turn out incorrect when timezone offsets change e.g. create a meeting at 9AM local,…

The UTC example allows the user to translate output using localised tools. The solution isn't incorrect , it is modular .

> The UTC example allows the user to translate output using localised tools.

So you provide an alarm clock which is works as neither a clock nor an alarm.

> The solution isn't incorrect, it is modular.

It's either not correct or not a solution, either way it's useless.

I also like how proponents of "simplicity at all cost" apparently assume/assert the composition of two systems is no more complex than either, and that there is no additional complexity to the composition layer.

Re: Simple, correct, fast: in that order

#147

Post by jpalomaki »

Sir_Cmpwn wrote: post #55
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.

If you cannot achieve correct without simple, redefine correct.

Having software people interact directly with the user/customer (internal or external) can be very useful because minor changes in requirements can make a huge difference in implementation complexity.

Re: Simple, correct, fast: in that order

#148

Post by ConceptJunkie »

Anyone can write complex, brittle code, and often even get it to work.

The real superstars solve the same problems with simple code.

I recall a fellow student in CS in the 1980s who used to brag about how many lines of code he wrote to solve an assignment. I never understood that mentality. His programs were always 2-3 times longer than mine. But now that I've had many years in the industry, it almost seems that a lot of people believe more code is better.

Re: Simple, correct, fast: in that order

#149

Post by kibwen »

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…

> Correctness comes first. Simplicity is highly desirable, adds additional cost, but always comes after correctness.

Seconded. I'm highly confused at how many upvotes the OP has gotten in such a short time despite appearing to say that implementation details matter more than program output. A beautiful machine that doesn't work is, at best, a statue. I'm all for the existence of pretty things that do not need to demonstrate inherent practicality, but most people are not printing out source code for use as wallpaper.

Re: Simple, correct, fast: in that order

#150

Post by comboy »

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.

He made up his mind, don't confuse him with facts.
Post reply on HN