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

141–150 of 178 posts

Re: Testing is better than data structures and algorithms

#141

Post by MrJohz »

hvb2 wrote: post #14
cogman10 wrote: post #9

Earlier quoted context omitted.

That wasn't the thrust of the article. The article is saying that it's more important to write tests than it is to learn how to write data structures. It specifically says you should learn which data structures you should use, but don't focus on knowing how to implement all them. It calls out, specifically, that you should know that `sort` exists but you really don't need to know how to implement quicksort vs selecti…

No, it says learn data structures first, then focus on testing. You don't have to go super deep on all the sort algorithms, sure. That's like saying that learning testing implies writing a mocking library

I think the issue is that most DSA curriculums do go super deep on things like sort algorithms or linked lists or whatever else. Whereas testing is usually barely taught in universities or colleges, and when it is taught, it's usually very lightweight.

Re: Testing is better than data structures and algorithms

#142

Post by pezgrande »

Arun2009 wrote: post #129

I have always thought of DSA as a proxy for a subset of general software development skills: the ability to translate a problem into computer science or programming terms, implement it in code, and argue that the implementation is correct and efficient. Skill in solving DSA problems can signal both an aptitude for absorbing computer science knowledge in general and a capacity for solving problems through programming.…

Maybe in some companies. At "Enterprise" level your control-alt-f skills are more valuable (for your average IC) based on my experience.

Re: Testing is better than data structures and algorithms

#143

Post by mekoka »

Many programmers think that the way DS&A work is that one beautiful spring morning, some requirements fall onto your lap where the words "nodes" and "edges" are neatly circled, thus marking a key moment in your life where you can finally put to use that old dusty algorithm book. Meanwhile, trees and graphs have been flying up to your face, slapping you left and right, every single day of your career and you kept repeating to yourself "see, you don't need all that DS&A stuff".

I think the article is unnecessarily trying to contrast two orthogonal and separately useful software development concerns. DS&A are about having the most efficient tools for the specific job. Testing is about ensuring that results match expectations. But I'd be surprised by anyone who only learns DS&A in theory and also naturally develops the related, but subtler skill of recognizing classes of problems that match up to particular algorithms. It's an almost tacit skill, which many programmers don't have despite knowing some of the classic DS&A, because it requires to linger a bit longer in the material. And that's the real gap leetcode type challenges try to bridge. The more you do them, the more you reinforce an intuitive understanding of involved structures and techniques, including some of the subtler properties and oft undocumented corner cases. What looks like "memorization" to some is actually more of an almost indelible grokking, which you carry with you in professional programming.

Admittedly, people who only do leetcode type challenges and never write software in the real world don't know which parts of these challenges are useless (in my opinion, the puzzles and lateral thinking parts). But people who never do these challenges also know squat about how useful they can be at honing one's "real life" problem solving and coding skills.

Re: Testing is better than data structures and algorithms

#144

Post by moron4hire »

quotemstr wrote: post #104
IvyMike wrote: post #66

Always gonna have to side with Peter Norvig on this one: https://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-... > They said, “Look at the contrast—here’s Norvig’s Sudoku thing and then there’s this other guy, whose name I’ve forgotten, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bun…

> “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bunch of tests.” But then he never got anywhere There's a blog post I read once and that I've since been unable to locate anywhere, even with AI deep research. It was a blow-by-blow record of an attempt to build a simple game --- checkers, maybe? I can't recall --- using pure and dogmatic test driven developmen…

Norvig mentions it in the article linked in the post to which you are replying. The game was Sudoku. The person was Ron Jeffries. https://ronjeffries.com/articles/-z022/01121/sudoku-again/

Re: Testing is better than data structures and algorithms

#145

Post by JoeAltmaier »

yakshaving_jgt wrote: post #132
JoeAltmaier wrote: post #90

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

As effective as that sounds, having that integrated test suite didn’t preclude you from also having more granular isolated tests.

Sure, in a generous world with lots of resources. Given the startup environment and the overworked team, it's a choice how to spend limited time and energy.

Re: Testing is better than data structures and algorithms

#146

Post by JoeAltmaier »

rossant wrote: post #127
JoeAltmaier wrote: post #90

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

How much work was it to go from 1 hour to 1 week? How many issues have you discovered, what were they? Genuinely interested.

It took a big fraction of our energy to get to each new stage. Always it was something new and unexpected. It was quite a while ago, but lets see what I remember.

Some good fraction were mismatches between the app (bot) state and the server state. A bot would be expecting a message and stall. The server thought it had said enough.

The app side used a lot of libraries, which it turns out are never as robust as advertised. They leak, race, are very particular about call order. Have no sense of humor if they're still connecting and a disconnect call is made, for instance.

The open source server components were fragile. In one instance, the database consistency library had an update where, for performance, a success message was returned before the operation upstream was complete. Which broke, utterly, the consistency promise that was the entire point of using that product.

A popular message library created a timer on each instantiation. Cancelled it, but in typical Java fashion didn't unlink it. So, leak. Tiny, but you do it enough times, even the biggest server instance runs out of memory.

We ran bots on Windows, Linux, even a Mac. Their network libraries had wildly different socket support. We'd run out of sockets! They got garbage collected after a time, but the timer could be enormous (minutes).

