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

261–270 of 349 posts

Re: Simple, correct, fast: in that order

#261

Post by j45 »

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…

+1. Simplicity won't work if it isn't correct.

Simple correctness is the best way to create beginners that use software to get faster results. Fast isn't all about computation - it's taking the least amount of the user's time as reasonably neccesary.

Re: Simple, correct, fast: in that order

#262

Post by lszu »

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…

Agree. In many (most?) cases there is no formal, verifiable correctness proof. And then you are way better of with the simpler solution once feedback from the real world arrives.

Re: Simple, correct, fast: in that order

#263

Post by kungtotte »

kibwen wrote: post #149
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 demo…

I think the core consideration is that software isn't static, and a machine that is held together with chewing-gum and silly string can produce the correct output and be a terrible machine at the same time.

What happens when it breaks? What happens when you need to produce doodads as well as gizmos, or a different size gizmo is desired? Who wants to reach inside the silly string and hope for the best?

I'm reminded of that old saying that even a broken clock is right twice a day; an overly complicated piece of software that produces the correct output is only coincidentally correct. Which I think is the point of the article.

Re: Simple, correct, fast: in that order

#264

Post by y4mi »

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

most applications don't need to schedule events into the future though and its a smart strategy if all you need to worry about is the past

Re: Simple, correct, fast: in that order

#265

Post by a1369209993 »

whack wrote: post #145
Sir_Cmpwn wrote: post #56

Earlier quoted context omitted.

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.

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

If you can find a CPU that has the same number of non-cache[1] transistors as a Intel/AMD chip, but spends them on a larger number of simple (and preferably independent/non-hyperthreaded) cores, rather than squandering them on speculative execution and ten thousand obscure model specific registers, I would absolutely buy several of them.

1: and similar amounts of cache, of course.

Re: Simple, correct, fast: in that order

#266

Post by jackhack »

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…

>> They called in an outside insultant.

This is either a great typo, or a hilarious moniker I have somehow missed (almost 40 years in the business). Either way, it's worth recognizing.

Equal parts hilarious and accurate as "/in/con/sultants" are often brought in to play the part of the court jester -- they can speak the hard truths no-one else could, and survive.

>>"Yes, but MY program ACTUALLY WORKS". If the program doesn't have to work, I could make it read 100 cards per second.

I think I wrote a device driver like that, more than once. :( Fast as hell, to the point of outstripping the bitrate of the device it talked to, and about as useful as a sailboat on the moon.

Re: Simple, correct, fast: in that order

#267

Post by falcolas »

jackhack wrote: post #266
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…

>> They called in an outside insultant. This is either a great typo, or a hilarious moniker I have somehow missed (almost 40 years in the business). Either way, it's worth recognizing. Equal parts hilarious and accurate as "/in/con/sultants" are often brought in to play the part of the court jester -- they can speak the hard truths no-one else could, and survive. >>"Yes, but MY program ACTUALLY WORKS". If the program…

There's a great Dilbert where Dogbert wants to both con and insult someone. So he goes to consult for Dilbert's PHB.

Re: Simple, correct, fast: in that order

#268

Post by fwip »

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…

They did use OP's strategy in the CPU industry.

The first CPUs were simple as heck. They spent 20 years making them reliable(and faster without compromising simplicity, mostly just node-shrinks), and they've only really been complicating the architecture in the last 30 years.

Re: Simple, correct, fast: in that order

#269

Post by s3m4j »

taeric wrote: post #62
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.

This works for things that have happened. It doesn't work too well for schedules. In those cases, the timezone of the source matters, heavily.

To this day, knock on wood, I have had success at voluntarily avoiding those issues ^^ (aside from school assignements)

Re: Simple, correct, fast: in that order

#270

Post by kungtotte »

gwbas1c wrote: post #245

That mantra, taken blindly, leads to software that won't scale under realistic circumstances. I once worked on a project that failed because the lead programmers did not want to learn how to use a database. They insisted on using an ORM incorrectly, and almost all of their code needed to be rewritten in order to handle a typical anticipated load. Granted, the entire codebase was full of "simple" for each loops, but t…

There's a difference between simple and simplistic, and there's absolutely a value in keeping things simple instead of complex. So much so that I think it's reasonable to state categorically that if there is a simple solution that works it's always better than the complex solution.

Not using a database when the solution calls for one clearly violates the "works" principle. And obviously, using a tool incorrectly (the ORM) trumps anything else. That's a tautology.

Post reply on HN