I've programmed professionally using Python for several contracts/years now and find it quite enjoyable. In fact, I'm currently coding specifically in Python for Inkedmagonline.com, but that doesn't mean that I don't continue my personal exploration and education for both personal and professional reasons. I decided to re-experience Ruby by picking up the hallowed PickAxe book and giving it another honest chance. I'm glad I did.
I believe that Python, and the values espoused in Tim Peter's "De Zen van Python" (The Zen of Python) (my copy just happens to be in Dutch, otherwise I'd post it for others) have helped me to look at Ruby in a different light. There are some key differences in the two languages, but I can see now the inherent power in Ruby that I was overlooking before. In fact, some of those key pieces, syntactically as they were which make Ruby so enticing this time around are the very same 'features' I feel are missing in Python. It only took me working in an environment with situations where said language features would prove the best solution to the problem(s) on hand for me to realise it.
I am not going to spend time detailing all of the specifics, though I may mention one or two nonetheless. I'm more so bringing this point up so that others might be reminded that giving something new a single chance might be to your own disadvantage. After all, I didn't like Python the first time I tried it either. I think it is partially a matter of how we grow as developers that allow us to know what we're missing, that same spark of realisation that gives us the "a ha" of relief when we find it hiding in a new language, programming methodology, etc.
What brought me back to looking into Ruby a second time is of all things, Smalltalk. The whole "everything is an object" concept is nothing new to me, or to programming languages. However in dynamic strongly typed languages, it is. More importantly is manner of how even rudimentary objects such as integers, floats and strings are treated in Ruby. They have methods which can be both called using the standard instance.methodname call format, and have their standard methods overridden. The second being something far more wonky and kludgy in Python (and a non-option in perl).
The fact that key methods are instance based such as "len" or "length" for example makes a world of difference for consistency. It speaks to the overall design that "Matz" (Yukihiro Matsumoto creator of Ruby) had in mind during the planning phase. In Python, a language in which everything is truly an object as well, this starts to get rather confusing. While Python does treat every integer and string as an object, it mixes the traditional functional paradigm for calling items such as 'len' so that to find the value of 'a', one would type len(a), as opposed to the more object based a.len .. This seems counter-intuitive and quite frankly a real surprise when you look at the overall design of Python.
I'm not ripping on Python as I do wholeheartedly enjoy the language, I'm just starting to feel aches and pains over decisions which are ingrained into the language, as well as not being seen as an issue or being addressed in py3k (or Python 3000/Python v3.0) as it were. I just think that my eyes have been opened to Ruby again and I like what I'm seeing. I am actively looking to find a future professionally as it were utilising it as nothing beats having fun while accomplishing what one would hope accounts to 'great' things. We'll see what the future holds.
Next Step: Migrate my SimulaE virtual world/real model object simulation from Python into Ruby as a test run. Lather, rinse, repeat and then see what the side-by-side comparison's look like.
Until next time...
No comments:
Post a Comment