Tuesday, October 20, 2020
Network Programming
Monday, October 19, 2020
fp-course
Following the Learn Haskell recommendation, the FP study group at Recurse Center worked through the fp-course exercises after finishing CIS 194.
https://github.com/bitemyapp/learnhaskell
The exercises seem to provide good practice, with modules like State and StateT requiring some mental gymnastics training..!
The repo unfortunately has some incomplete tests files, so I transcribed a few from the comments into HSpec format for Parser.hs and MoreParser.hs: https://github.com/tkuriyama/puzzles/tree/master/fp-course.
The test cases were tedious but turned out to be worthwhile, since JsonParser.hs is comprised of more abstract parser combinators. (Interestingly, the parser combinator in CIS 194 is almost identical to fp-course in its building blocks... a coincidence, or a common design pattern?).
Anagrams and Cheque remain to be completed, but we're moving on to writing a toy database in Haskell (with the goal to complete in the last two weeks of the Fall 1 batch!).
Monday, October 12, 2020
Dijkstra '74 on Scientific Thought
Some slides from a short talk at Recurse Center on Dijkstra's 1974 essay "On the role of scientific thought"
Sunday, October 11, 2020
Game of Risk Elm Visualization
Building on the previous post... an interactive(ish) Elm visualization of the game's probability trees:
https://tarokuriyama.com/projects/risk.php
Thursday, September 17, 2020
Game of Risk
The last assignment in the CIS194 Haskell class is to simulate dice-throwing battles in the game of Risk. The combat rules, taken from assignment specs, are:
- There is an attacking army (containing some number of units) and a defending army (containing some number of units).
- The attacking player may attack with up to three units at a time. However, they must always leave at least one unit behind. That is, if they only have three total units in their army they may only attack with two, and so on.
- The defending player may defend with up to two units (or only one if that is all they have).
- To determine the outcome of a single battle, the attacking and defending players each roll one six-sided die for every unit they have attacking or defending. So the attacking player rolls one, two, or three dice, and the defending player rolls one or two dice.
- The attacking player sorts their dice rolls in descending order. The defending player does the same.
- The dice are then matched up in pairs, starting with the highest roll of each player, then the second-highest.
- For each pair, if the attacking player’s roll is higher, then one of the defending player’s units die. If there is a tie, or the defending player’s roll is higher, then one of the attacking player’s units die.

Friday, September 11, 2020
Trying TCR
A fellow at the Recurse Center hosted a workshop on TCR (see Kent Beck's post for an introduction to the idea), using these templates.
The short of it is: a watcher will automatically run tests upon file save; if any tests fail, it will revert to the prior commit; else, it will make a new commit.
Despite some initial mental (and practical workflow) resistance, I've warmed very rapidly to the idea.
By far the biggest change is the revert part of test && commit || revert. Some initial complaints:
- I made a typo, and it revert to the last commit
- I just lost a whole block of code
- I can't just try this simple thing because it keeps failing a test and getting deleted
- slow down
- write fragments that you understand
- write smaller fragments if necessary
- Instead of inotifywait, on macOS fswatch can be installed from Homebrew (brew install fswatch)
- fswatch should be called with the --one-event flag, since it's already called in an infinite loop (otherwise it blocks the next line)
- By default, TCR will auto-commit with the same message; as one possible alternative, call AppleScript and ask for a commit message via a prompt

- The default example has some assertions in the main Python file; modify this to call a testing framework instead (in my case, py.test)
Friday, August 28, 2020
Sudoku Visualization
The Sudoku solver visualization in Elm is done!
https://tarokuriyama.com/projects/sudoku.php
Writing Elm feels similar to writing Haskell, with a bit of syntax that's more like F# (e.g. the pipeline operators <| and |>). Between the familiar format of Learn You and Elm and the examples in Beginning Elm, it's relatively easy to pick up given a bit of functional programming background.
All of the code for the solver and visualization is on GitHub.
