The game of Risk for children

We had family game night last night, and my 4yo son wanted to play Risk. He likes the little army men, and before we had just played with the army men on the board, but I decided to invent a simplified game for him to play. I just made it up as we went along, but I was pleased with how it turned out.

Each person takes a turn drawing a card from the pile. If a person draws a wild card, then they can place their army on any empty country, or if there are no empty countries, they can pick any inhabited country and do "battle." During a battle each player rolls one die, and the player with the highest number wins (in the case of a tie you roll again). The winner either keeps the country, or kicks out whomever was inhabiting the country.

When a player picks a country card, if the country on the card is empty, then they place an army on the country. If the country is not empty they do battle.

Each player keeps the cards they draw, and during their turn if they have three of a kind, then they get to place an extra army on any empty country they choose, or if there are no empty countries, then they can choose an inhabited country and do battle.

The game ends when the pile of cards is exhausted, and there is an army on every country. My thought was that at the end we would count up the number of countries that each player had, and the one with the most would win. We didn't get to do that last night, though, because my son wanted to drive a cannon through all the countries on the board making all the armies fly everywhere (who can blame him!).

I don't think there is any strategy to this game. You are basically subject to the randomness of the cards you draw, and to the dice in the case of battle. You could assign extra points for holding an entire continent at the end of the game, but I'm not sure there are enough opportunities to choose on which country you'd like to place an army.

So there may be room for improvement, however, it was surprisingly entertaining, and it kept the attention of my son. :)

The Flerb Paradox

Chas Emerick has ranted against Emacs conducted a survey of Clojure usage. That's right, in the middle of a friggin survey of Clojure usage he took the time to bash Emacs, and I'm kinda fed up with Chas' Emacs hate. I'm a heavy Emacs user, and I think its the bees knees, and I would like to correct some errors in Chas' article.

Fact #1: Learning Emacs is not necessary for learning Clojure

No one has ever said it is. It's a flat-out false statement. Chas does not use Emacs to write Clojure. Neither do 30% of Clojure users according to his survey results, and when you look at the comments on Brian Carper's article, you see many people saying they gave up trying to learn Emacs, and went with another editor.

Fact #2: No one is pushing Emacs

The clojure.org homepage does not say it is a syntax error to write Clojure code in an editor other than Emacs. In fact, I remember a time when I almost unsubscribed from the Clojure mailing list because there was so much talk about VimClojure (not that I hate vim, it was just noise to me). Contrary to Chas' belief, people are not running around thumping their Emacs. Chas probably just sees Emacs mentioned with Clojure in blogs and tweets and IRC and gets the impression that people are being bigots, but as revealed by his survey there is a simple explanation for this: 70% of us are using Emacs. In fact, if anyone is obsessed with Emacs its Chas, he seems incapable of talking about Clojure IDEs (or perhaps just Clojure) without ranting against Emacs.

Fact #3: There are alternatives

