Category Archives: Development

Software Development

7 John McCarthy Papers in 7 weeks – #1 How My Thermostat has Beliefs and Goals

http://www.flickr.com/photos/midnightcomm/447335691/

Ascribing Mental Qualities to Machines or How My Thermostat has Beliefs and Goals

After reading John McCarthy’s paper this week Ascribing Mental Qualities to Machines, I can honestly say that it has changed the way I think about programs and most certainly thermostats. For you see, I realize now that my thermostat has beliefs and goals. No, it does not have beliefs about what the weather is going to be tomorrow, or when the next George R.R. Martin book is going to come out. But it does have beliefs. It has three of them to be exact:

The room is too hot
The room is too cold
The room is OK

It also only has one goal:

The room should be OK

Wat?

Why should we think of a simple thermostat this way? It is not very complex. In fact, we can completely understand its state and reason about its behavior by looking at its small and complete program listing. What benefit can there possibly be to endow the humble thermostat with its own beliefs and goals?

Start Small

Let’s step back. We are talking about designing and building intelligent systems, not just programs. The example of a thermostat is indeed small, but let us try out our ideas on a easy to understand system first. Later we can consider applying it to more complex systems.

Beliefs and Goals are Easier to Understand and Reason About

Using a higher level construct to express state can make it easier to reason and understand intelligent systems. It also is useful in describing states that are not completely known or have portions that are not easily observable. In short, defining a program’s state in terms of beliefs and goals may be closer to our natural way of thinking. When I consider my co-worker sitting next to me. I cannot hope to observe the complete mental state of him at that moment. Although I could hope to describe it at a high level with beliefs and goals. I could even hope to predict future behavior with this knowledge of his beliefs and goals, (which most likely has to do with the goal of eating more bacon).

Easier to Debug and Correct

Once we have a higher level model of a systems mental state and behavior. It would be easier to debug, communicate, and correct problems. For example, If I come home and the room is way too cold, I could look for the problem in terms of beliefs and goals. Does the thermostat have a faulty belief? Or did it have a good belief that the room was too cold? If so, then the problem was that it could not act on its belief to tell the furnace to turn on. If it could communicate and know the problem, perhaps it could message me and I could arrange a service call, or it could even self-correct. Another example, is my recent experience with my Roomba. I came home the other day to find my Roomba had not returned to its charging station after its scheduled cleaning. Instead, it was stopped under my bed. What went wrong? Did it believe that the battery was low? Or was there some other faulty belief? It would be nice if it could tell me.

Delving Further – What is a belief?

McCarthy talks about defining a belief as a function of the system’s state. For each state, there are beliefs that can be expressed as a sentences in a language. The machine does not need to understand the meaning and concepts in the English, French or any given language. That is for us to interpret. The important part is that there is a mapping of the state to this sentence. Taking our humble thermostat for an example:

(defn thermo-belief [temp]
  (cond
    (> temp 70) "The room is too hot."
    (< temp 70) "The room is too cold."
    :else "The room is OK."))

We can test our thermostats beliefs with something like:

(deftest thermo-beliefs-tests
  (is (= "The room is too hot." (thermo-belief 71)))
  (is (= "The room is too cold." (thermo-belief 69)))
  (is (= "The room is OK." (thermo-belief 70))))

This testing or criticizing the belief structure of the thermostat is what McCarthy called a Second Order Structural definition for mental qualities. This differs from a First Order Structural definition in that, rather than criticizing or testing an individual belief, he sought to describe them by testing/ criticizing the structure of the whole set of beliefs.

In the example of our thermostat, to have a “good” belief structure, in accordance with Second Order Structural definition, it the must have some consequences or actions of it beliefs. Furthermore, these actions most be consistent with its goals.

It might be expressed in code like this:

(defn thermo-action [belief temp]
  (case belief
    "The room is too hot." (dec temp)
    "The room is too cold." (inc temp)
    "The room is ok." temp))

