[ansin]

Just because it's a satire doesn't mean the title in incorrect. I would argue that Ruby is, in fact, the future for the same reason that Python is the future.

As for monkey patching, yes, it's ill-advised in general just as global scope and gotos are ill-advised for similar reasons. However, monkey patching is a powerful feature if used responsibly as Chad Fowler has noted ("The Virtues of Monkey Patching"):

http://chadfowler.com/index.cgi/Computing/Programming/Ruby/T...

Now admittedly, not every programmer is as competent or responsible as Chad Fowler or the programming world would be a very different place but the point is there's a right way and a wrong way to do it.

Werner Schuster's article on InfoQ ("Ruby's Open Classes - Or: How Not To Patch Like A Monkey") has more good advice on how to do it the right way:

http://www.infoq.com/articles/ruby-open-classes-monkeypatchi...

[ankhmoop]

As noted in Werner Schuster's article, many languages (such as C# or Scala) do support type-safe, non-ambiguous, non-conflicting extension of existing classes, demonstrating that extension of existing classes can be safely implemented and does not require the use of dangerous monkey-patching.

[jshen]

dealing with the type system in scala can be a pain and is a hit to productivity in the early stages. The question is if the hit in the early stages leads to more productivity in the later stages. I'm not convinced that it does.

I've done a lot of ruby, and I've had monkey patching bite me a few times. However, fixing the problem was never that hard (two days max) and is clearly overshadowed by the productivity gained from the power ruby gave my teams.

[ankhmoop]

How can one effectively argue against an entirely subjective judgment of difficulty in terms of dealing with a type system?

Anecdotally, I find that leveraging functional language programming features coupled with type inference and polymorphism leads to considerable productivity gains as code correctness can be ensured through judicious use of types -- without requiring extensive testing or programmer effort -- while excess verbosity can be eliminated through the use of FP features such as type-safe anonymous functions, currying, etc.

[ansin]

How do you deal with excess verbosity in C#? I know this is a separate argument from the monkey patching issue but for me the conciseness and elegance of the Ruby syntax versus C# is the primary reason to choose Ruby.

[ankhmoop]

Hopefully a user of C# will chime in -- I've spent very little time with it, and only recently evaluated C#'s extension mechanism for the purpose of comparing it against other language's implementations.

That said, elegant and concise syntax does not require eschewing an internally consistent, fully specified type system -- the two are not incompatible, as demonstrated (subjectively) -- by many existing FP languages. I argue that elegance/conciseness requires either FP language features and advanced type system, or abandonment of rigorous typing.

[SamReidHughes_]

Which version of C# are you thinking of?

In C# 3, the verbosity level is much less than in C# 2, where it's slightly less than C# 1.

I don't see where Ruby syntax is particularly more concise than C# 3's.

Well, let me clarify "particularly". I don't find myself feeling like I'm suffering under C#'s syntax, relative to Haskell's. It has about the same amount of syntactic overhead: writing types for method parameters, and when defining data structures. Occasionally I have to explicitly write a type parameter to a function.

[ansin]

"I don't see where Ruby syntax is particularly more concise than C# 3's."

1.upto(10).each{|x| print x}

I'm curious - how would you print 1 through 10 in C# 3 by comparison?

[jhancock]

I find monkeypatching happens because the framework doesn't utilize proper baseline OO techniques. By "baseline" I'm excluding mixins. I have rarely found a case where mixins do a better job over well factored inheritance. I don't think mixins are "evil". Just over utilized and inheritance heavily underutilized in Ruby.

[ansin]

You're lucky that in those cases you were able to recover in only two days. The time it takes to get back on track can be proportional to the size of the project so imagine if you were dealing with an enterprise system written in and monkey patched in Ruby and you had a similar problem. Depending on your luck, you might get back on track or you might end up having a lot of extra time to work on your resume.

[jshen]

I do work for a very large enterprise. Monkeypatching isn't something that is used liberally, but it's the right thing in certain circumstances.

It's not luck, simply put, it's not hard to fix well written software.