Live data from Hacker News

Testing is better than data structures and algorithms

nedbatchelder.com

21–30 of 178 posts

Re: Testing is better than data structures and algorithms

#21

Pure bullshit and incompetence. > esoteric things like Bloom filters, so you can find them later in the unlikely case you need them. They are not esoteric, they are trivial and extremely useful in many cases. > Less DSA, more testing. Testing can't cover all the cases by definition, why not property testing? Why not formal proofs? Plus, in our days, it's easy to delegate testcase writing to LLMs, while they literally…

It's a strawman besmirching niche knowledge for methodology. The two aren't mutex and shouldn't be competitors. Bloom filters are really trivial to implement and are great examples of time/space tradeoffs, and are useful mostly for checking if a key isn't a member of an otherwise expensive lookup operation and so can be avoided early.

What's more concerning is "engineers" incurious about how lower levels of the stack work, or aren't interested in learning breadth, depth, or new things.

Re: Testing is better than data structures and algorithms

#22
The title is unfortunately more than a little irresponsible, considering it's the norm for many (most?) to read only the title.

There is no dichotomy here: you need to know testing as well as data structures and algorithms.

However, the thrust of the article itself I largely agree with -- that it's less important to have such in-depth knowledge about data structures and algorithms that you can implement them from scratch and from memory. Nearly any modern language you'll program in includes a standard library robust enough that you'll almost never have to implement many of the most well-known data structures and algorithms yourself. The caveat: you still need to know enough about how they work to be capable of selecting which to use.

In the off-chance you do have to implement something yourself, there's no shortage of reference material available.

Re: Testing is better than data structures and algorithms

#23
This is one of the things I'd tune in the current curriculum.

When I went to college in the late 1990s, we were right on the verge of a major transition to DSAs being something every programmer would implement themselves to something that you just pick up out of your libraries. So it makes sense that we would have some pretty heavy-duty labs on implementing very basic data structures.

That said, I escaped into the dynamic programming world for the next 15 years or so, so I almost never actually did anything of significance with this. And now even in the static world, I almost never do anything with this stuff directly because it's all libraries for them now too. Even a lot of modern data structures work is just using associative maps and arrays together properly.

So I would agree that we could A: spend somewhat less time on this in the curriculum and B: tune it to more about how to use arrays and maps and less about how to bit bang efficient hash tables.

People always get frosty about trying to remove or even "tune down" the amount of time spent in a curriculum, but consider the number of things you want to add and consider that curricula are essentially zero-sum games; you can't add to them without removing something. If we phrase this in terms of "what else could we be teaching other than a fifth week on pointer-based data structures" I imagine it'll sound less horrifying to tweak this.

Not that it'll be tweaked, of course. But it'd be nice to imagine that I could live in a world where we could have reasonable discussions about what should be in them.

Re: Testing is better than data structures and algorithms

#24

This will annoy a lot of folks, but: 1 - If you work on large scale software systems, especially infrastructure software of most types then you need to know and understand DSA and feel it in your bones . 2 - Most people work on crud apps or similar and don't really need to know this stuff. Many people in this camp don't realize that people working on 1 really do need to know this stuff. What someone says on this topi…

I already know the answer to this, but did you read the article? Ned addresses your concerns.

Re: Testing is better than data structures and algorithms

#25

When testing job candidates, sure, no doubt about that. For for learning, no, it's not. You should not spend as much time learning testing as you spend leaning data structures.

I feel like this mischaracterizes the blog. You seem to be taking this: > People should spend less time learning DSA, more time learning testing. And reading it as "More total time should be spent on learning testing than the total time spent learning DSA". That's one reading, another is that people are studying DSA too much, and testing too little. The ratio of total time can still be in favor of studying DSA more,…

That's a fair point. But then the author makes a blatant and unrealistic generalization about how much time people spend on each of those. Between CS undergrads and introduction to programming bootcamps, the variance on that number is extreme.

Re: Testing is better than data structures and algorithms

#26

This will annoy a lot of folks, but: 1 - If you work on large scale software systems, especially infrastructure software of most types then you need to know and understand DSA and feel it in your bones . 2 - Most people work on crud apps or similar and don't really need to know this stuff. Many people in this camp don't realize that people working on 1 really do need to know this stuff. What someone says on this topi…

> What someone says on this topic says more about what things they have worked on in their life than anything else.

This is the crux of the debate. If you work on CRUD apps, you basically need to know hash maps, and lists, but getting better at SQL and writing clean code is good. But there are many areas where writing the right code vs the wrong code really matters. I was writing something the other day where one small in loop operation was the difference betweeen a method running in miliseconds and minutes. Or choose the right data structure can simplify a feature into 1/10th the code and makes it run 100x better than the wrong one.

Re: Testing is better than data structures and algorithms

#27

This will annoy a lot of folks, but: 1 - If you work on large scale software systems, especially infrastructure software of most types then you need to know and understand DSA and feel it in your bones . 2 - Most people work on crud apps or similar and don't really need to know this stuff. Many people in this camp don't realize that people working on 1 really do need to know this stuff. What someone says on this topi…

This is so true. When you get DSA wrong, you end up needing insanely complex system designs to compensate -- and being great at Testing just can't keep up with the curse of dimensionality from having more moving parts.

Re: Testing is better than data structures and algorithms

#28

Sigh. Monochromatic myopia denying the need for holistic quality and mastery in multiple arenas and methodologies. Belts and suspenders, not just elastic waistbands.

Oh if the holistic myopia is multiples of monochromatic does it really need elastic mastery? Sigh.

Re: Testing is better than data structures and algorithms

#29
It really depends. Working on genome analysis, I once encountered/interrupted (by rebooting after a software update) a student who had been running an analysis for more than a week, because they had not pre-sorted the data. With pre-sorted data, it took a few minutes.

Not everyone works on web sites using well-optimized libraries; some people need to know about N and Nlog(N) vs N^2.

Re: Testing is better than data structures and algorithms

#30
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

> 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

Not if the user can, say, farm 1,000,000 different rows 100 times over an hour and a half while gossiping with their office mates. I over Excel as Exhibit A.

Post reply on HN