In this case, the action of a belief is returning a new state, the temperature. Our thermostat could issue a command to the furnace to turn on. But, let us keep it simple for the moment and just think of its action directly changing the temperature. Now, our believing thermostat program can be described as having beliefs as well as taking actions from them.

(defn thermostat [temp]
  (thermo-action (thermo-belief temp) temp))
 
(thermostat 33) ;=> 34

So now we have a thermostat that has beliefs and consequences from these beliefs. We still need to figure out how to test that its belief system is consistent with its goals. Thankfully, it only has one goal to keep it simple. The goal is that the room should be OK.

(def goal 70)

Let’s say that the thermostat is doing what it believes will achieve its goals, if the new temperature is closer to its goal.

(defn distance-from-goal [g t]
  (Math/abs (- g t)))
 
(distance-from-goal goal 80) ;=> 10
 
(defn closer-to-goal [g t nt]
  (&gt; (distance-from-goal g t)
    (distance-from-goal g nt)))
 
(closer-to-goal goal 75 73) ;=> true
(closer-to-goal goal 75 76) ;=> false
(closer-to-goal goal 56 57) ;=> true

We can now construct a test to see if the thermostat actions are consistent with its goals.

(deftest themo-behavior-test
  (is (closer-to-goal goal 4 (thermostat 4)))
  (is (closer-to-goal goal 74 (thermostat 74)))
  (is (closer-to-goal goal 75 (thermostat 75)))
  (is (closer-to-goal goal 56 (thermostat 56))))

Given this particular thermostat example, we could even recursively show that it will reach its goal:

(defn thermo-simulation [g s]
(if (= g s) "Woo hoo!"
(thermo-simulation g (thermostat s))))
 
(thermo-simulation goal 73) ;=>; "Woo hoo!"
 
(deftest thermo-goal-achievement-test
(is (= "Woo hoo!" (thermo-simulation goal 73)))
(is (= "Woo hoo!" (thermo-simulation goal 100)))
(is (= "Woo hoo!" (thermo-simulation goal 33)))
(is (= "Woo hoo!" (thermo-simulation goal -33))) )

Our thermostat’s beliefs are good!

What if ….

The way that McCarthy explains the Second Order Structural definition as criticizing and testing beliefs, made me start thinking about test driven design. What if we were to start thinking and designing our programs with this testing of belief and goal structure? It could be IDD (Intelligence Driven Design) rather than TDD/ BDD. From experience, I know that TDD has changed the way that I think about coding and resulted in cleaner and more robust programs. I wonder what effect IDD could have on our program’s creation and perhaps the future of AI. Could changing the way we approach our definition of state and behavior change our software to become more intelligent? Wait a minute. If we write a test system to criticize another programs beliefs and goals, wouldn’t we be designing a program that would have beliefs about another program’s beliefs?

…

My brain get exploded.
It is in fact, turtles all the way down :)

7 John McCarthy Papers in 7 weeks – Prologue

7 Replies

In the spirit of Seven Languages in Seven Weeks, I have decided to embark on a quest. But instead of focusing on expanding my mindset with different programming languages, I am focusing on trying to get into the mindset of John McCarthy, father of LISP and AI, by reading and thinking about seven of his papers.

Why?

Get out of your box

If you are comfortable, you are not challenging yourself to grow. You are doomed to stay in your same mindset and your little box and your world gets smaller. As an Object Oriented programmer, I was happy in my little box. Then one day, I discovered Clojure and Functional Programming and my world became bigger and richer because of it. I hope to glean a similar box expansion, by exploring the thoughts of McCarthy. Especially, since I have the nagging suspicion that we are somehow doing programming “completely wrong.”

Slow Down

Reading papers is an antidote to today’s relentless stream of Twitter and Hacker News techno stuff. It forces you to slow down and read something …gasp, maybe even the same thing multiple times and digest it. Thinking slow and eating more veggies is something we could all do more.

Structure

