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

331–340 of 349 posts

Re: Simple, correct, fast: in that order

#331

Post by traviscj »

close04 wrote: post #138
DannyB2 wrote: post #108

Earlier quoted context omitted.

If correctness is some kind of continuum rather than a binary choice, then pick whatever trade offs, cost, and other factors you want. Plenty of times correctness is binary. In some cases it would be: passes all tests. Or: meets all requirements. Even if it could be "more" correct (or "more" simple), but those aren't part of the tests / requirements.

I always thought correctness begins when the result of your work does what it's supposed to do. Maybe it's supposed to move from A to B, maybe it should do it in under x seconds, maybe it should go via Y, maybe it has to be easily understood by a 6 years old, etc. But I can't really imagine something that has simplicity as the only requirement ("nothing" is the simplest thing so that requirement would always be met w…

I’ve noticed a pattern where the simplest solution DOES accomplish the goal, but isn’t what a user might consider the “shortest path”. How do you count a workaround where it technically can accomplish the end result, but requires a minor annoyance? What about a major annoyance?

What about a process so painful nobody has even thought of it?

Re: Simple, correct, fast: in that order

#332

Post by masklinn »

y4mi wrote: post #264
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,…

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

For very specific cases? Sure, but none of the comments talking about UTC everywhere cares to specify this rather important bit.

Unless restrictions are specified I will assume we're talking about the general case, and for the general case it's just plain wrong.

Re: Simple, correct, fast: in that order

#333

Post by BlackFly »

DannyB2 wrote: post #119
BlackFly wrote: post #101

Earlier quoted context omitted.

How sure are you that a given program is bug free? I feel that only very rarely would I ever assert 100%. In fact, I would generally assert with 100% confidence that there is some overlooked edge case. How many users that bug may affect... well I would generally give that a small percentage, but it still doesn't hit the boolean state of correct. So correctness is generally never satisfied in my mind. At any given mom…

I can not be sure the code was bug free. It was an anecdote in a book, the focus of which was more about the psychology of those who wrote the code. But it worked, and the first program did not work. The non working code's author took pride in the speed of his code.

Don't get me wrong, I think its an excellent anecdote. I just shy away from a focus on correctness since in my experience people who prioritize correctness above all else usually make a shambles. I feel that people who prioritize simplicity still understand that it still needs to work more or less correctly.

Re: Simple, correct, fast: in that order

#334

Post by close04 »

traviscj wrote: post #331
close04 wrote: post #138

Earlier quoted context omitted.

I always thought correctness begins when the result of your work does what it's supposed to do. Maybe it's supposed to move from A to B, maybe it should do it in under x seconds, maybe it should go via Y, maybe it has to be easily understood by a 6 years old, etc. But I can't really imagine something that has simplicity as the only requirement ("nothing" is the simplest thing so that requirement would always be met w…

I’ve noticed a pattern where the simplest solution DOES accomplish the goal, but isn’t what a user might consider the “shortest path”. How do you count a workaround where it technically can accomplish the end result, but requires a minor annoyance? What about a major annoyance? What about a process so painful nobody has even thought of it?

It's nigh impossible to solve any complex issue with the "simplest solution" from the first try. This means that when you're faced with a complex issue you will postpone the fix because it's not the simplest.

And you never know if it can be done in an even simpler fashion later.

Re: Simple, correct, fast: in that order

#335

Post by a1369209993 »

Const-me wrote: post #320
a1369209993 wrote: post #318

Earlier quoted context omitted.

https://www.intel.com/content/www/us/en/processors/xeon/xeon... shows at least six volumes of datasheets, and I still haven't found a instruction set refence. I have found https://www.intel.com/content/www/us/en/processors/xeon/xeon... (helpfully labeled "Datasheet, volume 2", rather than anything related to it's contents) which describes a subset of the aformentioned ten thousand random control registers. So no, Int…

