Ruby.NET | The Coffeehouse

jmacdonagh

With all the focus lately on Ruby on Rails, I found this to be rather interesting.

Ruby.NET

Not just some Ruby interpreter written in .NET, this is a standalone compiler for Ruby into MSIL.

EDIT: :o

We wish to thank:

Microsoft for their technical and financial support of this project.

Rossj

leeappdalecom wrote:

Have you looked at the .Net MVC Framework you use C# there and I don't see what difference is, it's still the MVC pattern?

Not Microsoft's, but I had a play with Promesh. Still sits on the ASPNet pipeline though.

leeappdalecom wrote:

I know the flexibity of dynamic languages has it's place and can result in some nice clean code but strong typing also has it's place.

I agree wholeheartedly, but it is the flexibility of Ruby and its idioms that provides the speed (of development) rather than the runtime performance. It depends what you think is important at any given time.

Escamillo

Nice find. Thanks for posting this. Smiley

I'll still go with F#, though. Wink

davidofmorris

There is also IronRuby: http://www.wilcob.com/Wilco/IronRuby.aspx

jb43081

A co-worker of mine demoed this for us a while back. It was interesting... but not compelling.

ben2004uk

I have downloaded it and had a play.

But only thing which gets me with this Python and Ruby - why would you want to develop it using this instread of C#.

I admitted - ever completed a program in it. but the only reason I would be tempted to is for Unix platforms - and it seems that having it built on .net takes that away.

So could someone please tell me a reason to use this? I am interested in the application of such dynamic languages......

Cool tho Smiley

Cairo
I want my waffle sundae, give me my carbs!

ben2004uk wrote:

But only thing which gets me with this Python and Ruby - why would you want to develop it using this instread of C#.

Because Ruby and Python are nicer languages than Java/C#. Smiley

They're a better fit for "agile" development than Java/C#. Dynamic typing and reduced scaffolding work make them more productive languages. Plus, you can do some lambda-calculus kinds of things with them that simply aren't possible (or are left-handed and/or inefficient) in static compiled languages like Java/C#.

Of course, I don't know if the CLR ports of Ruby and Python retain the dynamic aspects of those languages. Do they? And how -- and how's the performance?

jmacdonagh

Cairo wrote:

ben2004uk wrote:

But only thing which gets me with this Python and Ruby - why would you want to develop it using this instread of C#.

Because Ruby and Python are nicer languages than Java/C#. They're a better fit for "agile" development than Java/C#. Dynamic typing and reduced scaffolding work make them more productive languages. Plus, you can do some lambda-calculus kinds of things with them that simply aren't possible (or are left-handed and/or inefficient) in static compiled languages like Java/C#.

Of course, I don't know if the CLR ports of Ruby and Python retain the dynamic aspects of those languages. Do they? And how -- and how's the performance?

They're shooting for 100% CLR compliance and trying to reduce any performance bottlenecks to begin with. Considering that Ruby is interpretted normally anyway, I think any workaround code that goes into the compiled version won't make too much of a difference.

Jaykul

ben2004uk wrote:
But only thing which gets me with this Python and Ruby - why would you want to develop it using this instread of C#.

Joel Spolsky said it best: Can Your Language Do This?
The answer is in the ammount of code it takes to write MapReduce in C# (or Java, for that matter), and in how hideously complex it is, compared to languages with better support for anonymous (lambda) functions and functions as arguments.

Andrew Davey
www.aboutcode.net

LINQ will have extension methods to IEnumerable<T> that allow you to map (ConvertAll) and reduce (Fold). This gives C#3.0 some very powerful functional-style programming capabilities.

Sven Groot
My name has 9 letters. Coincidence? I think not...

It's not as if map and reduce are particularly hard to write in C# 2.0 either with anonymous delegates and generics. The only added lines of code over the javascript version in that "can your language do this" article are the delegate declarations.

public delegate T MapDelegate<T>(T input);
public delegate T ReduceDelegate<T>(T aggregate, T input);

public static void Map<T>(IList<T> list, MapDelegate<T> function)
{
   for( int x = 0; x < list.Count; ++x )
      list[x] = function(list[x]);
}

public static T Reduce<T>(IEnumerable<T> list, T initial, ReduceDelegate<T> function)
{
   T aggregate = initial;
   foreach( T item in list )
      aggregate = function(aggregate, item);

   return aggregate;
}

public static void Foo()
{
   List<int> list = new List<int>();
   list.Add(1);
   list.Add(2);
   list.Add(3);

   Map(list, delegate(int x) { return x * 2; });
   int sum = Reduce(list, 0, delegate(int aggregate, int input) { return aggregate + input; });
}

See, not all that more difficult than in javascript. Smiley

littleguru
<3 Seattle

Sven Groot wrote:
It's not as if map and reduce are particularly hard to write in C# 2.0 either with anonymous delegates and generics. The only added lines of code over the javascript version in that "can your language do this" article are the delegate declarations.

Great work. I like your implementation Sven.

Sven Groot
My name has 9 letters. Coincidence? I think not...

For reduce it's not even necessary for the aggregate type to be the same as the type used by the list. Want to concatenate a list of integers together as a string? You can!

public delegate TAggregate ReduceDelegate<TAggregate, TInput>(TAggregate aggregate, TInput input);