Frankly, if I was the developer of Counterclockwise, Enclojure, La Clojure, or VimClojure (that's right four other, non-Emacs editing environments for Clojure!), I would probably be hurt my Chas' comments. He looks at Emacs, which he finds too difficult to be worth his time, and concludes that there is no decent editing environment for Clojure. He even goes so far as to offer to pay someone to develop a green-field environment for him.

Fact #4: People hate Clojure's syntax more than any particular editor

Clojure's Lisp syntax and abundance of parenthesis is mentioned as a weakness/blind spot in the survey results just as many times, if not more, than IDE complaints. Many people think syntax is scaring off newbies more often than not. I think that is a natural reaction. I too was put off by the parenthesis at first, but once Lisp clicks for you, you realize that the parenthesis are necessary for its power. Someone who puts off learning Clojure because its syntax looks weird and different is missing out on the power that is enabled by that "weirdness." You have to be willing to try something different, completely different, and go through some pain to gain this incredible power.

The Flerb Paradox

That leads me to my last point. I'm not sure how to say this without it coming across as me being a jerk. Let me just say that I'm not out to attack Chas or anyone else personally. I don't think Chas is an idot. I don't hate him. I just wish he'd stop riding his anti-Emacs hobby horse. However, what I'm about to say is controversial: editing environments vary in their productivity enhancement. This is a corollary to the Blub Paradox that I call the Flerb Paradox.

Editing environments lie along a continuum of productivity enhancement from a plain text editor on up. The Flerb editing environment is a fictional environment that is somewhere in the middle of the continuum. A user of the Flerb editing environment looks down one end of the continuum at Notepad and balks at its lack of feature x (syntax highlighting, code completion, etc.). He knows he is looking down the continuum and his editor makes him more productive than those below it. Otherwise, why wouldn't he just use notepad?

However, when he looks up the power continuum at Emacs he doesn't realize he's looking up the continuum. He only sees something strange and confusing. He doesn't understand why anyone would want to use something like Emacs, because Emacs can do everything Flerb can do, but it has all this hairy stuff thrown in for no reason. It has different key bindings and Meta keys and buffers! It seems to be designed to confuse its users. This is the Flerb paradox.

Now, am I saying that Emacs is the best editor that could possibly be invented? No. What I'm saying is that it's the most productive editor that is available. There's still room for other editing environments. Perhaps one of them will turn out to be more productive than Emacs. There are plenty of people out there who would rather use something other than Emacs, and I'm fine with that. I think they won't be as productive as possible, but that's their choice.

Learning Emacs was tough. It was painful. And just like most tough things in life, it was worth it. But this is coming from someone who switched to the Dvorak keyboard layout, and taught himself to use the mouse with his left hand. I like to do things for the challenge, because it keeps me sharp. I fear the day I become dull and complacent.

So, while I said Clojure developers aren't Emacs bigots, I've turned into one, and it's Chas' fault :-), just like superheros create supervillians that create superheros. If Chas hadn't railed against Emacs so much I wouldn't have turned into the supervillian I am today. >;-)

Hiring a Rails Lead

My company (Sonian) is hiring a Rails Lead position. This is a remote, work-from-home, position, and it's an awesome situation...I love it! It is a team of excellent developers that are fun to work with.

Preferably an applicant:

• has been a team lead before
• has worked on a distributed team before
• has worked in a pair programming environment before

This is a full-time position for US based individuals only at a well funded startup that develops and sells an e-mail archiving solution with several paying customers. In addition to Rails, we're using modern tech like Git, Chef, Amazon AWS, Clojure, and distributed file systems. We're indexing terabytes of data for searching. It's a cool and serious application!

If you are interested in applying, please send a resume to jobs@sonian.com. If you have any other specific questions about Sonian or the position, feel free to contact me at paul@stadig.name or call me at 703-634-9339.

Eva Cassidy

I'm probably late to the game with this one, since most of her recordings date from the late 1990's, and her album skyrocketed to number 1 in England around 2000, but I have just discovered an amazing musician.

Eva Cassidy grew up just outside Washington DC in Bowie, MD. She struggled with being extremely shy, and didn't like to be in the spotlight. She sang as a background singer for other musicians, and occasionally played at Blues Alley in DC. She recorded demos that she sent to labels, but her talents were too wide ranging. Record labels had a hard time imagining how to sell an artist that excelled a jazz, folk, pop/rock, R&B, and gospel.

In 1996, after some success collaborating with Chuck Brown on "The Other Side" and releasing a live album from some gigs she did at Blues Alley, she moved to Annapolis, MD and took a job painting murals at elementary schools. The summer of 1996 she was experiencing hip pain that she assumed was from using the stepladder at work. X-rays revealed she had cancer throughout her body. A few short months later, at the age of 33, she died.

Eva had a beautiful, clear voice, and for being extremely shy and afraid of the spotlight, she poured herself and her passion into her performances. Just search YouTube for videos, watch them, and you'll see what an amazing talent she had.

Her fame and success has come posthumously. When a DJ in England played her song on the radio, her album became a smash hit, and more and more people have been discovering her music. Perhaps part of the attention her music has gotten is because of her tragic story, but I believe her music stands on its own, and I'm glad to have discovered it.

The Great Chef: A Parable

There was once a boy who loved food. He would sit for hours and read anything that had to do with food and cooking, including the instruction manuals for the kitchen appliances. The boy began to cook by trying out simple recipes. He would make the same recipes over and over and over, until he understood how each part contributed to the whole. His father noticed the boy's near obsession with cooking, and arranged for the boy to apprentice a chef.

