5 ms·

Always gonna have to side with Peter Norvig on this one: https://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html https://pindancing.blogspot.com/2

Always gonna have to side with Peter Norvig on this one: https://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html 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 bunch of tests.” But then he never got anywhere. He had five different blog posts and in each one he wrote a little bit more and wrote lots of tests but he never got anything working because he didn’t know how to solve the problem. I actually knew—from AI—that, well, there’s this field of constraint propagation—I know how that works. There’s this field of recursive search—I know how that works. And I could see, right from the start, you put these two together, and you could solve this Sudoku thing. He didn’t know that so he was sort of blundering in the dark even though all his code “worked” because he had all these test cases.

IvyMike 1y ago
More context, from an earlier HN comment: https://news.ycombinator.com/item?id=3033446 https://news.ycombinator.com/item?id=3033446
pncnmnp 1y ago
I love what Norvig said. I can relate to it. As far as data structures are concerned, I think it's worth playing smart with your tests - focus on the "invariants" and ensure their integrity. A classic example of invariant I can think of is the min-heap - node N is less than or equal to the value of its children - the heap property. Five years from now, you might forget the operations and the nuanced design principles, but the invariants might stay well in your memory.
roxolotl 1y ago
This totally misses the point of the article. The article agrees that knowing when a problem is a data structure and algo problem is a key strength. The article also isn’t saying that all development should be done TDD. The point of the article is that knowing how to test well is more useful than memorizing solutions to algo problems. You can always look those up.
quotemstr 1y ago
> “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 development. No changes at all without tests first. It was a disaster, and a hilarious one at that. Ring a bell for anyone?
- moron4hire 1y ago
  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/ https://ronjeffries.com/articles/-z022/01121/sudoku-again/
  - quotemstr 1y ago
    Thanks!
    - fifilura 1y ago
      To be fair, I'd like to be forgiven for anything I did in 2006. It is a story that reads like a fairy tale, but it is time to give the guy a break.
      - moron4hire 1y ago
        That's why I linked to Jeffries' post where he gave more context. Though, in this particular case, he then went on to go back down the TDD Sudoku rabbit hole and, though he does seem to eventually write a program that works, the path to get there involved reading existing solutions and seems rather drain circly, which makes his post I linked seem a bit like making excuses. IDK. I don't really care beyond mild bemusement.
        1y ago
runeblaze 1y ago
That story reads like what happens when the average senior engineer tries to do a hardish usaco problem; turns out algorithm engineering is different from your average enterprise engineering; turns out there are people in both camps
MrJohz 1y ago
I think the point Norvig is making there broadly agrees with this post though. In the Sudoku affair, Norvig had the DSA knowledge there, sure, but his point is more that you need to be willing to look up other people's answers, rather than assuming you have enough knowledge or that you can slowly iterate towards a correct answer. You can't expect to solve every problem yourself with the right application of DSA/TDD/whatever. That's the same as the blog post: you need to know enough DSA to be able to understand how to look for the right solution if presented with a problem. But Batchelder's point is that, beyond that knowledge, learning testing as a skill will be more valuable to you than learning a whole bunch of individual DSA tricks.
casey2 1y ago
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.
EVa5I7bHFq9mnYK 1y ago
If you write all the tests, I'm sure the LLM can figure out the implementation.

IvyMike 1y ago

More context, from an earlier HN comment: https://news.ycombinator.com/item?id=3033446 https://news.ycombinator.com/item?id=3033446

pncnmnp 1y ago

I love what Norvig said. I can relate to it. As far as data structures are concerned, I think it's worth playing smart with your tests - focus on the "invariants" and ensure their integrity. A classic example of invariant I can think of is the min-heap - node N is less than or equal to the value of its children - the heap property. Five years from now, you might forget the operations and the nuanced design principles, but the invariants might stay well in your memory.

roxolotl 1y ago

This totally misses the point of the article. The article agrees that knowing when a problem is a data structure and algo problem is a key strength. The article also isn’t saying that all development should be done TDD. The point of the article is that knowing how to test well is more useful than memorizing solutions to algo problems. You can always look those up.

quotemstr 1y ago

> “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 development. No changes at all without tests first. It was a disaster, and a hilarious one at that. Ring a bell for anyone?

moron4hire 1y ago
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/ https://ronjeffries.com/articles/-z022/01121/sudoku-again/
- quotemstr 1y ago
  Thanks!
  - fifilura 1y ago
    To be fair, I'd like to be forgiven for anything I did in 2006. It is a story that reads like a fairy tale, but it is time to give the guy a break.
    - moron4hire 1y ago
      That's why I linked to Jeffries' post where he gave more context. Though, in this particular case, he then went on to go back down the TDD Sudoku rabbit hole and, though he does seem to eventually write a program that works, the path to get there involved reading existing solutions and seems rather drain circly, which makes his post I linked seem a bit like making excuses. IDK. I don't really care beyond mild bemusement.
      - 1y ago

runeblaze 1y ago

That story reads like what happens when the average senior engineer tries to do a hardish usaco problem; turns out algorithm engineering is different from your average enterprise engineering; turns out there are people in both camps

MrJohz 1y ago

I think the point Norvig is making there broadly agrees with this post though. In the Sudoku affair, Norvig had the DSA knowledge there, sure, but his point is more that you need to be willing to look up other people's answers, rather than assuming you have enough knowledge or that you can slowly iterate towards a correct answer. You can't expect to solve every problem yourself with the right application of DSA/TDD/whatever. That's the same as the blog post: you need to know enough DSA to be able to understand how to look for the right solution if presented with a problem. But Batchelder's point is that, beyond that knowledge, learning testing as a skill will be more valuable to you than learning a whole bunch of individual DSA tricks.

casey2 1y ago

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.

EVa5I7bHFq9mnYK 1y ago

If you write all the tests, I'm sure the LLM can figure out the implementation.