public static TAggregate Reduce<TAggregate, TInput>(IEnumerable<TInput> list, TAggregate initial, ReduceDelegate<TAggregate, TInput> function)
{
   TAggregate aggregate = initial;
   foreach( TInput item in list )
      aggregate = function(aggregate, item);

   return aggregate;
}

public static void Foo()
{
   List<int> list = new List<int>();
   list.Add(1);
   list.Add(2);
   list.Add(3);

   string concat = Reduce(list, "", delegate(string aggregate, int input) { return aggregate + input.ToString(); });
}

The result will be "123". Smiley

EDIT:
Prefer to do the concatenation with a stringbuilder? Also possible:

string concat = Reduce(list, new StringBuilder(), delegate(StringBuilder aggregate, int input) { return aggregate.Append(input.ToString()); }).ToString();

Big Smile

Sven Groot
My name has 9 letters. Coincidence? I think not...

It just occurred to me that you can use a combination of anonymous delegates and the List<T>.ForEach method to achieve the Reduce effect as well:

int sum = 0;
list.ForEach(delegate(int x) { sum += x; });

It's the anonymous delegates that make this possible because they can access the variables of their defining function. Smiley

jmacdonagh

Sven Groot wrote:
It just occurred to me that you can use a combination of anonymous delegates and the List<T>.ForEach method to achieve the Reduce effect as well:

int sum = 0;
list.ForEach(delegate(int x) { sum += x; });

It's the anonymous delegates that make this possible because they can access the variables of their defining function.

Yeah actually I just found this out a few days ago. It's really a neat feature.

staceyw
Before C# there was darkness...

Sven Groot wrote:
It just occurred to me that you can use a combination of anonymous delegates and the List<T>.ForEach method to achieve the Reduce effect as well:

int sum = 0;
list.ForEach(delegate(int x) { sum += x; });

It's the anonymous delegates that make this possible because they can access the variables of their defining function.

In 3.0 you could also use a lambda like:

int sum = 0;
list.ForEach(i => sum += i);

or use:
int sum = list.Sum();

JChung2006

Looking ahead to ParallelFx though, these reduce implementations make the sum variable a synchronization hotspot though. If we folded functions and were able to combine partial results together as they were being evaluated or defer combination when appropriate, we could potentially increase parallelism. Combinators.

blowdart
Peek-a-boo

Cairo wrote:

Because Ruby and Python are nicer languages than Java/C#. They're a better fit for "agile" development than Java/C#. Dynamic typing and reduced scaffolding work make them more productive languages.

Isn't the scaffolding and ORM stuff part of Rails, rather than Ruby? I know these days everyone seems to merge the two.

Rossj

blowdart wrote:

Isn't the scaffolding and ORM stuff part of Rails, rather than Ruby? I know these days everyone seems to merge the two.

Yes, but Rails is only what it is because of the features available in Ruby - the power isn't just in the Rails framework, it is in the Ruby language.

I gather (but haven't tried) that the other scripting MVC frameworks benefit from the flexibility of their respective languages too, to varying degrees.

leeappdalecom
.nettter

Rossj wrote:

blowdart wrote:
Isn't the scaffolding and ORM stuff part of Rails, rather than Ruby? I know these days everyone seems to merge the two.

Yes, but Rails is only what it is because of the features available in Ruby - the power isn't just in the Rails framework, it is in the Ruby language.

I gather (but haven't tried) that the other scripting MVC frameworks benefit from the flexibility of their respective languages too, to varying degrees.

Have you looked at the .Net MVC Framework you use C# there and I don't see what difference is, it's still the MVC pattern?

I know the flexibity of dynamic languages has it's place and can result in some nice clean code but strong typing also has it's place.

Stebet
Buuuurrrritoooo!

Sven Groot wrote:
It just occurred to me that you can use a combination of anonymous delegates and the List<T>.ForEach method to achieve the Reduce effect as well:

int sum = 0;
list.ForEach(delegate(int x) { sum += x; });

It's the anonymous delegates that make this possible because they can access the variables of their defining function.

Also, take a look at the Action Generic Delegate Smiley

http://msdn2.microsoft.com/en-us/library/018hxwa8.aspx

Ray6

Rossj wrote:

blowdart wrote:
Isn't the scaffolding and ORM stuff part of Rails, rather than Ruby? I know these days everyone seems to merge the two.

Yes, but Rails is only what it is because of the features available in Ruby - the power isn't just in the Rails framework, it is in the Ruby language.

I gather (but haven't tried) that the other scripting MVC frameworks benefit from the flexibility of their respective languages too, to varying degrees.

Groovy and Grails for example.

Lots of ideas lifted straight from RoR, but with the advantage of the wealth of Java frameworks.

Ray6

Rossj wrote:

I agree wholeheartedly, but it is the flexibility of Ruby and its idioms that provides the speed (of development) rather than the runtime performance. It depends what you think is important at any given time.

... or what becomes painfully important later ...

Rossj

Ray6 wrote:

Rossj wrote:

I agree wholeheartedly, but it is the flexibility of Ruby and its idioms that provides the speed (of development) rather than the runtime performance. It depends what you think is important at any given time.

... or what becomes painfully important later ...

Too true, I told you my WPF story didn't I? Wink

You can't always predict what is going to be needed in the future though and you can only hedge your bets so much.

Ion Todirel
buuu

Rossj wrote:
...I told you my WPF story didn't I?

nope