Though the chef was not particularly masterful, he was a good chef. The boy was enthralled. He studied every minute detail of the kitchen, every movement of the chef. He studied the way the chef assigned tasks to the others that worked in the kitchen. He studied the way the chef chose his ingredients, and prepared his recipes. The boy became familiar with every tool at the chef's disposal, and eagerly did every job assigned to him, from chopping vegetables to mopping the floor.

Eventually, the boy became a man and he decided to enter cooking school. The first few years were boring drudgery to him, and he learned almost nothing. He had already experienced the inner workings of a disciplined kitchen, and he had continued to be a voracious reader of anything to do with food and cooking. However, in the later years of cooking school a new world was opened to him. He learned cooking techniques only few in the world understood. He learned the potent and exotic flavor of each spice. He learned the magic and the music of cooking.

Delicate dishes were like a symphony, each part had its purpose, and when everything came together the person eating it shared in some great truth, it was almost...mystical. The man had such a profound and heartfelt appreciation for food and cooking, that he found he couldn't even explain it to anyone else. In fact, the only people he could explain it to were others who had the same deep appreciation for food and cooking.

The man excelled at cooking school. His instructors and professors loved him because he was a passionate student. He eventually felt as though his professors were his peers, instead of his teachers. He even taught them a few things as he experimented with creating some truly unique recipes.

Finally, the man graduated from cooking school with the highest honors that could be achieved. He had become a master craftsman, an artisan. He had become The Great Chef. He struck out on his own to start a restaurant. His restaurant soon gained acclaim as everyone recognized his genius. Reservations had to be made over a year in advance.

The Great Chef decided that he would try something that would tax his skills to the breaking point. He had always toyed with the idea of creating this one dish that everyone said was impossible to create. He set his mind to it. If he cooked the tomatoes just so it would bring out the flavor he desired, and that would combine perfectly with the mushrooms. The combination of spices would perfectly complement the other ingredients. He sought out only the freshest meats and vegetables that were at the peak of ripeness, and at great expense.

All of The Great Chef's life's preparation had led up to this moment. By following his finely tuned intuition, he had created a recipe where no single ingredient could be removed without causing the flavor of the whole dish to collapse, because each ingredient depended on the others to draw out and complement its flavors. He only had to make the recipe once to know that it was perfect. He had done the impossible! He had proven beyond any doubt that he had no equal, and in the process he had created a new branch of the culinary arts.

One day, a man came to have dinner at The Great Chef's restaurant. He wasn't a connoisseur but he liked to try strange new things, and when someone told him The Great Chef's new dish was the best, he had to have it. He had made a reservation a year ago, and had come in from out-of-town expressly for this purpose. When it came time to order, the man said he would like to try the new dish, but as he read the description he said, "Oh...I don't like tomatoes. Can you make it without the tomatoes?"

The Programming of Philosophy

Just recently I watched Rich Hickey's presentation from the JVM Languages Summit 2009. It is a very interesting and thought provoking presentation, and well worth viewing. In it he takes from philosophy an understanding of time, state, and identity and applies it to the design of computer programming languages and models for concurrency.

Rich's presentation is also a further proof that no science (to include computer science) is philosophically or religiously neutral¹. Computer science in particular is one of the more "philosophical" sciences. We model and reason about information in its purest and most elemental forms. We learn De Morgan's laws in CS classes for goodness sake!

The connection between philosophy, religion, and computer science is illustrated best in the field of artificial intelligence, where we must answer questions like:

• What is intelligence?
• Are human brains nothing more than biochemical computers?
• Can an electronic computer model intelligence accurately?

I find it telling, that most AI researchers today punt on these issues. They have moved away from trying to define and model some theory of general intelligence, and moved towards statistical techniques, and creating agents that "act rationally" by imitating human behavior. However, even taking a pragmatic approach² there is still a philosophical underpinning. For instance, take Jeff Hawkins work at Numenta, which I have written about previously, clearly there are influences of Empiricism.

