Why IronRuby?

Ruby IronRuby
1

Hi,

I was thinking about why to use IronRuby and one of the things that came
to my mind is because of better gems like spec, cucumber etc. Mostly my
use of IronRuby is around unit testing .NET CLR frameworks. But then
.NET CLR implementations is catching up with all these tools like
specflow and (.NET implementation for cucumber not sure about the name).

RAKE is awesome but usually I just use sh to execute shell scripts and
perform the build. Currently, I am not interacting RAKE with .NET
assemblies so it is pure Ruby implementation.

So, what do you think? Where would you use IronRuby?

2

I have been using it the last couple months for building out a
Silverlight app and have found a lot less friction coding WPF with
IronRuby as opposed to XAML and C#.

Randall

3

This question keeps coming back :slight_smile:

Testing is a great use of IronRuby, maybe even the top reason for .NET
guys
to use it. However, there are more reasons for .NET guys to adopt
IronRuby
like:

  • Writing internal tools.
  • Make it possible to extend .NET applications using IronRuby.
  • Using IronRuby’s REPL capabilities for quick POCs or to enhance
    current
    .NET applications.
  • Silverlight and Gestalt development
  • Writing DSLs
  • Running Ruby on Rails on IIS “natively” (this one is not so much for
    the
    .NET developer, but it’s a great reason too :slight_smile: ).

All in all, it will be tremendously hard to convince C#/VB.Net guys to
work
with IronRuby. Moreover, it’ll be twice as hard until VS fully supports
the
language.
Having said that, I do believe that as time goes by the walls will
collapse
and IronRuby will become a common tool among .NET devs.

Shay.

Shay F. | .NET Technologies Expert | Author of IronRuby Unleashed
|
Sela Technology Center
Blog: http://IronShay.com | Twitter: http://twitter.com/ironshay

4

Amen to that :smiley:

5

A while back I really thought testing would be the largest use case,
but it went differently - here are my current real use cases:

  • faster UI development (windows forms)
  • interop with solutions already built on Ruby (see my previous
    message on Resque)
  • Excel templating (things like embedding IR into spreadsheet, somehow)
  • Silverlight (games or apps)

– Thibaut

6

On Tue, Jan 26, 2010 at 10:35 AM, Shay F.
[email protected]wrote:

This question keeps coming back :slight_smile:

Testing is a great use of IronRuby, maybe even the top reason for .NET guys
to use it. However, there are more reasons for .NET guys to adopt IronRuby
like:

I agree with that. :-/

  • Make it possible to extend .NET applications using IronRuby.

This one is a big one. (Think emacs-lisp but using Ruby in any app.)

  • Using IronRuby’s REPL capabilities for quick POCs or to enhance current
    .NET applications.

If things go the way they did for Michael F. with IronPython at
Resolver
Systems, those POCs may turn into real apps as developers realize that
IronRuby is plenty fast for their scenario.

I would further add that many Ruby libraries, or at least those that are
written in pure Ruby, may prove better or more useful than similar
libraries
in C#. The same goes for IronPython. In particular, I’m interested in
MongoMapper for Ruby or Dee-python for data access. Writing some of
these in
C# is just a pain and are cost inefficient.

Ryan R.

Email: [email protected]
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

7

The productivity increase vs programming in a language like C# is a big
one
too :slight_smile:

So why ironruby and not ruby?
if you’re a .NET shop you probably already have a serious investment in
libraries, control suites and so on.
With IronRuby you don’t lose anything you can reuse those items but
still
get the productivity increase.

As it so happens I tend to disagree that the rails stuff isn’t for .NET
people
What I’m seeing is that Rails is the primary reason people look at
IronRuby.

For example I’m currently doing a 40 day coaching job at a company that
is
evaluating asp.net mvc and Rails.
IMO and I’m fairly confident I know what’s in the asp.net mvc framework,
it
still has a looooooooong way to go before it can get anywhere near what
rails has to offer you. It would involve adding even more ruby/python
features to C# (at some point they should then rename it to ironC or
something).

