Wow, I just read the original Sudoku post by Norvig yesterday for the first time, and now today this shows up here!
It was bound to happen to someone.
Reflections on Sudoku, or the Impossibility of Systematizing Thought
51–60 of 67 posts
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#52Isn't there a less-conceptual (but still conceptual) problem that correctness of software is commonly abrupt rather than continuous? You don't get a series of almost-right programs gradually approximating the right program, you have a correct program and variations on it may fail completely. Of course, whether this is literally true depends on what sort of algorithmic problem you're approaching. But there must be man…
Yes. The difference between "A program that does what you want" and "A program that crashes on startup" can be one character.
Ya but the real fun ones are the "a program does what you want 99.993% of the time"
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#53I'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 essent…
But Uncle Bob said that if I follow his TDD process by rote then my code will automatically attain good design! /s
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#54I'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 essent…
That’s pretty much just Feynman’s algorithm but with more steps:
1. Write down the problem.
2. Think real hard.
3. Write down the solution.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#55It's making the same reasoning mistake that a lot of discussion of the Entscheidungsproblem makes - the problem talks about a generic algorithm to answer for all programs P if they can solve T, for all tasks T, the discussion assumes that you can't decide if P solves T for any P or T. With that in mind, let's look at the crux of the argument: "If we can't decide if a program P solves a task T, then we certainly can't…
I won't argue with the idea whether you can test a particular program produces a result (we aren't so interested in programs that run forever in any case). Your observation of the origins of TDD makes sense in this regard: there may be domains where the TDD approach is more useful, but it's not a generic panacea, and assuming it is can lead to sadness.
My point was more about arbitrary programs and tasks. In general, I don't think there's any particular process you can follow that, in effect, reduces programming or math to a checklist. I'm sure there are techniques that can help structure many problems but they're necessarily fairly general e.g. "think about the problem, take a nap, think about it some more".
What I was hoping to highlight was more the danger of trying to hill-climb without having the right set of skills, thus assuming you can solve a problem by following a particular pattern.
To give an example, I remember trying to derive the quadratic equation when I was young, and no amount of algebraic repositioning was going to help me unless I know how to complete the square! But once that type of trick is in your toolbox, you can begin to solve all sorts of other problems.
Even the bowling calculator can become hard if you don't know what your doing, not because TDD is bad or a wrong way to do things, but because you don't know how to reason about your program. Even bowling has 12^13 outcomes, with a bunch of silly special cases if you approach it the wrong way. Thus a truly naive approach might lead you down a weird direction.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#56I'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 essent…
But Uncle Bob said that if I follow his TDD process by rote then my code will automatically attain good design! /s
My view of Uncle Bob is that his advise is attempt improve the average situation, even if taken literally as a gospell.
It’s better that everybody do route tdd, than no tests at all. It’s better to have all methods exactly 3 lines of code, than all methods being 3 pages long.
Uncle bob preaches better baseline, experience will teach all the nuance.
Disclaimer: I dont do tdd. But it’s nice method of work to know.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#57I'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 essent…
That’s pretty much just Feynman’s algorithm but with more steps: 1. Write down the problem. 2. Think real hard. 3. Write down the solution.
Understand the problem...
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#58> Wouldn't it be nice if you just had a general method you could apply to solve everything?
Would it? Why?
> But the reality is there's no single approach we can take.
> I know, I know, this is all so deeply... unsatisfying.
Why is it so unsatisfying?
This is the only thing that I disagree with the post, that this need to have a general approach to solving problems is necessary for solving problems to be satisfying. What is so disconcerting about a problem that seems to be unsolvable? Why do we need to solve everything immediately?
Maybe it's important not only to accept, but to embrace the fact that there is a sort of magic to the process of creativity that we can't capture in a bottle. But for that to happen we need to divorce ourselves from the necessity of productivity. This way we are more likely to be able to just sit with the problem without beating ourselves over not being able to solve it and without feeling like the problem owe us a resolution in return for our efforts.
It doesn't prevent anyone however from pursuing better tools and more general approaches to systematizing thought and problem solving. We can do both -- tackling a problem creatively or systematically -- as long as we feel like we are able to choose doing it. I think if we feel like we must find these general methods, they will likely elude us indefinitely.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#59Earlier quoted context omitted.
Yes. The difference between "A program that does what you want" and "A program that crashes on startup" can be one character.
Ya but the real fun ones are the "a program does what you want 99.993% of the time"
The annoying situation being that sometimes that 0.007% requires a major rearchitecture!
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#60Earlier quoted context omitted.
That’s pretty much just Feynman’s algorithm but with more steps: 1. Write down the problem. 2. Think real hard. 3. Write down the solution.
Understand the problem...
That is actually his step 1. Step 0 might be write down the problem as stated - but in his writing step 1 is really, "structure the problem." Of course you might have structured it wrong, that is in part where step 2 comes in.