This is not an article about genetic algorithms. It’s about us. You, me, that guy over the other side of the coffee shop hunched over his ipad.

Let me explain. This afternoon I attended a meeting with my new clients. After the meeting, I was one of the only people in the room with a camera (on my ipad). So, the project manager running the meeting asked me to photograph the whiteboard and send her a copy.

So, I clicked a couple of shots, checked that they where not washed out with glare or bad contrast and headed back to the office.

When there, I tried to send the picture to the project manager, but the office guest wifi was not working so the email would not send.

There I sat, thinking furiously, “how can I get this photograph over to Eileen? Hmmm. She is sitting over there on her laptop, but I don’t have a wifi connection!’. There I sat for all of 10 seconds until the forehead slapping moment came. I stood up, walked over and handed her my ipad with the picture displayed.

So, I ask, what is living in a digital world doing to our brains when digital problems overshadow analogue solutions?

In Ruby, you don’t have access to the properties of an object, not directly anyway. You have to access them via a method.

>> class Klass
>> def initialize
>> @pickled = true
>> end
>>
?> def pickled
>> @pickled
>> end
>>
?> def pickled= value
>> @pickled = value
>> end
>> end
=> nil
>>
?> a = Klass.new
=> #
>> a.pickled
=> nil
>> a.pickled = "Sausage"
=> "Sausage"
>> a.pickled
=> "Sausage"


Thats a little long winded, so ruby offers us some sugar.
>> class Klass1
>> attr_accessor :pickled
>>
?> def initialize
>> @pickled = true
>> end
>> end


Personally, I don’t like either of the above. The assignment within the initialize method is not going through the accessor.
So any logic we place in there to safeguard things is not being performed on the initial assignment

>> class Klass1
>> attr_accessor :pickled
>>
?> def initialize
>> self.pickled = true
>> end
>> end


Much better. So, ruby keeps attributes internal to its objects and forces us to expose what we want. Python is different, idiomatic python tells us accessing properties from outside is fine.

>>> class Klass(object):
... def __init__(self):
... self.pickled = False
...
>>> a = Klass()
>>> a.pickled
False
>>> a.pickled = "Bacon"
>>> a.pickled
'Bacon'


It’s not the same, not at all. There is no place there for guarding things. You CAN guard things though, lets see how you do that.

class Klass(object):
def __init__(self):
self.pickled = True
 
def _set_pickled(self, new_value):
print "> in setter"
self._pickled = new_value
 
def _get_pickled(self):
print "> in getter"
return self._pickled
 
pickled = property(_get_pickled, _set_pickled)
 
a = Klass()
print a.pickled
a.pickled = False
print a.pickled
a.pickled = "Eggs"
print a.pickled


And there are no prizes for guessing why it is idiomatic to go to the properties directly.

What are these underscores for? Well, by convention any methods you define that are used as the mechanics for how a class operates are ‘guarded’ by adding either one or two underscores.

Another aspect of this is that there are two ‘things’ that you can access on an object, its properties and its methods. Haha, see what I did there? I lied. There is only one. Properties! methods are properties of their objects.

>>> class Klass(object):
... def method(self):
... print "Bingo"
...
>>> a = Klass()
>>> a.method
<bound method Klass.method of <__main__.Klass object at 0x1034198d0>>
>>> a.method()
Bingo


Thats actually quite nice in some ways, it means you can pass around a method on an object to anything that wants a callback. On others its a pain, cos it means that for a lot of things you have to KNOW whether something is a property or a method returning a value. In Ruby, you don’t have that. It is possible to use property() to hide things behind methods or indeed to use the @property decorator to do similar for getters, but it’s a fair bit more cumbersome.

In Ruby(1.8.7), truth and falsehood are expressed by the literals “true” and “false”.
true has a class of TrueClass and false has a class of FalseClass.

>> a = {}
=> {}
>> if a
>> "Empty hash is true"
>> else
?> "Empty hash is false"
>> end
=> "Empty hash is true"
>>
>> a = ""
=> ""
>> if a
>> "Empty string is true"
>> else
?> "Empty string is false"
>> end
=> "Empty string is true"
>>
>> a = []
=> []
>> if a
>> "Empty array is true"
>> else
?> "Empty array is false"
>> end
=> "Empty array is true"
>>
>> a = 0
=> 0
>> if a
>> "Zero is true"
>> else
?> "Zero is false"
>> end
=> "Zero is true"
>> if nil
>> "Nil is true"
>> else
?> "Nil is false"
>> end
=> "Nil is false"


That shows some interesting things. Most of the above, I am willing to accept. Empty strings, empty arrays, fine, they can be true, but ZERO? how can zero be true?

Python has a slightly different take on it.

In Python, both of the literal truth values (True and False) are of class bool. Testing the same things as with Ruby gives us :-

>>> if {}:
... print "Empty hash is true"
... else:
... print "Empty hash is false"
...
Empty hash is false
>>> if []:
... print "Empty array is true"
... else:
... print "Empty array is false"
...
Empty array is false
>>> if "":
... print "Empty string is true"
... else:
... print "Empty string is false"
...
Empty string is false
>>> if 0:
... print "Zero is true"
... else:
... print "Zero is false"
...
Zero is false
>>> if None:
... print "None is true"
... else:
... print "None is false"
...
None is false


So, in Python it is possible to use most of the basic objects as truth values but in Ruby, not so much. Personally, I prefer Pythons way with this than Ruby, not least of which is that the two literals are of the same class.

So, I have a little time on my hands at the moment. I’ve started having a play with eventmachine (sort of a ruby nodejs), websockets and webgl (more on webgl later).

Yesterday I started off with a really REALLY simple online webchat. You can see a demo of it here http://fatgeekuk.org/web-chat/.

It leaves MUCH to be desired in both styling and functionality. But, it is a ‘plausible promise’.

Any comments welcome.