Hacker News Reader

We run probably one of the largest Ruby production systems that has ever been made and the dynamism and "monkey patching" are used daily to skillfully make the language better and better over time for the tasks that we solve.

It's absolutely crucial to teams that internalize it's power and pitfalls.

"one of the largest Ruby production systems that has ever been made"

As an aside, I worked on a very large Ruby app (built by about a dozen developers over the course of years) and then later worked on another very large Ruby app of similar size. One of the employees there remarked that it was the largest Rails app built. I think the people who write very large Ruby apps tend to be very quiet about it (no blogs, no open-source, less community participation, etc.) so that if you're one of the ones writing a very large Ruby app you think yours is the largest. :)

I can fully agree about the quietness of developers working on large ruby app considering I work on such an app but were not big on advertising it yet.

Lol, I work on a Ruby app that is entirely internal and processes an incredible volume of information. The key here was the ease of adding a few key C modules.

I was about to ask if you work for Twitter, but then I read your bio. I like Shopify, all the shops built with it look real slick.

Oh, and I like delayed_job as well.

It's an extension of the critique leveled at dynamically typed languages by Java/C/C++ devs. How can you possibly work in a world where function foo can return/expect any type?

The more dynamic (powerful?) the language the more leverage good, experienced developers have. They can achieve results in 10 lines of code that are hard/impossible in more static languages (closures, meta-classes etc.). The other edge of the sword is that one dud developer can bring your whole stack down by being too smart for their own good. The more dynamic the system the greater the risk. In Ruby as is pointed out you can have a developer on the other side of your code base royally screw you because he wants feature X of sequences to act differently.

As with all things it's a balancing act, how smart are your devs, how much time can you spend testing and how strict are your coding standards.

I can believe that such power can be achieved and scale within a single department-size group of "smart people".

The problem appears if or when you want to share the code between departments or give it to the world. Give "clever code" to someone who simply doesn't understand the whole process and they turn into a "dud developer" no matter how otherwise intelligent they are.

(And what's with down-voting the parent? It's a fair point even if I'm not in agreement)

Cool. What's the site?

The fact that anyone at any point can monkey patch any built-in is a potential liability for large teams, with average programmers. It must be addressed by culture and code review that you may or may not have.

Still worth it though :)

I've never bought the idea that the opposite is a better trade off because it comes with costs too. Have you ever worked with a bunch of mediocre java programers? Heaven forbid they make an interface that isn't well thought out and needs to be changed later!

That extreme is also terrible. Python is somewhere in between.

if ruby is an extreme to the left, and java an extreme to the right, then python is also extreme to the left. The difference between python and ruby in dynamicity is really small.

Python is not in the middle of ruby and java. Python is virtually on top of ruby.

A fair point. Maybe 'optimum' would be a more useful concept here than 'centre'... I see Python's position on the dynamicity (ugh) spectrum is in line with it's philosophy on readability.

(On a side note - your definition of 'extreme' rather depends on what outliers you have. I do love it when the US media refers to the Democrats as 'left of center' ;)

yup, republican and java are in the same camp ;)

On a serious note, I've been doing ruby as my job for about 5 years and I work at a giant corporation with a few hundred programmers. In those 5 years I've never been bitten by someone changing a core class that breaks my code. Maybe 3 times I've been bitten by someone changing a non core class, and it usually takes me about an hour or two to resolve it.

So that's maybe 6 hours in 5 years where I've lost time due to this, but the amount of time it has saved me is far larger than this.

That sounds like an interesting big Ruby gig that would be a good story to tell the anti-dynamic languages FUD brigade.

You should blog :)

In what situation is it actually a good idea to employ a large number of bad programmers, rather than a small number of good ones? We shouldn't be making trade-offs for the sake of bad ideas ;)

There's a distinction to be made between preventing risky behaviour and relying only on a programmer's good judgement to avoid mistakes. Even if your team is solely good programmers there's a lot to be said for discouraging unsafe behaviour by default since anyone can have a bad day, distraction, etc.

I view this situation as somewhat analogous to having guards on power tools: even a highly skilled operator doesn't want to rely on always doing something perfectly.

The nice thing about code is that (when version controlled) all mistakes can be fixed retroactively. As long as two programmers aren't having a bad day at once, pairing will catch "all" errors. As long as all your programmers aren't having a bad day at once, code review will catch "all" errors again. ;)

This is why you need to automate peer review http://www.parasoft.com

...and all it takes is one rogue or bad programmer to mess up the code base.

...in either scenario. During code review, however, I'd expect that the good programmers would reach much more strongly to the rogue commits than the mediocre programmers would.

Are there many ruby app built by large teams?

In my experience, teams building Ruby apps tend to be much smaller than teams building Java apps ..

That said, this is a problem for any libraries that you might want to include, you have to trust that the authors followed conventions and didn't do any thing 'evil'. Ruby Rewrite (http://rewrite.rubyforge.org/) was conceived to specifically avoid this sort of problem.

The best software is built by small teams.

Both languages offer the unvigilant programmer plenty of opportuities to shoot off his foot. If you're really concerned about this you should take a look at scala. I'm amazed at how much easier it is for me to maintain my own scala code than either ruby or python.

and so much harder for me to maintain someone else's scala code. It feels like statically typed perl, but that's just mho.

It is possible to write very cryptic scala code. Mine isn't, but neither was my perl.

At least with version 2.7, I actually really enjoyed looking at the Scala standard library code when the documentation wasn't sufficient for my needs. That's no knock on the scala documentation either, as I frequently look at the JDK standard library source code too. I've also had a couple of similarly positive experiences digging around the Lift code.