> I still haven't found a instruction set reference. X86-64, SSE, AVX, AVX-512, AES-NI, etc. Their key selling point is software compatibility. > Intel does not make [simple cores] The cores are quite simple by today’s standards; otherwise Intel wouldn’t be able to pack 72 of them on a single chip. IME is unrelated to the cores, it’s a separate piece of silicon. But if you don’t like the IME and don’t need backward c…

> X86-64, [etc]

So it has the ten thousand x86 and x64 registers in addition to the ten thousand ?PCI registers?

> The cores are quite simple by today's standards

That's my point; today's CPUs don't have "ultra-simple" as a option (at modern feature densities).

> IME is unrelated to the cores

Fair point, I probably should have added "and doesn't have technicalities like builtin malware" to my original post.

> https://www.qualcomm.com/products/qualcomm-centriq-2400-proc...

This looks interesting, although I'll need to research a bit more (and "SOC - Features - Integrated management controller" isn't encouraging). Thanks!

Re: Simple, correct, fast: in that order

#336

Post by kungtotte »

sethrin wrote: post #330
kungtotte wrote: post #319

Earlier quoted context omitted.

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…

Oh, that's me then :) I didn't put two and two together because I knew him as just beagle, and it was a long time ago that I hung out with him. We played together in a gaming community known as ShackTac or ShackTactical, playing a game called Armed Assault/ArmA.

Way back when a bunch of us put our names into a custom name file for XCOM so people could make campaigns featuring ShackTac people instead of generic dudes. I completely forgot about that until you reminded me. It must be five years since I talked to him :)

Re: Simple, correct, fast: in that order

#338

Post by y4mi »

masklinn wrote: post #332
y4mi wrote: post #264

Earlier quoted context omitted.

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

For very specific cases? Sure, but none of the comments talking about UTC everywhere cares to specify this rather important bit. Unless restrictions are specified I will assume we're talking about the general case, and for the general case it's just plain wrong.

from my point of few its the other way around.

There are very few applications that need to schedule events into the future, and that is literally the only situation where you have to worry about the timezone.

Btw, keeping the timezone is insufficient as well if you're building a calendar/scheduler. If the user changes the timezone after scheduling the event... do you keep to the old one and alert him whenever, or do you adjust? There are a lot of edge cases with schedulers -- yet as i said before, most applications don't schedule into the future. They're mostly just doing things right now or within the next few minutes and keeping a log of their actions.

Re: Simple, correct, fast: in that order

#339

Post by sethrin »

kungtotte wrote: post #336
sethrin wrote: post #330

Earlier quoted context omitted.

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…

Oh, that's me then :) I didn't put two and two together because I knew him as just beagle, and it was a long time ago that I hung out with him. We played together in a gaming community known as ShackTac or ShackTactical, playing a game called Armed Assault/ArmA. Way back when a bunch of us put our names into a custom name file for XCOM so people could make campaigns featuring ShackTac people instead of generic dudes.…

Oh cool :) Yeah, I did get the impression that the name list represented more former acquaintances than current ones, and I think he got pretty burnt out on YouTube generally. He seemed like a pretty great guy, and the series was excellent, so it seems you have a small measure of reflected glory at least :)

Re: Simple, correct, fast: in that order

#340

Post by masklinn »

y4mi wrote: post #338
masklinn wrote: post #332

Earlier quoted context omitted.

For very specific cases? Sure, but none of the comments talking about UTC everywhere cares to specify this rather important bit. Unless restrictions are specified I will assume we're talking about the general case, and for the general case it's just plain wrong.

from my point of few its the other way around. There are very few applications that need to schedule events into the future, and that is literally the only situation where you have to worry about the timezone. Btw, keeping the timezone is insufficient as well if you're building a calendar/scheduler. If the user changes the timezone after scheduling the event... do you keep to the old one and alert him whenever, or do…

> from my point of few its the other way around.

> There are very few applications that need to schedule events into the future, and that is literally the only situation where you have to worry about the timezone.

My experience is the exact opposite: there are few applications which only store past dates, and in those said date is usually indicative/barely even relevant and could just as well be part of a freeform comment or removed entirely.

Post reply on HN