* * * * *
These are the programmers I'm scared of …
> One thing at a time. Let's first write it out longhand:
>
> -----[ Ruby ]-----
> def square_indexes(square_number)
> result = []
> first_row = square_number / 3
> first_column = (square_number % 3) * 3
> first_row.upto(first_row+2) do
> | row |
> first_column.upto(first_column+2) do
> | col |
> cell_number = row * 9 + col
> result.push(cell_number)
> end
> end
> result
> end
> -----[ END OF LINE ]-----
>
> That's a lot of code, and I'm afraid it won't work. And it doesn't:
>
> -----[ data ]-----
> 1) Failure:
> test_square_four(TC_MyTest) [./sudokutest.rb:31]:
> <[39, 40, 41, 48, 49, 50, 57, 59, 59]> expected but was
> <[12, 13, 14, 21, 22, 23, 30, 31, 32]>.
> -----[ END OF LINE ]-----
>
> We see that it has started in row 1, not row 4 as it should have, but that
> it is taking the right corresponding cells after that incorrect start. So
> the row_number init is wrong.
>
> Now, this might have been a good time to just throw the code away and start
> over, which is a pretty good trick. If I had felt the need to debug, I'd
> have tried to start over instead, since that method was pretty weird. But I
> see exactly what the bug is—I think—so I'll just fix it. If it doesn't
> work, I'll start over.
>
“OK, Sudoku [1]”
This is the type of programmer [2] I was talking about yesterday—not only is
he unsure about 14 lines (and makes it out to sound like it's thousands of
lines) of a dynamic programming langauge (Ruby [3] in this case), but he's
not even clear he understands the bug in the code.
Also, the “crutch” this programmer uses is “unit testing,” which to me
(because the culture is totally alien to my way of thinking [4]), translates
to “let us write a ton of code to catch bugs that in a statically typed
language, the compiler would catch.”
Update a few minutes later …
I don't know if that programmer really thinks that way, is just playing a “I
don't know what I'm doing” type of programmer for the sake of demonstration,
or it's a serious case of “the culture is totally alien to my way of
thinking” but I'm finding his presentation of his programming methodology
extremely annoying.
> I choose to say “we'll need” here to emphasize that implementing those
> methods in yesterday's spike was a violation of YAGNI (You Ain't Gonna Need
> It), the rule that says not to implement things just because you need them.
>
“Moving On With Sudoku [5]”
I don't think YAGNI (You Aren't Gonna Need It) [6] doesn't mean “not to
implement things just because you need them.” But I could be wrong, as I
think Ron Jeffires [7] (who's writing these annoying articles) coined the
term. And even if he is right, he's giving excuses for not following his own
advice.
Alien cultures indeed.
And comments like:
> … I have to figure out which row number a cell is in, which column, and
> which square. Each of those is a bunch of integer divides and modular
> arithmetic, which I have a good chance of getting wrong …
>
> …
>
> Maybe it means I've thought too much about this, or that I'm following my
> anticipation too much.
>
> …
>
> Here we go. Hold on, that was a lot of code, ten or so lines … [But he's
> written about a bazillion lines of code implementing test cases, but I
> guess those don't count. —Editor]
>
“Moving On With Sudoku [8]”
Isn't helping my confidence with his coding skills any. Is it any wonder I
consider dynamic programming afficiandos as sloppy thinkers [9]? And the bit
about getting divides and modular arithmetic wrong? That's just … [DELETED-
wrong! You are not a programmer if you don't understand modular arithmatic-
DELETED] alien to my way of thinking.
Okay, I think I'll stop reading this now.
[1]
http://xprogramming.com/xpmag/OkSudoku
[2]
gopher://gopher.conman.org/0Phlog:2009/11/03.1
[3]
http://www.ruby-/
[4]
gopher://gopher.conman.org/0Phlog:2009/11/02.1
[5]
http://xprogramming.com/xpmag/Sudoku2
[6]
http://c2.com/cgi/wiki?YouArentGonnaNeedIt
[7]
http://c2.com/cgi/wiki?RonJeffries
[8]
http://xprogramming.com/xpmag/Sudoku2
[9]
gopher://gopher.conman.org/0Phlog:2006/06/05.1
Email author at
[email protected]