Our server used a message-distribution component to 'shard' messages. It had a hard limit on message dispatching per second. I had to aggregate the client app messages (we used UDP and a proprietary signaling protocol) to drop the message rate (ethernet packet rate) by an order of magnitude. Added a millisecond of latency, which was actually important and another problem.

Add the usual Java null pointers, order-dependent service termination rules (never documented), object lifetime surprises. It went on and on.

Each doubling of survival-time the issues got more arcane and more interesting. Sometimes took a new tool or technique to ferret out the problem.

To be honest, I was in hog heaven. Kept my brain plastic for a long time.

Re: Testing is better than data structures and algorithms

#147

Post by specialist »

mekoka wrote: post #143

Many programmers think that the way DS&A work is that one beautiful spring morning, some requirements fall onto your lap where the words "nodes" and "edges" are neatly circled, thus marking a key moment in your life where you can finally put to use that old dusty algorithm book. Meanwhile, trees and graphs have been flying up to your face, slapping you left and right, every single day of your career and you kept repe…

> ...unnecessarily trying to contrast two orthogonal and separately useful software development concerns.

> ...only do leetcode type challenges and never write software in the real world...

Respectfully, I agree with OC's point about testing vs implementation. (Both are programming.) It's been a (long) while since I've had peers who regularly, usefully tested their own work.

Like this OC, I too have struggled to articulate why leetcode has tiny IRL relevance.

How's this:

A useful distinction may be implementation vs usage.

Of course, a tiny handful of people are entrusted with implementing libraries of algorithms, so should be properly vetted for that work. Ditto crypto, parsing, and other misc arcane arts.

OC's point remains that leetcode hazing ignores the majority of actual work as a programmer. Such as fixing bugs, testing, modeling, documenting, enduring meetings, etc.

--

IIRC, I haven't implemented a sort algorithm, either in anger or for fun, since my BASIC & Pascal days. Why would I?

But I have recast real world problems as a Traveling Sales Person problems a handful of times.

As you well know, modeling using well known data structures, to enable using stock algorithms, is a big part of the job.

I'd rather interviews verified applicable skills. Such as data modeling, sequence diagrams, etc. And maybe some lightweight arch like (from the hip) caching, serialization, indexing, queuing and backpressure, locks, and validation (and whatever other bog standard stuff is immediately relevant).

--

(Oops: I did recently implement topo sort, just to understand it better, even though I was using a ready-baked solution. Just like +25 years ago I implemented (poorly) taboo, simulated annealing, etc. during my brief optimization kick.)

Re: Testing is better than data structures and algorithms

#148

Post by jiggawatts »

hxtk wrote: post #96
JackSlateur wrote: post #59

Earlier quoted context omitted.

Testing concurrency is extremely hard For instance, get sql queries; You ran them, and you have no issue; Is your code sane ? Or is it because one query ran 10ms earlier and, thus, you avoided the issue ? I truly wonder if there is real world tests around this; I bet there is only algorithm and fuzzing;

I’ve long wished for an SQL error model: given a schema, query, and transaction isolation mode, what errors are theoretically possible? I have a hard time answering this for Postgres, which disappoints me because I don’t see any reason it sounds very easy to answer, like there could be an extension to EXPLAIN that would dry run the query and list all the error states reachable.

Computer Science is incredibly immature. Many of its "founding fathers" are still alive!

Something akin to this that blew my mind recently was an IDE for a functional language that used typed holes, the programming equivalent of a semiconductor electron "vacancy", a quasi-particle with real properties that is actually just the lack of a particle. The concept was that if you delete (or haven't yet typed) some small segment out of an otherwise well-typed program, the compiler can figure out the type that the missing part must have. This can be used for rapid development because many such "holes" can only have one possible type.

This kind of mechanistic development with tool assistance is woefully under-developed.

Re: Testing is better than data structures and algorithms

#149

Post by casey2 »

IvyMike wrote: post #66

Always gonna have to side with Peter Norvig on this one: https://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-... > They said, “Look at the contrast—here’s Norvig’s Sudoku thing and then there’s this other guy, whose name I’ve forgotten, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bun…

To be fair to the other guy a Sudoku solver easier to bang out than a tiny distributed operating system environment that happens to solve sudoku, even if your language does help you.

Re: Testing is better than data structures and algorithms

#150

Post by pfdietz »

fuzztester wrote: post #121
pfdietz wrote: post #112

Earlier quoted context omitted.

As I recall this was a book that included the orthodoxy at the time that random testing was the worst kind of testing, to be avoided if possible. That turned out to be bullshit. Today, with computers many orders of magnitude faster, using randomly generated tests is a very cost effective away of testing, compared to carefully handcrafted tests. Use extremely cheap machine cycles to save increasingly expensive human t…

Interesting. Don't remember that from the book, but then, I read it long ago. I agree that random testing can be useful. For example, one kind of fuzzing is using tons of randomly generated test data against a program to try to find unexpected bugs. But I think both kinds have their place. Also, I think the author might have mean that random testing is bad when used with a small amount of test data, in which case I'd…

I'd say in any sufficiently complex program, random testing is not only useful, it's essential, in that it will quickly find bugs no other approach would.

Even better, it subsumes many other testing paradigms. For example, there was all sorts of talk about things like "pairwise testing": be sure to test all pairwise combinations of features. Well, randomly generated tests will do that automatically.

I view random testing as another example of the Bitter Lesson, that raw compute dominates manually curated knowledge.

Post reply on HN