We each have our own worldview, and our worldview not only influences the way we model the world, but it also limits our model of the world. Programmers are fond of talking about how the programming language you use limits the way you think about solving a problem³. We encourage each other to learn multiple languages especially from different paradigms (declarative, functional, object oriented, imperative, etc.) to gain new ways of solving problems. We have arguments about which languages model the world better. Is action (functional languages) primary or is existence/state (object oriented) primary? In other words which came first God existing, or God creating? You could even liken the debate about static versus dynamic typing to a debate about absolute versus relative morality. Can we possibly come up with a system of rules beforehand that are applied in every situation, or is that too rigid? ... OK maybe that last analogy is pushing it a bit... :)

I like what Rich has done. He acknowledges that his philosophy of state and time has come from Alfred Whitehead. Perhaps there are more lessons that can be learned from philosophy and applied to computer science. Or perhaps if we are explicit about our philosophical underpinnings and follow them to their logical conclusions we will gain some useful insights.

Footnotes:

¹ This will most assuredly set some people afire, but I do not see a distinction between philosophy and religion. They both answer questions we have about the nature of the universe, the limits and proper use of reasoning, etc.

² Pragmatism is a branch of philosophy, by the way.

³ Again from philosophy! See "Wittgenstein philosophy of language"

Simplicity and Complexity in Software

Avdi Grimm wrote "Simplicity is Complicated" where he argues that simplicity isn't simple. It brought to mind a few pet peeves of my own.

I think I agree with what Avdi has to say, but I might couch it in different language and come at it from the complexity side of the issue. I also have some opinions on simplicity in programs, which basically boil down to readability.

I like to think of complexity as being of two kinds: essential, and accidental. Accidental complexity is complexity that is introduced by the way in which you solve the problem. It is complexity that is unnecessary, and that could be removed by solving the problem in a more elegant fashion. Essential complexity, however, is complexity that is inherent to the problem, and cannot be reduced no matter how you solve the problem.

I had this conversation with a coworker recently. We were working on several reports for a Rails application. We were discussing whether it would be better to have a single controller with sixteen actions, or sixteen controllers with one action each. This is an example of essential complexity. If you have sixteen reports, then you are going to have sixteen "somethings," there is just no way around it. This is like Avdi's example of a pocket of air trapped under plastic, if you squeeze on the actions, then sixteen controllers will pop up somewhere else.

Then when it comes to simplicity in programs, my view is to reduce the accidental complexity as much as possible, and also to stick to the conventions and idioms of your language as much as possible. Obviously, there would be no innovation if we only stuck to conventions, but as much as possible, a Ruby programmer should be able to read and quickly understand a Ruby program. Consider these two examples from Avdi's article:

Example 1

sum = 0
i = 0
while i < times.length
  time = times[i]
  # parse / manipulate the time
  sum = sum + time
  i = i + 1
end

Example 2

def average_time_of_day(times)
  sum = times.map(&:to_time).inject(&:+)
end

I don't think that Avdi is necessarily arguing for this viewpoint, but he says that "[Example 1] uses language constructs that are familiar to almost all programmers, not just Ruby programmers," and that this can be considered a form of simplicity. While it's true that one might see that as a form of simplicity, I think the most important thing when writing a Ruby program should be writing it in a way that it is easy for Ruby programmers to understand.

When a Ruby programmer sees Example 1, he has to stop and think about what is going on, because it is not idiomatic Ruby. When he sees Example 2, he can immediately grasp the essence of what the code is doing. This is more an issue of readability than simplicity.

I'm not saying that the Ruby programmer grasps it easier because it is more terse. A Java programmer would look at Example 2 and perhaps be a bit befuddled. What I'm saying is that a Ruby programmer grasps it easily because it is idiomatic Ruby. I do not think it would be appropriate to write something like Example 2 in Java.

I would not advocate writing Java code with Ruby (like Example 1), nor would I advocate writing Ruby code with Java. Stick to the idioms and conventions of the language you are working within. And to those who say, "Well some Ruby programmers wouldn't easily grasp the essence of Example 2," I say, "You mean newbies?" Tough. They should master their tool. They should read more code written by others. That's part of being a professional programmer.

So to summarize, the distinction between essential and accidental complexity is, I think, a useful and important one in thinking about complexity of code. Second, to me the issue isn't so much simplicity as readability, and the key to readability is to stick to the idioms of your language as much as possible.