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

Testing is better than data structures and algorithms

nedbatchelder.com

Post reply on HN
Print view View original

81–90 of 178 posts

Re: Testing is better than data structures and algorithms

#81

Post by hinkley »

matheusmoreira wrote: post #58
chamomeal wrote: post #50

Earlier quoted context omitted.

Dang I got this book a few weeks ago and still haven’t cracked it open. Maybe today is the day

The algorithm I'm talking about is at the very end of the book. If you start reading it from start to finish you might stop before you reach it. Certainly happened to me. Someone had to point it out for me to realize SICP had the answer all along. https://eng.libretexts.org/Bookshelves/Computer_Science/Prog... The explicit control evaluator. It's a register and stack machine which evaluates lisp expressions without t…

A common story with JIT languages is to go back and forth between having a bytecode interpreter and not.

The paradox is that when the interpreter is fast enough then you delay JIT because it takes longer for the amortized cost to be justified. But that also means the reasons for that high amortization cost don’t get prioritized because they don’t really show up as a priority.

Eventually the evidence piles so high nobody can ignore it and the code gets rearranged to create a clearer task list. And when that list runs out they rearrange again because now that other part is 2x too slow.

Personally I’d love to see a JIT that was less just in time. Queuing functions for optimization that only get worked on when there are idle processors. So there’s a threshold where the JIT pre-empts, and one where it only offers best effort.

Re: Testing is better than data structures and algorithms

#82

Post by janalsncm »

matheusmoreira wrote: post #69
hvb2 wrote: post #6

This feels backwards. When you have a good understanding of data structures you have the luxury of testing. If you focus on testing over data structures, you might end up testing something that you didn't need to test because you used the wrong data structures. IMHO too often people dont consider big O because it works fine with their 10 row test case.... And then it grinds to a halt when given a real problem

> too often people dont consider big O because it works fine with their 10 row test case.... And then it grinds to a halt when given a real problem The reverse also happens frustratingly often. One could spend a lot of time obsessing over theoretical complexity only for it to amount to nothing. One might carefully choose a data structure and algorithm based on these theoretical properties and discover that in practic…

Slightly related, in ML I write a lot of code which will be executed exactly once. Data analysis, creating a visualization, one-off ETL tasks.

There are a lot of times where I could spend mental energy writing “correct” code which trades off space for time etc. Sometimes, it’s worth it, sometimes not. But it’s better to spend an extra 30 seconds of CPU time running the code than an extra 10 minutes carefully crafting a function no one will see later, or that someone will see but is harder to understand. Simpler is better sometimes.

What Big O gives you is an ability to assess the tradeoffs. Computers are fast so a lot of times quadratic time doesn’t matter for small N. And you can always optimize later.

Re: Testing is better than data structures and algorithms

#83

Post by danielmarkbruce »

hatthew wrote: post #46
fuzztester wrote: post #41

Earlier quoted context omitted.

> My work involves As the GP said: >>What someone says on this topic says more about what things they have worked on in their life than anything else.

TFA isn't saying "DSA is useless", it's saying "intermediate/advanced DSA is not useful for most people". It's obvious that it's useful for some people, but I think even most people working on "large scale systems" should probably value general software engineering skills over DSA skills. The very few people who actually need DSA skills already know that the advice "you don't need DSA" doesn't apply to them.

> The very few people who actually need DSA skills already know that the advice "you don't need DSA" doesn't apply to them.

This is right. And most of those people know a lot of their job is very far removed from many other software engineers. But the prevalence of the idea "you don't really use DSA in practice" does suggest many people building applications where DSA isn't as applicable seem to misunderstand the situation. It matters in some sense - it explains why interviews at google are the way they are, why universities teach what they teach, what one should do if they really like such things.

Re: Testing is better than data structures and algorithms

#84

Post by nice_byte »

KevinMS wrote: post #54
nice_byte wrote: post #7

