This sounds very similar to the challenge that companies had implementing Six Sigma (or other statistically-based quality programs). The tools significantly helped the average person improve the quality of their processes as determined by a variety of metrics. However, they were never going to tell you the solution or improvement to implement. They could give hints as to where to look for a solution, but someone still had to dream up the solution. For this reason, brain storming was always one of the most critical tools in the Six Sigma toolkit.
Reflections on Sudoku, or the Impossibility of Systematizing Thought
61–67 of 67 posts
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#62It'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,…
> reduces programming or math to a checklist
I mean, you can. "Have an initial idea. Define a utility function. Apply gradient descent".
It's just that all three steps are really really hard.
TDDs insight is that gradient descent is relatively easy if the utility function is one-dimensional and monotonic. (Bonus point, it still works with the set of initial ideas being empty)
The "tricks in your toolbox" are ultimately all about simplifying the utility function from "exhaustive mapping of problem domain to solution demain proves valid" to a simpler one. In your example, you mapped the problem domain from "solve order two polynomial" to "complete square, take square root, solve order one polynomial".
You _could_ apply these tricks mechanically (hey, that's what symbolic algebraic systems do in your example), but it would require an initial formal specification of the problem - that's ultimately what Norvig does for his Sudoku approach - and, for a general approach, a way to reason over formal specifications.
It always boils down to "how well do you understand the problem, and how well can you describe it formally". TDD works best for "not at all, not at all".
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#63Earlier quoted context omitted.
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.
every time i heard a talk or read something of his I always come out with the impression that he has no idea about anything. Most of what he says sounds like bullshit to me.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#64Earlier quoted context omitted.
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.
every time i heard a talk or read something of his I always come out with the impression that he has no idea about anything. Most of what he says sounds like bullshit to me.
His advice needs to be contextualized within the 90s and 00s. He was correcting (or overcorrecting) for issues that were prevalent then: methods that were hundreds or thousands of lines, processes with hundreds of hours of design work without writing a single line of code, no testing (or maybe handing to a QA to test, if you’re lucky), and tangled messes of logic the author thought could be saved by adding a comment.
Much of his advice seems silly or extreme now, but I believe that’s because he (and his cohort of likeminded programmers) won. Things have improved dramatically. The extreme advice worked. The problem, of course, is that you can’t just declare victory and move on. So now we have The Church of TDD and the like.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#65Earlier quoted context omitted.
every time i heard a talk or read something of his I always come out with the impression that he has no idea about anything. Most of what he says sounds like bullshit to me.
His advice needs to be contextualized within the 90s and 00s. He was correcting (or overcorrecting) for issues that were prevalent then: methods that were hundreds or thousands of lines, processes with hundreds of hours of design work without writing a single line of code, no testing (or maybe handing to a QA to test, if you’re lucky), and tangled messes of logic the author thought could be saved by adding a comment.…
It's silly and extreme and dogmatic because that's what he's like as a person. This is as much reflected in his political views - not just coding.
It might not be such a problem in other professions but good software development is heavily trade off oriented so dogmatism is especially dangerous.
It's a shame because TDD is pretty good but he puts people off it.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#66Earlier quoted context omitted.
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,…
> reduces programming or math to a checklist I mean, you can. "Have an initial idea. Define a utility function. Apply gradient descent". It's just that all three steps are really really hard. TDDs insight is that gradient descent is relatively easy if the utility function is one-dimensional and monotonic. (Bonus point, it still works with the set of initial ideas being empty) The "tricks in your toolbox" are ultimate…
> I mean, you can. "Have an initial idea. Define a utility function. Apply gradient descent".
> It's just that all three steps are really really hard.
Haha, I was hoping for something a little easier than that! I'm not sure gradient descent would apply for all problem spaces, but I get the gist of what you're saying.
> TDDs insight is that gradient descent is relatively easy if the utility function is one-dimensional and monotonic. (Bonus point, it still works with the set of initial ideas being empty)
That's sort of what I was driving at. I certainly won't argue you can't, with time and patience, at least exhaustively enumerate a solution space.
My impression of the TDD literature e.g. things like https://en.wikipedia.org/wiki/Transformation_Priority_Premis... is that they're pushing an idea that you can systematically walk through a set of transformations and get a program, that we can thus avoid the "really really hard" steps you mention.
This hill-climbing style matches closely with the monotonic utility function you mention. And if there are lots of interesting problems where this works for people, then that's great. I certainly won't object to having a system for approaching problems, and the general idea of trying to avoid adding complexity too early.
My original motivation was really just observing what appeared to happen when you apply these techniques _outside of their scope_. The failure mode becomes this sort of fascinating circling around a local minimum, with local changes that don't really make progress towards the ultimate goal. This is exactly what you'd see in an ML domain so it's kind of interesting to see it in the real-world.
Mea culpa: that was the part I found really interesting. I likely tried to stretch the point too broadly. Ultimately what I wanted to convey was there's no general way to avoid the hard part.
Re: Reflections on Sudoku, or the Impossibility of Systematizing Thought
#67Earlier quoted context omitted.
every time i heard a talk or read something of his I always come out with the impression that he has no idea about anything. Most of what he says sounds like bullshit to me.
His advice needs to be contextualized within the 90s and 00s. He was correcting (or overcorrecting) for issues that were prevalent then: methods that were hundreds or thousands of lines, processes with hundreds of hours of design work without writing a single line of code, no testing (or maybe handing to a QA to test, if you’re lucky), and tangled messes of logic the author thought could be saved by adding a comment.…
it is contextualized in around that time. That was the time I was actually learning to program. Didn't make sense then either. Doubling the line count (functions should contain a single statement) while also fragmenting it all around the place never did strike me as "better". His code was just straight up unreadable