Showing posts with label logic. Show all posts
Showing posts with label logic. Show all posts

Sunday, April 12, 2015

Rearrangeable FizzBuzz

"What zeal, what fury hath inspired thee now?"
-- Shakespeare, Love's Labour's Lost

I was inspired a while back by the talk "Write the Other Half of Your Program" by Jason Hemann and Daniel Friedman.


In the talk they showed how one could take a program written in Racket and translate it over to miniKanren.  One of the things I found very interesting was rewriting conditional statements in such a way as that they can be reordered and still produce the same result (I believe would eliminate procedural cohesion).

What would an example of this look like?  Let us look at one example with the FizzBuzz kata.


We see in the code above that the conditional statements around when to Fizz, Buzz, FizzBuzz, or just return the value given are more complex than they normally are.

Here is the Fizz condition:

(and
(fizz? x)
(not-buzz? x))

We see that in the Fizz condition we are testing that it is a Fizz and that it is not a Buzz, this will allow us to relocate the this condition before the FizzBuzz condition if we want to, but only if the FizzBuzz condition will allow this (which it will).

Here is the Buzz condition:

(and
(buzz? x)
(not-fizz? x))

We see that it is the reverse of the Fizz.

Here is the FizzBuzz condition:

(and
(buzz? x)
(fizz? x))

We see that we are testing for both Fizz and Buzz conditions.

Finally here the else condition:

(and
(not-fizz? x)
(not-buzz? x))

We see that we are looking for Not Fizz and Not Buzz.  In a sense we have came up with our own little DSL around the logic of FizzBuzz and at the same time have written our conditions in such a way as to allow for them to be completely rearranged!


Sunday, November 10, 2013

Code is Part of the Programmer and the Programmer is Part of their Code

"My songs cease, I abandon them,
From behind the screen where I hid I advance personally solely
    to you.

Camerado, this is no book,
Who touches this touches a man,
(Is it night? are we here together alone?)
It is I you hold and who holds you,
I spring from the pages into your arms—decease calls me forth.
"
-- Walt Whitman, Leaves of Grass (1891-1892, Deathbed edition)
So Long!, page 382

Being a programmer, a creator of worlds, is both humbling and invigorating at the sametime.  Everytime that I work my craft, I truly have endless potential, I could create something which changes lives or I could write a shitty monkey patch to just get something "done".  Even if it does not seem like it, the choice is always up to me.

Today, more so than any other time in human history, we software developers have created a small part of the world that exist.  Our creations have influenced and altered human civilization.  Don't believe me, post something to your Facebook that you know will get a response from family or friends.

When my first nephew William was born, my wife and I were let to see him only an hours or so after he was born.  I did what anyone else would do of my age group, I took pictures of him and us which I shared on Facebook.  Almost instantly I got a ton of likes and comments attached to these pictures, it then dawned on me that these were most likely the first images of Will that a lot of people would see.


And if you gaze for long into an abyss, the abyss gazes also into you.

-- Friedrich Nietzsche
Beyond Good and Evil, Aphorism 146
(generated from The Nietzsche Family Circus)

We creators of programs become part of our programs, which become part of us.  These programs become part of the user and the user becomes part of the program.  Thus, we programmers much like a poet, become one with our users and they become one with us.  This is really a humbling thing to think of.

Most of us do not work for Facebook or on code which is released to the general public, but our code is hopefully used.  When our code is used by someone or something it becomes a small part of that someone or something.  The point being, we become one with the world we consume and it becomes one with us.  When you stare into the abyss it stares back into you.

So what does this mean?  Which would you rather be associated with?


I have used my share of crappy software and third party vendor add-ons, when I use these "products" I cannot help but feel that the people who created them simply do not care.  I know this is faulty logic, in fact it is the fundamental attribution error, but still, WTF!  I am not alone in this feeling, in fact Uncle Bob recently blogged about his experience with Healthcare.gov and upgrading his Mac (neither of which were good experiences).