ignore this advice. spend plenty of time studying data structures and algorithms as well as computer architecture. these are actually difficult things that take a long time to understand and will have a positive impact on your career. study the underlying disciplines of your preferred domain. in general, focus on more fundamental things and limit the amount of time you spend on stupid shit like frameworks, build syst…

> "testing" is not fundamental. there is no real skill to be learned there, it's just one of those things that will find a way to steal your time anyway so there is no point in focusing actively on it. that's an edgy take and a red flag

it is not edgy whatsoever. it reflects the actual reality on the ground.

nobody goes to school to learn how to use git or how to write unit tests. it's not something that needs to be actively "learned", you'll just absorb it eventually because you can't escape it.

The more interesting and important things you will never "just absorb", you actually have to make a conscious effort to engage with them.

Re: Testing is better than data structures and algorithms

#86

Post by wubrr »

sarchertech wrote: post #74
wubrr wrote: post #71

Earlier quoted context omitted.

Every place I worked at, that had any kind of reliable, high-throughput concurrent system had an extensive suite of concurrent tests. https://github.com/postgres/postgres/tree/master/src/test/is... https://muratbuffalo.blogspot.com/2023/08/distributed-transa... https://learn.microsoft.com/en-us/archive/msdn-magazine/2008... https://go.dev/blog/synctest https://learntla.com/core/concurrency.html

> Every place I worked at, that had any kind of reliable, high-throughput concurrent system Pretty much anyone with high throughput is running a high throughput concurrent system, and very few companies have an extensive suite of concurrency tests unless you just mean load tests (that aren’t setup to catch race conditions). The “reliable” part of that statement might be doing a lot of heavy lifting depending on what…

I gave you several concrete examples. Your claims of 'very few companies have...' aren't very convincing, and the apparent popularity of concurrency testing isn't really a strong argument for or against it's effectiveness or do-ability.

Re: Testing is better than data structures and algorithms

#87

Post by wubrr »

teraflop wrote: post #78
wubrr wrote: post #72

Earlier quoted context omitted.

No, it's called testing many concurrent operations. Implementing a complex concurrent algorithm based on your understanding of it, without proper testing is called luck, and often called delusion.

You can't easily, automatically test concurrent code for correctness without testing all possible interleavings of instructions, and that state space is usually galactically huge. It is very easy to write multithreaded code that is incorrect (buggy), but where the window of time for the incorrectness to manifest is only a few CPU instructions at a time, sprinkled occasionally throughout the flow of execution. Such a…

It will obviously not catch all bugs. Nothing will. But it is a relatively easy and reliable way to catch many of them. It works.

Re: Testing is better than data structures and algorithms

#88

Post by wubrr »

JackSlateur wrote: post #75
wubrr wrote: post #72

Earlier quoted context omitted.

No, it's called testing many concurrent operations. Implementing a complex concurrent algorithm based on your understanding of it, without proper testing is called luck, and often called delusion.

What algorithm ? The whole idea is that algorithms are useless, and you should just write a bunch of tests and go with it Yes, if I write stuff with locks, I shall ensure that my code acquires and releases locks correctly This is completely off-topic with the original post; Also, you cannot prove something by tests; Just because you found 100000 cases where your code works does not mean there is not a case where is d…

It's not about making sure your system is 100% perfect. You cannot do that on any real sufficiently complex system. It's about testing the core functionality in a relatively straightforward and reliable way (including concurrency testing), to catch many common bugs.

Re: Testing is better than data structures and algorithms

#90

Post by JoeAltmaier »

We wrote a conferencing app and server (years before Zoom). Tested the server by having automated headless apps run in gangs, a hundred at a time, hopping from conversation to conversation, turning mic and camera on and off, logging out and logging back in. Used it for years, the Bot Army we called it. Responsible for our rock-solid quality reputation. Not API design or test classes or constraints or anything. Just, trying the damn thing, in large cases, for a long time.

When it ran an hour, we celebrated. When it ran overnight, we celebrated. When it ran a week we celebrated, and called that good enough.

Post reply on HN