I have a chuckle every time I see a C# dev create a viewmodel or use
stuff
like:

var myVariable = new MyGiantGeneric<MethodImplementations,
ProperyImplementations, IAmAnInterface, IAmToo>();

When they say strong typed view, that’s just plain funny because it’s
correct but also wrong at the same time what they really mean to say is
statically typed view, but anyways.
It basically boils down to do you want to deal with this typing nonsense
or
do you want to deal with it more intelligently (at a performance cost).

When this coaching job is over I do a 4 day training course at another
company on: Ruby/Rails + .NET, RSpec and testing best practices (or what
to
test).
So in my opinion there is a keen interest for something more mature to
take
over.

As you may know I’ve implemented ironruby mvc, because I assumed that’s
what
.NET people would be interested in.
There is 1 good use case for it if you have an existing asp.net mvc app
otherwise I don’t really see the point of using asp.net mvc for example
and
having to deal with generics and all other CLR nonsense.

  • everything shay said.

PS: If I get the the sqlserver stuff to work with ActiveRecord properly
I
definitely want to do a datamapper adapter so I don’t have to deal with
ActiveRecord and its inconsistencies or actually writing sql

Met vriendelijke groeten - Best regards - Salutations
Ivan Porto C.
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

8

I’m currently using IronRuby to do automated UI testing using the WPF UI
Automation framework. IronRuby is working out brilliantly, the WPF UI
automation framework on the other hand is “sub par”, but that’s another
story.

Have also used it for many ad-hoc tasks such as exploring .NET api’s,
transforming data files, connecting to SQL server to poke around, and so
forth.

9

Along a lot of these ideas, I have written a small app which I use to
file bugs on Codeplex. The source is at
GitHub - jredville/cp_bugger: A repl for working with Codeplex bugs.. I bring it up now because it
fills some of these points:

  •     Internal: it's not internal since it is open source, but it is

a custom toom

  •     Extending .NET applications: I wrap the TFS api's to make them

more friendly and adjust the complexities of TFS to the relative
simplicity of Codeplex.

  •     REPL: Used the repl a lot during the development of this. I

plan on adding a repl mode to this, and I might make IRB the base of
that repl.

  •      SL: Not here ;)

  •     DSLs: Yep, I made a command DSL that makes creating commands

relatively easy

  •     IIS: Not here :)

This app would have been possible via screen scraping or Ruby.NET, but
it was amazingly simple to build using IronRuby. It’s also really
useful, and has very little todo with testing.

JD

From: [email protected]
[mailto:[email protected]] On Behalf Of Shay F.
Sent: Tuesday, January 26, 2010 8:35 AM
To: [email protected]
Subject: Re: [Ironruby-core] Why IronRuby?

This question keeps coming back :slight_smile:

Testing is a great use of IronRuby, maybe even the top reason for .NET
guys to use it. However, there are more reasons for .NET guys to adopt
IronRuby like:

  • Writing internal tools.
  • Make it possible to extend .NET applications using IronRuby.
  • Using IronRuby’s REPL capabilities for quick POCs or to enhance
    current .NET applications.
  • Silverlight and Gestalt development
  • Writing DSLs
  • Running Ruby on Rails on IIS “natively” (this one is not so much for
    the .NET developer, but it’s a great reason too :slight_smile: ).

All in all, it will be tremendously hard to convince C#/VB.Net guys to
work with IronRuby. Moreover, it’ll be twice as hard until VS fully
supports the language.
Having said that, I do believe that as time goes by the walls will
collapse and IronRuby will become a common tool among .NET devs.

Shay.

Shay F. | .NET Technologies Expert | Author of IronRuby Unleashed
| Sela Technology Center
Blog: http://IronShay.com | Twitter: http://twitter.com/ironshay

On Tue, Jan 26, 2010 at 6:13 PM, Mohammad A.
<[email protected]mailto:[email protected]> wrote:
Hi,