Becoming one with the world is not limited to programmer's end products!  This oneness with the world extends to their code they commit to source control!

At SCNA this Saturday, (November 9, 2013), Katrina Owen in her Here be Dragons talk linked the Prisoner's Dilemma to the development of software.  You see everytime you check in code you can either check in something that will be a pleasure for someone in the future (which might be you) or something that will cause a ton of swearing.

The choice is up to you, but the choice is even deeper than simply what you d.  Believe it or not what you check in influences other people.

Humans generally want to be cooperative and helpful to each other, but when crossed, O-boy the claws come out!  This applies to your code in the following way.  

Say that you are generally careful with your code and do all kinds of well thought of things (today that would be BDD, unit testing, "clean code", ...).  Others will see this and will most likely than not follow suit and raise the bar even higher.  The code base will generally become better overtime and general happiness will ensue.  The team will get along and will become happy with their code and the code will become better ...

What happens if someone has a bad day and checks in some crappy code?  One of two things could happen: either people retaliate with crappy code which could cause a downward spiral or they could let it slide, fix it, and continue checking in careful, well thought out code.


This my friends is the Prisoner's Dilemma!

With just one commit we have a simple Prisoner's Dilemma, but most programmers will work with each other for an undetermined number of commits across many days, months, years, and sometimes even decades!  This moves us from a simple single round of the Prisoner's Dilemma to that of an Iterated Prisoner's Dilemma.  In this type of game, the best strategy is what is known as tit-for-tat.

A tit-for-tat strategy:

1) start by being cooperative
2) do what the other player did

Tit-for-tat starts by being cooperative, thus starting things off on the right foot.  After the first cooperate, the tit-for-tat player will do whatever the other player did previously, thus if the player was cooperative the tit-for-tat player will be cooperative, if the other players defects, then the tit-for-tat player will defect. Defecting when the other player defects can lead to hell  A slightly more efficient tit-for-tat strategy will cooperate at random when in a defect spiral, this will allow for one to get out of a defect spiral, if one can.

With code (and everything else) things are not as simple as cooperate and defect, this is for many reasons, the most important one being not everyone agrees on what "Clean" and "Crap" code is, but we are humans and have a sense of being treated fairly and not fairly.  Thus, one can know if they are in a defect spiral or not.  If you find yourself in a defect spiral you can either see if things will change by issuing a corporate or simply leave.


Whoever fights monsters should see to it that in the process he does not become a monster.

-- Friedrich Nietzsche
(generated from The Nietzsche Family Circus)

If you are in a defect spiral, leave before you to become a monster and always start by committing well thought out clean code.  Thus, be what you want the world to be, for your code is more than just code, it is part of you and you are part of it.

Wednesday, August 4, 2010

What Side of the Tracks Should I Be On?

Whenever I can, I try to take a train to the city. Trains are great: no traffic jams, no trouble finding a parking spot, and no taking the wrong exit off the highway. Plus they are green (for the most part).

One thing I noticed is that most of the time the train station gives no indicator as to which side of the tracks to be on. In the morning when there are lots of people going to work, this is not an issue. Just go to where the people are. However, this does not work at odd times when you might be the only person at the station.

When at a station by one's self I find the general rules to help tell which side of the tracks to be on.
  • Most people wait for the train in the morning on their way to work in the city, when they get off the train on their way home they do not wait around they just leave; therefore the benches and covered waiting areas are on the side of the tracks going to the city.
  • If benches and covered waiting areas are on both sides of the tracks, the side with more benches and larger covered waiting areas is the side going to the city (the reason is volume).
  • If there are three or more tracks with a fence splitting the tracks, the slide of the fence with more tracks is the side going to the city (again the reason is volume, but this time in the number of trains).
Following these simple rules should help get you on the right side of the tracks, if they do not work please let me and others know by commenting.