Why Would a .NET Programmer Learn Ruby on Rails?
Very well written and thoughtful article by Stephen Chu up at InfoQ.
To be fair, I still think .NET is great. It has offered me a place where I am consistently delivering great business value to my clients. However, I constantly remind myself that there are multiple ways and numerous technologies to solving a single problem, some better than others. By being loyal to one technology stack, I am bound to unconsciously make biased decisions, which will ultimately hinder my ability to deliver business value.
Here's some choice tidbits, emphasis mine:
There are a few hurdles I had to go through in learning Ruby. First, I had to go through the emotions of accepting the fact that it will take longer to find a new Ruby solution than to use an existing technology that I am comfortable in. This is by far the most painful experience. But, after a while, you will start cherishing the fact that you are starting to develop multiple ways to solving different problems, and that’s where the pleasure comes in. Secondly, reading about Ruby/Rails only gets me so far. Practically using what I have learned helps me to remember what I have learned. Remember, use it or lose what you have invested time to read about.
This article says, better than I could, why .NET folks should look at Rails. If you're resistant to change (or installing things) try Instant Rails. If you refuse to install anything, and still want to Try Ruby, then try it directly in your browser.
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
He also has a good video of it in action here: http://www.wekeroad.com/actionpackintro.html
It provides an ActiveRecord pattern for .NET that works with all of the built-in .NET and ASP.NET features as well (GridView, Master Pages, Security). Best of both worlds.
Ruby on Rails is flat *awesome* for this type of prototyping. I'm not saying it is a prototype only language, or that you cant do real applications with it. Since the data access, form ui and some display bits are generated/reflected, you can do this type of prototyping very quickly and with very few changes in code. Once things stabalize you can then switch it to .net starting with a fully baked database.
the link to INstantRails -- about:instantrails.rubyforge.org/
it should instead be http://instantrails.rubyforge.org/wiki/wiki.pl
Learning and sharing the knowledge, that's my brain food.
I have been struggling with a very complex web app for almost two years (ugh). I found myself circumventing the Page Life Cycle in ASP.NET often. I began dreaming about "alternative" ways to build Web apps in .NET. At the same time, I was increasingly influence by Patterns. When I explored RoR I discovered that it was the same sort of thing that I had been thinking of. In the end this led me to the Castle Project and MonoRail. For those of you who don't know, MonoRail is essentially a port of Rails to the .NET framework.
Honestly, I don't see what the fuss is all about with Ruby? More than likely... 900% of the attraction is the ActiveRecord pattern included in the ActionPack. Have you ever slapped a profiler on your app and seen the number of SQL calls made during the rendering of a non-simplistic web page? We could argue this to death, but I think Rails developers are creating a number of non-scalable sites (sure they work good when 1 user is testing them on a development machine) and fooling themselves in the process.
Let's face it... most developers don't like writing data access code... but there's no such thing as a free lunch.
The emporer wears new clothes.
That said... there is a bunch I do like about Ruby (the language) and bits of Rails that have influenced how I write my ASP.NET, Classic ASP and PHP applications.
Just my humble opinion. Love your blog!
Hopefully, Jon Lam and co will be able to accomplish the same feats that the IronPython team has and we'll be able to write DSLs using Ruby within our .NET application frameworks.
RoR does one thing, builds a web application. If I have a team of developers it doesn't make sense to say "we are going to use RoR for web stuff" but .Net for winform apps, web services, threaded applications, etc. We are under deadlines and cost our company money to re-invent ourselves in a new platform. If developers want to learn things on their own time that's fine but at the end of the day the Enterprise needs to be able to move people from team to team to work on various projects and RoR only does one thing so the value add of even looking at it in the Enterprise is pointless compared to the value of having one platform that can do ANYTHING whereby you can move people around as projects need it.
The title should read: "If you are a consultant, you may want to explore Ruby on Rails to have more technolgies to land more business."
Comments are closed.
However, there are only so many hours in a day and I find being expert in .NET consumes all my time. By broadening my focus to include other unrelated technologies I would lose depth by necessity.
Jack of all trades -> expert in none.
Is there a balance to strike?