After three months as a student apprentice at 8th Light, I’m starting over, now as a resident. And this is not something trivial. I moved from another city to Chicago because of the apprenticeship, and of course I really wanted to continue in the program as a resident. I couldn’t be happier with the project that I developed as a student and with the project that I started working on.
If the thread macros that I wrote about on the previous post are a nice way to make nested forms easier to read, destructuring is a technique that makes code easier to read by making binding a more intuitive process.
The thread macros in Clojure are an excellent way to make things clearer and easier to read, but it can be hard to understand what they do and when to use them.
One of the requirements of the Tic Tac Toe was that the user should be able to quit a game. Simple, right? The detail was that it should not only quit the game, but also clear the terminal screen.
After adding an easy computer and an unbeatable computer to the Tic Tac Toe game, it was difficult to think was a medium computer would be like, how it would behave, what kind of moves it would make.
One of the most interesting things that can happen while working on a project is dealing with the unknown. So, everybody knows how to play a Tic Tac Toe and knows how it works. But, what if we play with symbols other than x and o? What if we can give the option to save the game? What if we play with a 5x5 board?
Just like the minimax, I thought that adding colors to the output of my Tic Tac Toe would be easy. And just like the minimax, it was a lot more difficult than I thought it would be.
One of the multimethods that I use on the Tic Tac Toe project is related to how players select a spot on the board. The hardest thing to do while implementing the methods was, actually, dealing with dependencies.
It’s been almost two months since I started learning Clojure and I think I’m finally letting it go my problem with the documentation — that is, for me, one of the most complicated things about the language.
One of the requirements of the Tic Tac Toe project was that the screen should be cleared after getting an input from the user. Everything on screen should disappear, except the representation of the current state of the board. The problem was that my tests started to disappear as well.
Physical exercises can reduce stress, ease anxiety and depression, and boost self-esteem. Programming exercises can do the same.
The minimax algorithm assumes that both players make the best possible move they can. What if one of the players makes only incredibly bad moves?
While debugging the minimax implementation, I decided to create a record named Game, so the analysis of the board could be done accordingly to the type of a game: if it is human vs unbeatable computer, human vs human, and so on. In total, 6 types of games, and 10 conditionals, depending on the role of the two players.
It finally came the day when I was asked to implement an unbeatable player in the Tic Tac Toe project. I had (horribly) done it before in Ruby, so I thought it would be reasonably easy: I knew the algorithm already and I thought I had a good grasp of how recursion works in Clojure. What could go wrong? Everything.
How easy would it be to use a multimethod that could handle multiple arguments? And what is the point of having such methods? Wouldn’t they add complexity to the problem? I deferred answering those questions as much as I could while developing the Tic Tac Toe.
While building my Tic Tac Toe, I came across a situation like the following:
After a week using Clojure, I think I finally started to get used to reading it. Maybe because I’m not a native English speaker or because I am used to Ruby, I’ve been having a hard time with some conventions.
As soon as I started working as a reporter some years ago, I heard about a guy who used to work at the same newspaper. He was famous for the things he wouldn’t do.