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

Reflections on Sudoku, or the Impossibility of Systematizing Thought

rjp.io

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#31

Post by jerf »

aleph_minus_one wrote: post #17
jerf wrote: post #16

Earlier quoted context omitted.

"Scrum" isn't really "Agile", though. Maybe someone developed it through a truly Agile process, but then they froze it and held it up as an unchanged ideal and started down the oh-so-appealing road of telling anyone that finds it doesn't work for them that it's because they weren't doing it right. I find myself having to distinguish between what I call "Real Agile" and Scrum quite a bit, because Scrum is exactly the…

> "Scrum" isn't really "Agile", though. Wikipedia: > https://en.wikipedia.org/wiki/Scrum_(software_development) "Scrum is an agile team collaboration framework commonly used in software development and other industries." In other words: people who claim to do Scrum, but in a non-agile way are simply scammers.

I am aware that Scrum essentially defines itself as "agile". However, the Agile Manifesto defines a very, very specific sort thing as "Agile", and is what I'm calling "real agile", and Scrum is not it.

Scrum could be it, if it presented itself as "here's a set of things to consider as tools you could deploy, but hey, do whatever works". But it doesn't. It is every bit as prescriptive as any of the methodologies that real Agile is a revolt against and can and does have all of the pathologies when it is applied in places where it doesn't make sense, or even just excessively rigidly. Scrum as it is practiced in the real world responds to "it's not working" with "do it more accurately, then!", not "oh, well, fix it up as you see fit". That's why so many of us here have such a visceral distaste of it. Many of us have enough experience and run-ins with "Scrum" to know that anyone trying to claim "Oh, but it 'really' wants you to be Agile and change it to work however you need to" is in practice just motte-and-bailey. That's not how it works in the wild.

You need to figure this out sooner or later or you're going to be deeply and repeatedly taken advantage of in life: Just because someone puts a label on something doesn't mean that label is accurate. Scrum isn't Agile and I don't care how many times someone grabs a label printer, prints out the word "Agile", and slaps it on Scrum. It's plainly obviously not an Agile methodology and never was.

Agile isn't a methodology; it's a meta-methodology, which is why it's so hard to productize.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#32

Post by mbb70 »

I'm reminded of Rich Hickey's Hammock Driven Development talk, whose thesis for design is basically:

1. Think about the problem and write it all down

2. Research what other people have done to solve this problem

3. Think about it some more and write all that down too

4. Sleep on it

I think the conclusion is the same: Good design does not naturally arise from good programming, and background/domain knowledge is essential

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#33

Post by dragonwriter »

jerf wrote: post #31
aleph_minus_one wrote: post #17

Earlier quoted context omitted.

> "Scrum" isn't really "Agile", though. Wikipedia: > https://en.wikipedia.org/wiki/Scrum_(software_development) "Scrum is an agile team collaboration framework commonly used in software development and other industries." In other words: people who claim to do Scrum, but in a non-agile way are simply scammers.

I am aware that Scrum essentially defines itself as "agile". However, the Agile Manifesto defines a very, very specific sort thing as "Agile", and is what I'm calling "real agile", and Scrum is not it. Scrum could be it, if it presented itself as "here's a set of things to consider as tools you could deploy, but hey, do whatever works". But it doesn't. It is every bit as prescriptive as any of the methodologies that…

> Agile isn't a methodology; it's a meta-methodology, which is why it's so hard to productize

More specifically, its a meta methodology that specifically rejects methodology as a one-size-fits-all, or even custom but top-down-imposable, product, but explicitly holds that methodology is an emergent product of continuous optimization within and specific to the team doing the work.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#34

Post by Symmetry »

Someone wrote: post #25
PaulHoule wrote: post #21

Earlier quoted context omitted.

The smart way to write a Suduoku solver these days is to formulate the problem for an SMT solver, which is specifically intended to solve that kind of problem. The SMT solver already has tests, so you don't need to write tests. When I wrote my first Sudoku solver I started out with a solver that solved easy problems where, at each step, there was some square with only one possible solution. That didn't work for harde…