I was thinking about why to use IronRuby and one of the things that came
to my mind is because of better gems like spec, cucumber etc. Mostly my
use of IronRuby is around unit testing .NET CLR frameworks. But then
.NET CLR implementations is catching up with all these tools like
specflow and (.NET implementation for cucumber not sure about the name).

RAKE is awesome but usually I just use sh to execute shell scripts and
perform the build. Currently, I am not interacting RAKE with .NET
assemblies so it is pure Ruby implementation.

So, what do you think? Where would you use IronRuby?

Posted via http://www.ruby-forum.com/.

10

There’s nothing stopping you from using Blend to generate XAML, and
loading it from IronRuby. The tutorial app in the IronRuby samples
directory was built like that. You’re right that AttachedProperties
won’t work today, but if you really want to use XAML and Ruby together,
you can have guidelines for your designers on what blend features they
can use, or have some way of converting what they write to Ruby.

~Jimmy

From: [email protected]
[mailto:[email protected]] On Behalf Of Miguel Madero
Sent: Tuesday, January 26, 2010 10:08 PM
To: [email protected]
Subject: Re: [Ironruby-core] Why IronRuby?

I’ve been willing to try it with Silverlight Apps, I know it has a lot
of potential and I’m thinking of IR as full replacement of C#. Binding
doesn’t work for dynamic objects which is a big showstopper (although I
know there’re ways around it, I’ve not had a chance to get aroudn that).
I see a lot of application frameworks that would be better implemented
on a real dynamic language. People is struggling to fix some C#
limitations with weird things like TypeDescriptors, DynamicProxies, AOP,
Code Generation, etc.

However, the lack of support from tools like the Visual Studio Designer
and Blend is another showstopper. I’m happy to handcode my XAML or even
add elements from ruby code, but for bigger proejects we might have a
designer working in Blend, creating controls in XAML, probably even
using Attached Properties, this are all things that won’t work ATM with
IronRuby so we have to fault back to a statically type language to
define this. So we gain productivity in some areasb, but loose it in
others, I guess for some apps we would end up with a mixed approach, but
I would ike to use IR as the main language and C# for those thigns that
I can’t do in IR and not the otherway around.

11

I’ve been willing to try it with Silverlight Apps, I know it has a lot
of
potential and I’m thinking of IR as full replacement of C#. Binding
doesn’t
work for dynamic objects which is a big showstopper (although I know
there’re ways around it, I’ve not had a chance to get aroudn that). I
see a
lot of application frameworks that would be better implemented on a real
dynamic language. People is struggling to fix some C# limitations with
weird
things like TypeDescriptors, DynamicProxies, AOP, Code Generation, etc.

However, the lack of support from tools like the Visual Studio Designer
and
Blend is another showstopper. I’m happy to handcode my XAML or even add
elements from ruby code, but for bigger proejects we might have a
designer
working in Blend, creating controls in XAML, probably even using
Attached
Properties, this are all things that won’t work ATM with IronRuby so we
have
to fault back to a statically type language to define this. So we gain
productivity in some areasb, but loose it in others, I guess for some
apps
we would end up with a mixed approach, but I would ike to use IR as the
main
language and C# for those thigns that I can’t do in IR and not the
otherway around.

12

Jimmy,

I know I can consume XAML from Ruby, what doesn’t work is the other way
around, create and set properties of Ruby objects from XAML

About converting what they have to ruby, sounds like a tough task, they
tend
to generate the ugliest XAML, certainly something that can be automated,
but
that’s not the issue. The problem is that we need to create some custom
controls, converters, behaviors, attached properties, etc, in code and
they
won’t be able to consume it from XAML so they woudl be limited to using
“assets” created in C# (or we would have to create wrappers for our IR
implementations).
Now that I think about it, it might not be that hard to generate the
wrappers for our IR objects, sounds simple at least for things like
Converters where we only care about the interface.

On Wed, Jan 27, 2010 at 5:48 PM, Jimmy S. <