Ruby Is The Future(enfranchisedmind.com) |
Ruby Is The Future(enfranchisedmind.com) |
"... later upgrades to the library don’t need to be re-fixed: the one-time patch will automatically get re-applied by application code automatically!"
Anyone who fails to realize how monkey-patching can and will break both subtly and catastrophically across library upgrades has no business advising anyone regarding language choices.
[Edit] I hate April Fool's Day. Depressingly, the author's satire is so subtly aligned with common arguments as to so thoroughly fool.
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...
"There needs to be a special term for an attempt at an April Fool's Day Joke, which is in all of its points true and then ends up looking like a joke made by an author at his own expense."
http://www.reddit.com/r/ruby/comments/8966h/ruby_is_the_futu...
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.
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.
It's not luck, simply put, it's not hard to fix well written software.
I have very few issues with Ruby as a language, in general it let's me get from thought to working code quicker than any other language I've used. Honestly the largest issues I've run into with Ruby typically deal with people trying to be too clever.
Ruby certainly provides a lot of ways for people who want to look incredibly clever to hang themselves and anyone using their code. I typically avoid libraries or frameworks where clever code is the norm (I'm looking at you Rails), and because of this I tend not to have too many problems.
It's certainly not perfect, and I've been frustrated by bad error messages, stupid type system mistakes, etc. But I've found that those issues simply replace issues in other languages.
I still feel that Ruby gets me from Thought to Code quicker, and for the kind of projects I typically do, that's worth dodging a couple of warts.
I agree with you about Thought-to-Code and even though I argued in favor of monkey patching earlier, the willingness to use it without discipline has raised a red flag for me and is the biggest sign of this "too cleverness" that you're referring to (at least for me). If Ruby becomes the new Java, maintaining irresponsibly monkey patched legacy systems could be a nightmare for the enterprise developer in the years to come.
What I do miss are good, well documented, stable libraries. For example, I currently process RSS/Atom feeds with FeedTools, whose own creator says he's tired of maintaining (I totally understand him and am extremely thankful for the time he put into it). I assume if there were more people coding Ruby, there would be a better chance someone would step up and take his place. So, having a community that is more welcoming to newcomers would eventually benefit us all.
By "open to newcomers" I don't mean that Ruby-celebs should stop posting snarky comments at each other in their blogs. This is pretty negilible. I mean stuff like having better documentation, for example, online, free, in googleable format (rather than screencasts or print books). IMHO PHP3 annotated online docs back in 1999 were significantly more usable than what Rails has to offer now.
Is it more the fact that the community is small or that fewer people share their code than in the Python community? Just wondering.
Do you mean for the core language? Are you not happy with http://www.ruby-doc.org/ ?
http://ruby-doc.org/q/<your search string>Here again I think it's interesting to compare to PHP's annotated docs ca. 2000, which were a great resource since they usually contained a few common usage examples for every function. The language itself was less consistent and mature than Ruby, but the user contributed (pre-Web 2.0! ;)) docs made up for it.
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.
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.
1.upto(10).each{|x| print x}
I'm curious - how would you print 1 through 10 in C# 3 by comparison?
(1).UpTo(10).ForEach(x => Console.WriteLine(x));
Of course, "UpTo" requires first extending int, which is trivial: public static class IntExtensions {
public static List<int> UpTo(this int start, int end) {
var range = new List<int>();
for(int i = start; i < end; i++) {
range.Add(i);
}
return range;
}
} def print[T] (value:T) = System.out.println(value)
1.until(10).foreach(x => print x)
This is a fairly uninteresting example, however. Something more interesting would be, for instance, the use of structural types to implement type-checked duck typing.Scala example:
// Declare a structural type for any class implementing close()
type Closable = {def close(): Any}
// Executes the provided function with the given
// closable generator, creating a new instance which
// will then be closed on completion. The provided
// function's value will be returned.
def withClosable[T, C <: Closable] (c: => C) (f: (C) => T) = {
val closable = c
try {
f(closable)
} finally {
closable.close
}
}
// Example usage
def usage = {
val updated = withClosable(db.openConnection) { conn =>
conn.update("INSERT INTO example VALUES (...")
}
System.out.println("Rows updated: " + updated)
}
This could be compared with Python's new 'with' syntax. 1 to 10 foreach println
Which seems more concise than the equivalent Ruby to me. Feh. for i in range(1,11): print i
Python FTW? ;) for x in range(1, 10): print xBTW another example that comes to mind regarding beginner-friendliness is how long it took to get Rails working with Apache. Before Phusion you were supposed to run your own mongrel cluster or similar fringe solutions - it was insane to ignore the world's most widely installed server. Personally I only started considering Rails production-worthy after mod_rails turned out to be fast and stable. Sure, I can run Thin/nginx or whatever, but I don't want to learn a new server (and wait for it to mature) just so I can use Rails.
I don't like Rails, but I hate Apache.
It seems to me most Rails jobs are either for companies who chose Ruby because they really know their stuff, which is great, or companies who chose Rails because 2 years ago it was touted as some sort of Web app pixie dust in Wired Magazine, which is often less fun :)
p *1..10
Edit: you may need to do a "require 'pp'" first.I recommend watching it. Good talk. Takeaway point - always err on the side of charging too much :)