> but it is faster if you start with the square that has the minimum number of choices available Alternatively, find the digit that, in its row/column/square/whatever, has the minimum number of choices available, and try each of them. Ideally, combine the two and use Knuth’s dancing links algorithm ( https://en.wikipedia.org/wiki/Dancing_Links ). It, at every step, picks the one of those two approaches that has the l…

In Sudoku I usually find it's easier to just keep track of guesses on the stack, by `solve` recursively when you make a guess. That leads to nice memory re-use characteristics and without the overhead of link pairs that might end up blowing out your level 1 data cache.

But you certainly want to be guessing on the most constrained spot you can.

Also, bitfields are a nice compact way of representing the possible values of a space and your cpu can and or or all the possible values in parallel, plus determine the number of possibilities with a modern CPU's popcount instruction.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#35

Post by 9rx »

jerf wrote: post #31
aleph_minus_one wrote: post #17

Earlier quoted context omitted.

> "Scrum" isn't really "Agile", though. Wikipedia: > https://en.wikipedia.org/wiki/Scrum_(software_development) "Scrum is an agile team collaboration framework commonly used in software development and other industries." In other words: people who claim to do Scrum, but in a non-agile way are simply scammers.

I am aware that Scrum essentially defines itself as "agile". However, the Agile Manifesto defines a very, very specific sort thing as "Agile", and is what I'm calling "real agile", and Scrum is not it. Scrum could be it, if it presented itself as "here's a set of things to consider as tools you could deploy, but hey, do whatever works". But it doesn't. It is every bit as prescriptive as any of the methodologies that…

> it's a meta-methodology

It is not even that. It is basically just a roundabout statement of "We believe software developers should be in control of the entire software development process". Or even more succinctly, "No managers". The Twelve Principles highlights the things developers need to consider when there isn't a manager around to do that work for them.

Scrum, while having little to do with Agile in and of itself, suggests that if you follow it, developers can start to learn how to operate on their own. This seems to be why it is commonly associated with Agile.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#36

Post by SideburnsOfDoom »

PaulHoule wrote: post #21
JonChesterfield wrote: post #15

This was an interesting read but the source article is fascinating https://explaining.software/archive/the-sudoku-affair/ TDD as an incremental search from a simple start point towards a solutions. Put in those terms, it'll work when the path from start to solution is smoothly differentiable.

The smart way to write a Suduoku solver these days is to formulate the problem for an SMT solver, which is specifically intended to solve that kind of problem. The SMT solver already has tests, so you don't need to write tests. When I wrote my first Sudoku solver I started out with a solver that solved easy problems where, at each step, there was some square with only one possible solution. That didn't work for harde…

I have only once written a Suduoku solver. It brute-forced the whole problem space in a second or 2.

This works because it's very easy to prune invalid branches according to the rules of the game.

It just tried putting "1" in the top-left most empty square and checking if the configuration is valid. If not, try "2". recurse until you find a branch that completes.

Is this the smart way? IDK, but I was quite pleased with it. I found it more elegant than e.g. "find some square with only one possible solution"

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#37

Post by reedlaw »

JonChesterfield wrote: post #15

This was an interesting read but the source article is fascinating https://explaining.software/archive/the-sudoku-affair/ TDD as an incremental search from a simple start point towards a solutions. Put in those terms, it'll work when the path from start to solution is smoothly differentiable.

I had a similar reaction to Jeffries' Gilded Rose solution in Ruby [1]. After 13 blog posts he ended up with something [2] a lot less elegant than Victor Shepelev who also used TDD but came up with a one-shot solution [3]. Just like Norvig with his Sudoku solver, Shepelev codifies the rules as a set of relationships. He writes:

  When rereading the requirements, we might notice that all conditions can be described as a simple dependency (name, sell_in) => change of quality.

  The most natural representation of this in the modern Ruby would be pattern matching.
1. https://ronjeffries.com/articles/020-01ff/gilded-rose-1/

2. https://github.com/RonJeffries/gold-1/blob/master/wrappers.r...

3. https://zverok.substack.com/i/149071314/the-implementation

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#38

Post by rjpower9000 »

JonChesterfield wrote: post #15

This was an interesting read but the source article is fascinating https://explaining.software/archive/the-sudoku-affair/ TDD as an incremental search from a simple start point towards a solutions. Put in those terms, it'll work when the path from start to solution is smoothly differentiable.

> incremental search from a simple start point towards a solutions

Good point. More broadly than just TDD, we might characterize an "easy" problem as one where the surface from conception to completion is broadly visible and there's a logical set of steps (i.e. "differentiable"). Or maybe "easy" is I can see the full set of steps immediately, and "tractable" is that I've got a good guess.

But the set of steps you can take is highly dependent on your knowledge and skillset. For example, if I know how about completing the square, then deriving the quadratic equation is a basic algebra exercise. If I don't, then I might struggle for a long time before I manage to discover that key insight.

I'm sure there are coding methodologies which can lead to better or worse results, but they augment knowledge or skill, they don't replace it.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#39

Post by prmph »

And this is exactly thinking AI is going to make human thought and skill redundant is crazy. LLMs can never get to a point where you whip them up to solve any general intellectual challenge. Even creating CRUD apps (that are well-behaved, secure, performant, scalable, and maintainable) can't really be totally systematized.

Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought

#40

Post by rjpower9000 »

IceDane wrote: post #13

Wow, the Ron Jeffries articles are sort of embarrassing, and he doesn't even realize. This why dogma never works.

I respect he's open about his work and struggles, and it's cool he's programming at 86, but it does seem like his approach makes it harder for him rather than easier.

For example with the bowling score calculator, it's great to start with some tests, but I think he then marched towards a specific OOP formulation which obscured rather than clarified the problem.

Post reply on HN