Ruby Monkey Patching Slang
August 12, 2007 at 11:36 AM | categories: humor, ruby | View Comments Stumbled across a great list of "alternate" terms for Monkey Patching in Ruby: My Complete List Of Substitute Names For The Maneuver We Now Know To Be MonkeypatchingWorse is better?
June 29, 2007 at 12:09 AM | categories: python, ruby, freebsd, linux | View Comments Linux : FreeBSD :: Ruby : Python Discuss.Python Party in Ruby
June 17, 2007 at 12:57 PM | categories: python, ruby | View CommentsLast month, a lengthy discussion kicked off on Ruby-Talk called "Why not adopt Python style indentation for Ruby?" .. it wasn't anything particularly new, because a similar discussion occurred six years ago. Nevertheless, a coder called Jinjing has been inspired to create Lazibi, a Ruby pre-processor to allow one to use Python style indentation within Ruby code.http://www.rubyinside.com/lazibi-python-style-indenting-for-ruby-532.html Why not just adopt Python altogether? :-P So close and yet so far.
Understanding Monkey Patching
May 24, 2007 at 12:53 AM | categories: python, ruby, software engineering, rails | View Comments I've noticed one of the problems I have writing this blog is that I prefer to have finished thoughts when I write up something, or at least to have a good understanding of a problem I am working on before committing it to 'paper'. Unfortunately, this doesn't lead to many updates. I'll try to break this habit a little. Recently I heard the term 'Monkey Patching' after one of the Seattle Patterns Group meetings, in relation to Ruby on Rails.A Monkey-Patch (also called Monkey Patch, MonkeyPatch) is a way to extend or modify runtime code without altering the original source code for dynamic languages (e.g. Ruby and Python).Today, reading a blog entry from Chad Fowler, the term came up again with a Python developer saying:
You can monkeypatch code in Python pretty easily, but we look down on it enough that we call it "monkeypatching". In Ruby they call it "opening a class" and think it's a cool feature. I will assert: we are right, they are wrong.When I read that, I felt almost relieved, because I was thinking the same thing. I can see a limited use for it, but it seems like something you should only do in dire circumstances, that it would be detrimental to good software engineering practices. I can't prove this, nor am I totally convinced, but Ruby and Ruby on Rails in particular seems to play a little bit fast and loose. I suppose this fits in with Agility, but there does seem to be a mental divide between Python and Ruby people (even though they are really quite close linguistically). To date, I'm much more in the Python camp, but I've been deploying Rails apps at work, and I'll be delving more into Ruby as I go forward. I have heard rumors that Zope does Monkey Patching, and this convinces me even more. Zope has almost single handedly destroyed Python's reputation at my place of work. Thanks Zope!
Python vs Perl vs Ruby vs PHP vs Java
July 07, 2006 at 10:08 AM | categories: java, python, programming, perl, php, ruby | View CommentsWaiting For Python Web Frameworks
April 23, 2006 at 04:22 PM | categories: python, ruby, turbogears, rails, django | View Comments I've tried out Turbogears and Django, ultimately putting together a quick prototype in Django, because the built in admin interface was the only thing left for me to complete. It was simple enough to port over my object from Turbogears, add in some meta data and push the whole thing to "production". Unfortunately, I started coding in Django right before the "magic" removal branch went public. The documentation didn't mention anything about a massive API change that seems to require lots of changes to any code you write. Not that it is too important to me, it will be faster for me to start over and move the methods into the new branch. Still frustrating. Of the two, I think Turbogears has the long term advantage. I love the fact that someone took the time to integrate a bunch of seperate programs into a whole (it's not quite coherent yet). The desire to re-invent the wheel is strong with all programmers and I've done it myself a couple times. Turbogears also is not quite ready, they have some nice widgets that will be a joy to use, but when I tried, I couldn't find any documentation beyond the wiki. The example in the wiki didn't work with my build, so I decided I would come back to it after I had tried Django. Maybe after they come out with 1.0. Which leaves me to ponder trying out Ruby on Rails. Frankly, I've been avoiding it because I want to stick with Python. I've been using Python for all my Unix Scripting and I love the way it is put together. I've heard good things about Ruby, but I also want to deepen my Python experience, not dilute the languages I know with yet another one. But considering Rails is past 1.0 and is gaining momentum, it would be a mistake not to look into it further. There is no doubt in my mind that I ever want to go back to writing straight PHP if I don't have to though. These new frameworks make writing web applications a joy. The thought of thousands of lines of poorly written PHP make me shudder.Dynamic Languages on the JVM
April 22, 2006 at 03:17 PM | categories: python, ruby, java, django | View Comments I've been focusing on Python lately, mostly for web development. It is strange, but it doesn't quite feel ready yet. Obviously, there are large production sites deploying on some of the frameworks like Django, but compared to Java and Tomcat, Python web development is still in the infant stages. Even so, the productivity that Python provides over Java is astonishing. PHP just makes me laugh, though PHP 5 does clean up a lot of the warts. The only good thing I can say about PHP right now is that it is ubiquitous and easy to learn. I don't know how I missed it but in late 2004, there was an awesome meeting of the minds at Sun which included:- Larry Wall
- Guido van Rossum
- Jython folks
- Groovy folks
- Parrot people
If Sun would release the JVM under the GPL or BSD or even the Mozilla MPL, and create awesome support for dynamic languages, it would explode all over the web server scene. Heck, I would pay good money for a JVM that had first rate support for Python. It would also help consolidate Ruby, Python, Perl and Java. I guess Parrot could do this, but honestly it will take years for it to be as fast as the JVM on all the platforms Java currently supports. The JVM is an impressive bit of Sun kit, but Sun has tied too closely to the Java language. Sun, open up the JVM even if you keep the Java spec under your control. This is the best of both worlds and would take a major bite out of .NET. Unfortunately, Sun will probably let the JVM wither away just like they are doing with Solaris. Sigh.