What other "someone else's" Scala code have you actually had to look at and maintain that you had problems with? In my experience, I only have a hard time understanding Scala code when it is doing something I'm conceptually unfamiliar with, usually something in the functional world that I know little or nothing about.

it's been a while so I don't remember the specifics but it was code for dealing with json in a lift code base.

Yea, you can make scala look like haskell, java, or perl with relative ease. Up for debate whether thats a good thing or not.

My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp.

In regards to monkey-patching, while I'm not a Ruby programmer by any means, I sorely feel its absence in other languages. It's in JavaScript (expando objects as well as being able to override and overwrite built-in methods of existing types), and to some extent available in C# (extension methods are a sort-of expando object, but there is very little ability to overwrite a method). Like operator overloading, sure, don't build a project completely off of it (I'm looking at you, C++'s iostream), but when you need it, damn you need it. I'm still delving into Python (late to the party, whatever), but I definitely use Python in much more of a tinkering fashion, so monkey-patching is something I would desire in the language.

My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp.

I don't entirely disagree with the larger sentiments, but I worry about the tone of the word 'tinker'. That is, the Ruby world is full of playful characters, and often displays a spirit that is far from corporate. However, many Ruby (and RoR) apps are also serious businesses at this point. There are also many libraries that don't charge money, do exhibit that playful or exuberant spirit, but also provide hard-core real-world functionality (e.g., Nokogiri).

tl;dr The word 'tinker' is a bit trivializing (perhaps unintentionally on Martelli's part). The division between 'tinker' and 'enterprise' doesn't fully or properly cut up the problem space. It's a binary view of a multi-faceted world.

(For whatever it's worth, this is my view as someone on the outside of this whole situation. I use Ruby and Perl about equally, primarily for systems administration and personal projects.)

I agree completely. I tend to dislike the phrase "enterprise development" anyway, because it implies that somehow our programming is suddenly different just because a company uses it. But, I try to write for my audience.

Eh. Most of my work (not all) is done within the confines of a company. There are some dramatically different ideas when you're writing something to be used WITHIN a company than when you're writing something to be used BY a company.

Most of it makes sense, or seems obvious, but your SAAS companies don't typically offer Active Directory (or LDAP) integration, as most companies aren't willing to expose their directories outside of their firewalls.

Auditing levels tend to be more paranoid, and need to be structured so that they can be fed into (or are at least sane enough to be read by) the industry-standard log analysis tools.

Admin accounts are typically transitioned to in-house users, or employees of the company, instead of being managed by the man behind the curtain (you).

So, perhaps it's that my experience is different than the majority of HN here, but to me, 'enterprise development' is a dramatically different process than what those guys at 37Signals do, for example.

C# (by .NET 4) now has real expando objects, if you really need them. It uses what they call the Dynamic Language Runtime: http://msdn.microsoft.com/en-us/library/system.dynamic.expan...

If only there was a tool to fix core objects that were tinkered with. Something like... wait. Monkey patching!

But seriously, at his Q&A session on EuRuKo 2010 Matz mentioned that monkey patching issues are going to be addressed in Ruby 2.0. http://nuclearsquid.com/writings/euruko-day2.html

As I recall, Python actually has even more detailed meta-programming abilities if you look around in it; in Python but not Ruby, a function can scan up the calling stack and determine the name a caller used for an object that the function was passed (which sounds crazy but could be nice for a DSL).

It's just that Python hasn't ever had an ethos of monkey-patching.

If you want to know about Monkey patching visit the Smalltalk community. They've been doing it a lot longer.

About point 2: the author is probably ignorant of ast module (http://docs.python.org/library/ast.html), which allows the programmer to take any ast and recompile it to anything he/she wants (in runtime, unlike Lisp macros, but alike parse tree and ruby2ruby in ruby).

This feature allows you to transform things like "1, minute" into "Minute(1)", enabling dsls, and "wrecking havoc" all over. In ruby, you don't have to do this, as there are simpler and less powerful metaprogramming tools.

So yeah. Just because you have a shotgun, it doesn't mean you can't use it to kill a fly. Of course, the really important question is not if you can, but if you should. And it is always better that this decision is left for the users of the language than to its creators.

So "the author" is Alex Martelli, a long-time Python user, contributor, and winner of the 2006 Frank Willison award which is given each year for outstanding contribution to the Python community.

I highly doubt he's "ignorant" of anything when it comes to Python...

A better theory is this article is from 2003, but the ast module was added in Python 2.6, which was released in 2008.

(I agree with everything you've said in the second and third paragraphs, but, man, try to give people a little credit before you assume they're ignorant, 'k?)

Thanks for the info. I was ignorant of the author and post date.

I seriously did not want to imply (the incorrect fact) that the author was ignorant in general, but of a single matter (which is kinda unknown, so I'd expect most be to be oblivious to it).

I am equaly sorry for the bad choice of words...

It takes efforts to write a simple Transformer using ast. Along the way of making one, your instinct will tell you that doing so is a bad idea, probably.

In Ruby, meta-programming is always powerful and always so easy to use. I don't have problem using these methods, but it pains me when some crappy monkey-patching-flavored gem (For example, cache-money) decided to bite me intermittently.

Or when debugging the code of some kick-ass-ninja-rockstar programmer where he decided to generate methods using both class_eval and instance_eval (along the way, generating the "def statements" using string interpolation) inside a module that supposed to be injected into ActiveRecord object.

I do agree with your last paragraph completely. The real ninja is capable of stopping himself from beheading anyone he sees just because he can.

Re 2): With great power comes great responsibility.