Following a somewhat arbitrary schedule of seven papers in seven weeks gives a structure that gives an measurable goal and timeline to this endeavor. Which gives you a fighting chance of actually getting it accomplished.

The Answer is Never Too Far Away

When we are presented with a problem, more often then not, the answer comes to us from some of our recent thoughts and experiences. Many breakthroughs in new technologies have come from cross pollination across different fields. Exposing yourself to a new ways of thinking gives your creative problem solving abilities new and powerful ammunition.

Encourage Others

Serendipity moves in mysterious ways. By sharing your travels and thoughts, who knows what might spark in someone else’s mind…

So I encourage you to join along. Pick a paper that appeals to you and read it this week. Think about it, talk to your co-workers about it, maybe write about it, or even code from it. But most importantly, slow down and take a moment to peek outside your box.

The Software Bathtub Curve

Code Mash 2012: Bacon for the Brain

1 Reply

I was delighted to see first hand, why 1200 CodeMash tickets sold out in 20 minutes. It was full of awesome. This was easily the biggest conference that I have ever attended. It was held in the luxurious and fun Kalahari conference center and ran as smooth as silk, expertly supported by a volunteer staff.

One of the things that I really appreciated about the conference was the diversity of people from different technology backgrounds. There were many developers from .NET, Java, Ruby, and Python worlds all coming together to swap stories, share ideas and learn something new. It created an opportunity for everyone to get out of their box and their comfort zone. I was particularly impressed by one woman that I talked to, who came from the .NET world but had made a conscious decision to not attend any .NET talks at all.

The talks that I attended were all superb. Here is a few of my personal highlights:

Jim Weirich’s Roman Numeral Code Kata: He did a live coding demonstration of the Roman Numeral kata by TDD and refactoring. The joy that he shows when his tests turn green and the love of the beauty of the code that emerges from refactoring, embody for me what Software Craftsmanship is all about. He simply is an inspiration.
Joshua Smith’s Prolog Talk: An excellent talk by and excellent speaker. He demonstrated the basics of Prolog reasoning by doing a family tree example. I am intrigued by it’s use with Semantic Web RDF reasoning and it’s similarity to Clojure’s core.logic. It is top of my list of things to look into.
Jen Myer’s Developers Can’t Design: She touched a chord for me, since I wish that I had more design skill. She masterfully pointed out the similarities of solving problems in design just as we solve problems in code development. Another key take away for me, was the need to have a holistic design for our applications. Siloing designers in Photoshop and then having developers take it from there is reminiscent of failed waterfall patterns. Embracing holistic design feedback at all levels of the project is needed to produce excellent applications.
Elizabeth Naramore’s Building Open Source Communities: This talk was a gem. She touched on the importance of Open Source communities by focusing on it’s essential component – people. Communication is so important in facilitating the flow of ideas that turns into the magic that fuels a vibrant community. One of her points, that I took away is to remember it is the little things that count. Don’t forget to say “Thank you.”

Another thing that delighted me was the strong interest in Clojure that was present at the conference. I had the good fortune to present an introduction to Clojure and I was so happy to talk to many people during the conference that said that they were interested in learning more at the language. There was even an Open Space that got spontaneously organized on Clojure on Friday.

The only downside of the conference was that it was hard to choose between the Open Spaces and the excellent talks going on. I did attend one that Justin Searls hosted on Friday afternoon. It was a blast. People paired up creating a simple JavaScript To Do app from different frameworks. John Andrews and I took the opportunity to explore ClojureScript. In particular, we played around with the new ClojureScript One and also the Enfocus library. At the end of the hour, we were having so much fun, I wished that we had another day just to continue.

All in all, it was an awesome time and I recommend it highly. If I had to sum it up in a phrase it would be: Bacon for the Brain :)

On Men in Ballet and Women in Software Development

Long ago, I worked for a couple years as a professional ballet dancer with a small company. Reflecting on this, I have an interesting perspective of working in field were woman are the majority and also one where women are in the minority. I thought I would dedicate this post a few observations of similarities between men in ballet and women in software development.

