# Why use IronRuby **URL:** \ **Category:** IronRuby\ **Created:** [November 11, 2009, 7:24pm UTC](https://www.ruby-forum.com/t/why-use-ironruby/178815 "2009-11-11T19:24:00Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Patrick\_Brown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/e9a140/32.png) [@Patrick\_Brown](https://www.ruby-forum.com/u/Patrick_Brown)\ **Post date:** [November 11, 2009, 7:24pm UTC](https://www.ruby-forum.com/t/why-use-ironruby/178815/1 "2009-11-11T19:24:00Z")
Hello I have been playing with IronRuby 0.9.2 for a week or so and I have to say that it is alot of fun to tinker with, I am having alot of trouble trying to figure out where I would really use this though besides maybe in writing scripts to do little things or to help out with builds. My development is all desktop Client/Server code. I see people mention testing and rapid development, I think I can actually develop a fair bit quicker given current tools. I really am interested in working this in if I can see some areas that it would be helpful. Thanks, Patrick ---
**Author:** ![Patrick\_Brown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/e9a140/32.png) [@Patrick\_Brown](https://www.ruby-forum.com/u/Patrick_Brown)\ **Post date:** [November 11, 2009, 8:42pm UTC](https://www.ruby-forum.com/t/why-use-ironruby/178815/2 "2009-11-11T20:42:27Z")
It’s probably too early to start building full client/server projects using IronRuby, though I am confident the day will come when WPF development is primarily accomplished using DLR languages and frameworks. Our shop is also heavily client/server, still using mostly Windows Forms, and the major potential for IronRuby to add value to our existing products falls into five categories: - ``` Dev / Build Automation ``` - ``` Testing (primarily BDD style, in my opinion) ``` You say you don’t see much added value in using IronRuby in these scenarios, but I would challenge you to do some real world proof of concepts. I think you will eventually find the flexibility and dynamic nature of Ruby blows the standard .NET tooling out of the water from a productivity perspective. These kinds of tasks are inherently prone to constant flux and change and are best built in rapid iterations, and having a dynamic/interpreted language optimized for simplicity is of immense value. - ``` Adding end user customizations / scripting / event handlers to ``` the front end OR back end Eventually, you may want to allow your customers (or even your dev team) to be able to react in custom ways to domain events occurring in your applications. A dynamic language is perfect for this. - ``` API / Integration ``` Chances are your applications react to and generate a number of business events, or domain events. It is likely that at some point, if not already, your users will want your applications to integrate with other systems. Your applications may also be required to communicate with humans, via automated e-mails, sending SMS messages, etc. Giving your application servers the ability to prepare some event data related to each domain event and pass it off to dynamically discoverable Ruby scripts/handlers when these events occur gives your application tremendous flexibility to easily integrate with almost any system or platform at the drop of a hat. If you have a customer that wants to call a partners web service when something happens in their workflow, you just write a script for it. If the partners system is archaic and watches the files system for dropped files, you can generate that file in a few lines of Ruby too. Maybe your customers have IT departments? They can write their own scripts. As for integrating incoming data into your application, Ruby is also very good at transforming incoming data structures or DTO’s into your domain objects, as you can react to changes in partner services without having to do a full, versioned deployment process on your clients and servers. Finally - ``` Runtime (remote) access to application state via IronRuby REPL ``` Being a dynamic, interpreted environment, you can easily put together a REPL, or interactive console, that can be launched within the process of your desktop clients or your servers (via command line) that can allow your operations people to dynamically probe the running state if those processes. This can be quite useful in certain troubleshooting or tech support scenarios. By making this shell environment available remotely (by integrating with a .NET SSH server, for instance, there is one on codeplex, will take some work but I’ll have a library out soon to help) you can make your application externally scriptable for your operations department from any location, even an iphone (which has many SSH apps) The main point is that any place in your project that is likely to be customized on a per-deployment basis, or is likely to change in business time, which is a must faster rate of change than any infrastructure code you have, is a very good candidate for using a dynamic language, DLR and IronRuby. Given that IronRuby can easily call into any static .NET DLL’s, you lose nothing and gain the flexibility to allow your application able to morph to meet new business conditions (particularly at the interface of your application and the rest of the world) very rapidly. From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Patrick Brown Sent: Wednesday, November 11, 2009 10:17 AM To: removed\_email\_address@domain.invalid Subject: [Ironruby-core] why use IronRuby Hello I have been playing with IronRuby 0.9.2 for a week or so and I have to say that it is alot of fun to tinker with, I am having alot of trouble trying to figure out where I would really use this though besides maybe in writing scripts to do little things or to help out with builds. My development is all desktop Client/Server code. I see people mention testing and rapid development, I think I can actually develop a fair bit quicker given current tools. I really am interested in working this in if I can see some areas that it would be helpful. Thanks, Patrick ---
**Author:** ![Patrick\_Brown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/e9a140/32.png) [@Patrick\_Brown](https://www.ruby-forum.com/u/Patrick_Brown)\ **Post date:** [November 12, 2009, 5:54am UTC](https://www.ruby-forum.com/t/why-use-ironruby/178815/3 "2009-11-12T05:54:59Z")
As an experiment, I’d suggest pick a toy client-server problem. Try building out your server as a Rails app that has no human consumable view and only exposes REST resources (ok, Rails resources aren’t very RESTful, but that’s another story altogether). Build your client using standard C# if it’s a desktop app or silverlight, or build another Rails app as the client if it’s going to be a website. Stick with TDD the whole way on all components and keep your build green all the time (this is important if you’re looking to experience a productivity boost). This should give you a reasonably good idea about what you can expect and the tradeoffs that you make with Ruby. It will be even better if you can find an experienced Ruby hacker to pair with over the course of the exercise, preferably one who is familiar with .Net. > I would really use this though besides maybe in writing scripts to do > little things or to help out with builds. > Absolutely! I swear by Rake, it’s fabulous as a build language and > hammers ant/nant in terms of ease of use and longer term > maintainability, especially on larger codebases which tend to have many > stages in the build. There are several projects on multiple platforms > (including .Net, Cocoa, Java and of course Ruby) that have discarded > their traditional build scripts to move to Rake. > I think I can actually develop a fair bit quicker given current tools. > The catch with writing Ruby is that most of the dev tools are part of > the OS. It’s been a few years since I used a serious IDE (IntelliJ) but > IDEs are primarily valuable for their magnificent support for > Refactoring. These days I use TextMate with a bunch shell scripts which > give me everything except the Refactoring (which I sorely miss, I can > tell you). On Windows, you’re rather stuck when it comes Ruby dev > tooling (at least for now). In my experience, at least to begin with you > can do with IronRuby what most people do with JRuby - develop on > Ubuntu/OSX using the MRI and deploy onto IronRuby on Windows. You get > the developer productivity boost associated with any \*nix based OS and > the ability to finally deploy onto Windows. You’ll need to watch out for > gem dependencies though, since only the pure Ruby ones will be > automatically available on IronRuby. Best, Sidu. > **[Electric Sheep Blog](http://blog.sidu.in)** > > On hacking and startups by Sidu Ponnappa [http://twitter.com/ponnappa](http://twitter.com/ponnappa)