Category: bowling

Minimal syntax and access to meta-programming yields a close-to-the-metal language that we can shape to our liking.

I figure I'd better do at least a rudimentary frame display, to show more clearly what is happening and that it is as we wish.

We need to make the little marks that show up on the scoresheet, at which point I think our point will be made. Result: Point made!

The PinCount object isn't all that pleasing. Let's find a better way to deal with an unknown future.

The current frame works perfectly, except that it needs to know the future. That should be easy to fix: just know the future.

The knock on our bowling TDD demo is that the assumptions make it too easy. Therefore ... let's make those assumptions come true.

A casual remark at FGNO a few weeks ago turns my attention, once again, to bowling. Are you even serious?

I see yesterday's mistake. We complete the spike. Result: Works as expected. Not worth using.

In this session, I make some progress and then get stuck. Maybe worths kimming this, but no even good insights follow.

Today I'll try to make my new "holes" scheme work. Wish me luck.

I'm imagining a new way of scoring bowling. Recording the idea with intent to try it if it seems tasty upon reflection. Take this, "AI"!

Last night at FGNO we were reviewing a bowling exercise we had all tried. Today, I want to try something ... in Lua.

Object aficionados worldwide are concerned that the procedural bowling solution presented last time is just not robust enough. They want to see how we would make it score the frames incrementally. Frankly I haven't the slightest idea.

Here's the Bowling Game again. This time I'll take a simpler approach, along the lines I usually follow when I do a Test-Driven Development demonstration. The result is strikingly simpler than the preceding 'object-oriented' solution. What does this tell us about TDD and how to use it?

TDD on the Bowling Game (article lost and now found again)