Men in Ballet

Cervilio Amador from the Cincinnati Ballet

http://www.cballet.org/about/dancers/principal/amador

Have some lame people think ballet is just for girls and make assumptions about them based on cultural stereotypes
Have to have a sense of humor to handle accidentally injuries due to kicks or slips while rehearsing choreography with women.
Clearly love what they do. Otherwise, they most likely would have never overcome the social pressure to pursue their craft.
Partner when ballerinas to create great performances. The diversity of having men and women dance together allows more freedom of expression in the choreography. Ultimately, that produces a show that is more valuable and pleasing to the audience.
Usually have no wait in line for the men’s restroom during ballet performance intermissions.

Women in Software Development

Have some lame people think software development is just for boys and make assumptions about them based on cultural stereotypes.
Have to have a sense of humor to handle accidental insensitive remarks due to slips in conversation when working with men. (Ex: hot chicks, rude jokes, etc….)
Clearly love what they do. Otherwise, they most likely would have never overcome the social pressure to pursue their craft.
Partner with other software developers to create great software. More diversity*, allows more freedom of expression in understanding and applying technology to solve business needs. Ultimately, that produces software that is more valuable and pleasing to the business and user.
Usually have no wait in line for the women’s restroom during technical conference breaks.

*And yes, the diversity I am talking about is not limited to just men and women.

Project-Grep : Another Sharp Tool for your Emacs

Since joining EdgeCase, I have shelved my heavy Intellij and Eclipse IDEs in favor of Emacs. Overall, I have enjoyed moving to the light-weight but powerful editor. There is one thing that I did miss from my IDEs – that was the ability to search projects for string occurrences and being able to click navigate to them through the editor. Fortunately, one of the strengths of Emacs is it’s infinite configurability and extensibility. Even more fortunate, one of the guys in our shared office, Doug Alcorn of Gaslight Software, had already written just this feature for his Emacs. I installed it and was so pleased with it, that I thought I would share …

https://github.com/dougalcorn/emacs.d/blob/master/site-lisp/misc/project-grep.el

To install:
Download project-local-variables.el and project-grep.el
In your init.el file: (require ‘project-grep)
Create an empty .emacs-project file in your directory

To use: meta-x project-grep

Project-grep

Super Easy Clojure Web Apps with Heroku Cedar

Deploying Clojure apps with a single command to the cloud is now possible with Heroku Cedar and let me tell you, it is pure joy.

I experimented with this the other day by creating a Compojure web application that compares the followers that two twitter users have in common.

Here is the secret sauce you need to push your apps to Heroku:

1) Procfile:
You need to create a file in the root of your directory that contains the way to start up your application:

 web: lein run -m ring-twitter-common.core

2) The application must have the project.clj setup correctly so that you can just run:

lein deps

3) You need to install the Heroku gem

Once you have this setup you simply do:

heroku create --stack cedar

git push heroku master

That’s it. Your webapp will auto-magically be created, and deployed and be available for your viewing pleasure.

You can check out my sample Twitter Heroku app here:
http://ring-twitter-common.herokuapp.com/

But wait, you say… wouldn’t it be awesome if you could just write your Clojure app and say lein deploy and have it all work? Wouldn’t it be super awesome if there was some command to generate a skeleton for your Compojure app? The solution is actually in the planning stages by James Reeves (weavejester)! Hooray!

Leiningen Google Group Text

In summary: Developing Clojure Web Apps just got easier and the future is only looking up :)

Clojure Dictionary Challenge

There was a question today on Twitter about how to go about finding the word with the most consecutive consonants in the dictionary file. Of course, being a typical developer, when presented with a problem – I am usually not satisfied until I find a solution. Since I am interested in learning Clojure, I thought I would try to solve this problem functionally.

Armed with Stuart Halloway’s “Programming Clojure” and trusty Google by my side, I embarked on my first Clojure mission.

