Forum: IronRuby Why IronRuby?

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?

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

This question keeps coming back :)

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 :-) ).

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 Friedman | .NET Technologies Expert | Author of IronRuby Unleashed 
|
Sela Technology Center
Blog: http://IronShay.com | Twitter: http://twitter.com/ironshay

Amen to that :D

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

On Tue, Jan 26, 2010 at 10:35 AM, Shay Friedman 
<shay.friedman@gmail.com>wrote:

> This question keeps coming back :)
>
> 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 Foord 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 Riley

Email: ryan.riley@panesofglass.org
LinkedIn: http://www.linkedin.com/in/ryanriley
Blog: http://wizardsofsmart.net/
Twitter: @panesofglass
Website: http://panesofglass.org/

Along a lot of these ideas, I have written a small app which I use to 
file bugs on Codeplex. The source is at 
http://github.com/jredville/cp_bugger. 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: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Shay Friedman
Sent: Tuesday, January 26, 2010 8:35 AM
To: ironruby-core@rubyforge.org
Subject: Re: [Ironruby-core] Why IronRuby?

This question keeps coming back :)

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 :-) ).

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 Friedman | .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 Azam 
<lists@ruby-forum.com<mailto:lists@ruby-forum.com>> 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/.

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

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 Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)

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.

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.

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: ironruby-core-bounces@rubyforge.org 
[mailto:ironruby-core-bounces@rubyforge.org] On Behalf Of Miguel Madero
Sent: Tuesday, January 26, 2010 10:08 PM
To: ironruby-core@rubyforge.org
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.

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 Schementi <