@robconnery I’m really glad that you are excited. I think anytime someone is healthily and safely passionate about something, it can only be a good thing.
Rob has a great post where he lists 4 cases where he likes Ruby and compares to the same thing in C#. Case 1 Expressiveness: Rob likes the unless statement and the post expression if statement. Case 2: Rob likes Gems. Case 3: Rob likes simple things. Case 4: Rob likes sending messages, open classes and method missing.
Python and Perl already did all this, so why Ruby?
Case 1 and 3 were true in python when i started writing it in 1996 and case 1, 2 and 3 were true in perl when i started writing it in 2000. I’m sure case4 is true in both python and perl too, but I never went that deep into either of them. Much like in Ruby, you don’t have to go that deep to get things done.
I am of the opinion that if you have never seen a dynamic typed language before, or maybe a dynamic typed language other that BASIC or VB before, that Ruby has all of the appeal which you tout. However, there are some of us who write C# because we actually like it, we write desktop applications, and find it to be the best static and strong typed language around. We came to C# and were super impressed because the weak typing of C wasn’t there. The rough edges of C++ wasn’t there and for nearly all applications there is no performance difference and sometimes the GC and managed environment actually gives a boost in performance over some of the bad C++ we were writing before.
So should someone who has never written in Perl, Python, Pike and PHP go try out Ruby… absolutely… get the exposure.
Alternatively, if you have done some Perl or Python and now you are a C# guy. Ruby might not seem so impressive. In fact, it looks more like the same thing with a new coat. I can’t tell what the hype is about. There isn’t much new and different.
All that said, after years of Perl, learning C# was a challenge, especially since I was using it to solve many of the same problems for which I had been using Perl. WHY? was I doing it that way? Well I wanted Windows Forms UI front ends on my Perl versions of programs there were ultimately just sed/awk/grep and some ldapsearch/ldapadd/ldapmodify commands. Not commands really, but calls to libraries.
There is a good reason that the “simple things” aren’t AS simple.
What I learned was that there is a damned good reason that Case 3 “The Simple Things” were a little more complex in C#. The separation of stream and textreader abstract types in C# make huge sense once you realize that doing the same thing in perl or python (or ruby) can be a bit of a hassle. The organization of decorator streams in the .NET BCL just makes sense. Want to compress? Decorate with the stream compressing class. Want to encrypted? Decorate with the stream encrypting class. Want to do both? In either order? Decorate appropriately.
I do share Rob’s opinion. It is a little prettier in Ruby. I’ve already gone on record as saying that “var” in C# should be optional. In VB6 the Let statement was optional. In VB.NET the Let statement is no supported. IMO C#’s var isn’t much different than VB.NET’s Let and Dim. Sure would be nice if it were optional.
I’ve also requested static imports so that we could do things like just call the open method instead of saying File.Open. When you are in a nice tiny singly responsible file, it just makes sense.
These things don’t change my ability to write code.
On .NET’s lack of a CPAN, Cheeseshop, Gem equivalent: YES! YES! YES WE NEED IT NOW!
I can’t say anything other than .net needs CNAN (comprehensive .net archive network) or maybe CCAN (comprehensive CIL archive network). I can’t decide which name I like better.
As for metaprogramming, I think that Python, Perl and Ruby’s ability for runtime metaprogramming will continue to be far beyond anything you see in the C# world. That is not say that metaprogramming is not possible in C#. Its just very different. Its typically compile time metaprogramming. Thanks to the addition of T4 in VS2008 and 2010, metaprogramming in C# is readily available and powerful.
I could go on and insert above about how I learned to love the .NET RegularExpression API after having it blow my mind in comparison to perl’s. Or about how poorly documented the System.DirectoryServices API is, but that once I got it I loved it so much more than Net::LDAP. Or about the extreme pain in building CPAN modules on a Sun Sparc and how installing Mono and using Visual Studio and C# was actually easier than making Perl work properly.
But rather than elaborate on those things, I’ll end by saying, yes, Ruby is awesome, if you have never seen any of the things which make it awesome before.
Have you tried out IronPython yet? Microsoft has put together a plugin for VS2010 that works pretty well. http://ironpython.net/tools/
@Ben
Sure, IronRuby is awesome, but that doesn’t change any of the above argument 🙂
It’s a bit of a shameless plug (I have contributed to this project), but in relation to the CNAN/CCAN, I have a friend who’s put together Refix (might be just the tonic). http://refix.codeplex.com
Refix is more of a Maven’esque type of deal, but the concept is the same. Local, corporate and global repositories are all possible.
The pleasure of perl was learning all those secret handshakes. The pleasure of python is that there is a “right” way to do things. The pleasure of ruby is that when you wonder if something works a certain way, it probably does. The pleasure of Ruby on Rails is that it lets you “think a website” and make it so.
The pleasure of C# is that you can build industrial-strength applications for Windows, web, cloud, RIA, phone, etc., reusing knowledge across all those different platforms and knowing that you’ll be able to do whatever you want to do. I could also argue that the pleasure of C# (or VB.NET) is simply Visual Studio … I love the .NET development environment.
All these languages have their strengths. What amazes me is that the language writers clearly keep observing and learning from one another. Static languages add dynamic (and functional) features. Dynamic languages add better development environments, intellisense-like features, and production support.
If I need to rip some knowledge from a few text documents, I’ll probably still reach for perl, because the regex support is so natural. But if I need to add similar support into a production app, I’ll figure out the slightly tougher syntax to do it in C#. Conversely, if I’m going to create a service-oriented app, I’m going to reach for C#/WCF … but I have to admit it’s pretty cool that I can consume those services using perl or python or ruby (with appropriate bindings, of course).
I think I’m agreeing with you … but I also appreciate how the alternatives encourage people to look at similar problems in different ways. For example, you’re argument for “var” being optional comes from your experience in VB … though you choose to use C# instead of VB, there are places where you still want C# to be more “VB-like” … I think that exploring and celebrating those differences is what moves all the languages forward.
Nice post.
P