Starting small – I decided to tackle the issue of finding consecutive consonants in a word. I found that re-seq handles regex very nicely

user=>  (re-seq #"[^aeiou]{2,}" "batty") 
("tty")

Building on … let’s find the number of letters in this word. Since we have a sequence – we need to get the first element off of it, convert it to a string and find the length of it

user=>  (.length (str (first (re-seq #"[^aeiou]{2,}" "batty"))))
3

Not bad – but let’s turn this into a function now

user=> (defn count-cons [s]
   (.length (str (first  (re-seq #"[^aeiou]{2,}" s))))
 )
#'user/count-cons

Now we can call the function directly

user=> (count-cons "batty")
3

Alright – we are making progress. Next step, we need to be able to compare two words and see which has the bigger consonant count and return that. For this, we will need a little “if” magic.

user=> (defn compare-words [s1,s2]
(if (> (count-cons s1) (count-cons s2))
  s1 s2))
#'user/compare-words

Let’s test it out

#'user/compare-words
user=> (compare-words "batty" "bat")
"batty"
user=> (compare-words "bat" "batty")
"batty"

Oh, yes, we are getting to the good part now. Since we have a function that we can call on two arguments and give us one back that we can work with – we are ready to pull out the big guns …. reduce!

user=> (reduce compare-words ["vat", "batty", "cars"])
"batty"

Yeah! Next we just need to feed it a file. For this, after doing some research, I used the duck-streams library – you need to load it in using

user=> (use '[clojure.contrib.duck-streams :only (spit read-lines)])

nil

We open the file and read the lines and feed it to our function

user=> (reduce compare-words (read-lines "/usr/share/dict/words"))

"Ångström"

Yes, my regex needs some tweaking – but for this exercise, I am content.

When you just have the working code. It is actually quite concise:

;Counting consecutive consonants

(use '[clojure.contrib.duck-streams :only (spit read-lines)])

(defn count-cons [s]
   (.length (str (first  (re-seq #"[^aeiou]{2,}" s))))
 )

(defn compare-words [s1,s2]
(if (> (count-cons s1) (count-cons s2))
  s1 s2))

(reduce compare-words (read-lines "/usr/share/dict/words"))

All in all, a fun evening trying to think functionally.

Agile Software Lessons from Ballet

Swan Lake
Photo by Valentin Baranovsky – Uliana Lopatkina and Danila Korsuntsev.

Many moons ago, I spent a couple of years dancing with a ballet company. You wouldn’t think that much of that experience would transfer to development projects, but I give you an example in partnership, the can be applicable straight from the ballet world to the software world. The partnership in question is the one between the lead ballerina and the lead male dancer called a “pas de deux.” In many ballets, this dance involves the ballerina being a swan/princess and the male dancer being a prince/sorcerer. But in my example, it really doesn’t matter that much. The only important point is that they are the best dancers in the whole company.

Each one of them can astound the audience in their solo moves, but in their duets – they can do really awesome things. The male dancer supports the ballerina during dazzling spins and carries and lifts her in heart-stopping moves across the stage. When it is done well, the audience goes crazy and gives them a standing ovation. They can only pull off this spectacular performance if they have developed a great partnership. Of course they are brilliant performers individually. But they need more than that to pull of a pas de deux. The job of the ballerina is to be lovely, graceful and technically brilliant. The male partner must also to graceful and skillful (maybe not so lovely) – but his main job – is to make the ballerina look good. Failure to make the ballerina look good – even if you are the most talented dancer in the entire universe – will still make you a lousy partner. I don’t care if he can spin one hundred times a second and can jump one hundred feet in the air. If he is performing a pas de deux, and he drops his lovely ballerina on the floor, he is a lousy partner and she will be guaranteed to burn her toe shoes before agreeing to share the stage with him.

Reasons for being a bad partner in ballet (or dropping your ballerina):

You didn’t have enough time to rehearse
You don’t like your ballerina
You think you should be a the star of the show and don’t want anyone to look better than you.

Now let’s go to the world of the corporate software project. You have your developers and your business partner – the customer. You, the developers, have the supporting role. You main job is to make the customer look good. That’s right, through your mastery of technology, you must partner with your customer to help them accomplish their business goals and make them look great. If you metaphorically, drop your customer on the floor, then you are obviously not a good partner.

Reasons for being a bad developer partner in software projects:

You are new to the team and haven’t gotten into the communication groove yet

This is alright in the beginning of a project. Heck, it happens when ballet dancers are just learning their dances too. If you are doing short iteration cycles, then the first couple will be a little rough. But with feedback you will improve and your team will start to gel and shift into high performance.

You think all people that are not IT are idiots.

I have seen this sentiment common on projects that have a strict division between the IT people and the business people. Somehow, it turns into a horrible sentiment that the anything that the business users ask for is a waste of time and only the IT department knows the right things to do. If you have your team mixed with developers and business people this will help break down such harmful barriers.

You think that you are a Superstar and want to showcase your technical talents in your application – maybe they will start asking you to speak at the Google Confs after they see your work.

You may be the Ninja Assassin of the Black Arts of Java, Ruby and all the cool Functional languages, but if you can’t accomplish what your business needs to look good, then you suck as a partner. Frequent communication with the customer is key. Fun is fine, but please examine your motivations for putting in that cool new feature. Is it going to make the customer look good or you? Again, short iterations and feedback cycles will help put the focus back on what the customer wants and needs.

Communication, feedback are essential elements to a good partnership in the ballet world and the software development world. Don’t ever forget to make your customer look good and your projects will be sure to get a standing ovation.

The Smart Not-So-Smart Wave Function

I am cruising along in my morning. I have a cup of tea in my hand and a good outlook on my tasks at hand. The code is flowing off of my fingertips. I am feeling pretty smart. Then the cloud moves in and the code darkens. I am at a roadblock. I try to google, I try debugging, I try calling in my fellow developers to see if they can see what the problem is… no luck. I bang my head unproductively for another hour and then go home. A fresh start in the morning and a fresh cup of day move me in a new direction, somehow I stumble upon the answer and quite frankly, it was so simple I can’t believe I missed it. I feel not so smart. This is one of the many smart-not-so-smart waves that rule the life of a developer.

The example above is what I would call a mini-smart-not-so-smart wave. There are much bigger ones too and much more important too. These are the sort of moments that you encounter that you feel stupid in a really good way. You learn a totally new approach or way of doing things and much better because of it. One of these moments was when I went up to a MySQL Drunken Query Master Presentation by Jay Pipes. He is a brilliant speaker. Before I went up there, I thought I was pretty smart. I knew how to swing inner and outer joins on my queries and how to optimize using the explain plan…. After listening to him, I felt really not so smart. I had been using Theta style instead of Ansi style in my queries and I really had no idea of how to use the storage engines properly and really understand how the optimizer worked or even more important… to really do queries well, you need to stop thinking in logic loops (the comfortable world of the developer) and start thinking in sets. Yes, I felt really dim, but my world view had grown and I had found a whole range of stuff that I didn’t know. I had uncovered a whole dark section “how do you know what you don’t know”.

I had similar experiences when I attended some OWASP security talks and realized that I really didn’t know much about software security and it is actually quite important to learn and consider in design and development to make better more robust software. More recently, I have been spending my not-so-smart cycle time learning more about Test-Driven Design and Agile development by learning Ruby and attending some awesome local community user groups.

So, if you are feeling smart and have been for awhile. It is really time to look around for something to challenge you views. Look at a completely different field in technology then you are used to, try QA, project management, security, cloud computing, data governance. Go out in the community and talk to people in user groups. Push yourself of in the not-so-smart wave section and you will emerge smarter and happier for it.

Squid's Blog

Random and Occasionaly Useful Thoughts About Technology