hi!
Just in case someone do not seen this yet.
http://groups.google.com/group/RubyDOTNET/browse_thread/thread/1752830c857620b0
regards,
Slavo.
I’ve justed posted a few comments here:
http://www.sapphiresteel.com/The-End-Of-Ruby-NET
I think this is sad but inevitable. The fact of the matter is (in our
opinion, anyway) that the DLR truly is the way forward for dynamic
languages on .NET. We’ve only started looking seriously into the DLR
quite recently and suffice to say we are mightily impressed by what
we’ve seen. Dr Kelly and his team did great work on Ruby .NET but
ultimately I think the advent of the DLR just changed everything.
best wishes
Huw C.
SapphireSteel Software
Ruby and Rails In Visual Studio
http://www.sapphiresteel.com
I don’t find it all that sad, the Ruby.NET folks did some awesome
stuff, now they can come over and do awesome stuff in IronRuby 
On Feb 5, 2008 5:42 AM, Huw C. [email protected] wrote:
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
–
Michael L.
[Polymath Programmer]
http://michaeldotnet.blogspot.com
On Feb 5, 2008 2:16 PM, Michael L. [email protected]
wrote:
I don’t find it all that sad, the Ruby.NET folks did some awesome
stuff, now they can come over and do awesome stuff in IronRuby
This might be an old topic, but does the IronRuby project intend to
allow Ruby code to be written as a “first class” .Net language
Meaning, that like Ruby.Net can we write .Net classes in Ruby rather
than writing them as strings that are passed to the RubyEngine?
I had expected that having to do that was just a function of the
“newness” of IronRuby, not a design decision.
But wanted to check
–
Greg A.
Software Development Manager
SSI Services
http://kc.vanadium.com
http://www.pghcodingdojo.org
http://www.insomnia-consulting.org/monologue
C# is looking into making it easy to talk with DLR objects. See
On Feb 5, 2008 12:31 PM, Greg A. [email protected] wrote:
Meaning, that like Ruby.Net can we write .Net classes in Ruby rather
than writing them as strings that are passed to the RubyEngine?
There’s a kind of mismatch between the capabilities of statically
defined types (as in the CLR) and the dynamic classes that Ruby
offers. What should happen to the corresponding CLR class if, for
instance, someone were to dynamically add methods to the Ruby class?
CLR classes don’t support that kind of operation.
The best option in this regard is probably to allow a dynamic (Ruby or
other DLR) class to be delegated to by a statically-defined wrapper.
Conceptually, such a wrapper could be automatically generated from the
Ruby class definition, but once defined it would be unalterable.
–
Curt H.
[email protected]
I just posted a follow-up on my blog:
http://www.iunknown.com/2008/02/welcome-wayne-k.html
Thanks again Wayne for all your work on Ruby.net and gppg, and we look
forward to seeing more of you on our list!
-John
While this is really cool, it doesn’t (for instance) let you expose a
dynamic object to WCF without manually wrapping it in a static C# class
or any other CLR feature based on method, property or class-level
attributes.
Did I mention that this is really really cool? 
Yup, we still need to tackle attributes. Attributes are tricky to fit
into a dynamic language. It can be done, but it definitely has issues.
Another approach is to have attribute-based features exposed via other
mechanisms as well (for eg. an imperative API). Dynamic languages could
then build libraries on top of those APIs that worked well with the
paradigms of that particular dynamic language.
Given the existing set of attribute-based features, we will have to
think about this more. In the meantime, there is a workaround of using a
statically typed language just for the part which requires attributes.
From: [email protected]
[mailto:[email protected]] On Behalf Of Curt
Hagenlocher
Sent: Tuesday, February 05, 2008 2:58 PM
To: [email protected]
Subject: Re: [Ironruby-core] Access from static languages
While this is really cool, it doesn’t (for instance) let you expose a
dynamic object to WCF without manually wrapping it in a static C# class
– or any other CLR feature based on method, property or class-level
attributes.
Did I mention that this is really really cool?
On Feb 5, 2008 2:30 PM, Shri B.
<[email protected]mailto:[email protected]> wrote:
C# is looking into making it easy to talk with DLR objects. See
On Tue, 05 Feb 2008 13:43:14 -0700, Curt H.
[email protected] wrote:
On Feb 5, 2008 12:31 PM, Greg A. [email protected] wrote:
Meaning, that like Ruby.Net can we write .Net classes in Ruby rather
than writing them as strings that are passed to the RubyEngine?There’s a kind of mismatch between the capabilities of statically
defined types (as in the CLR) and the dynamic classes that Ruby
offers. What should happen to the corresponding CLR class if, for
instance, someone were to dynamically add methods to the Ruby class?
CLR classes don’t support that kind of operation.
I’m not sure this can really be applied to the notion of statically
compiling Ruby code into a language agnostic .NET assembly. People who
want static compilation of Ruby code don’t look at it from the stand
point
of “I want the best of both the dynamic and static worlds” and instead
“I
want to write this library in Ruby because it’s easier.” or “I would
like
to use this Ruby library inside of my C# code.” or “etc.”. There’s an
obvious tradeoff: If you compile the code statically you lose the
benefits
that come along for the dynamic ride. But that’s a tradeoff I believe
some folks are willing to make. It doesn’t always make sense to go this
direction, and in some cases it may not even work as one might expect.
But again, that’s the tradeoff you have to be willing to make and it
seems
to me there are enough people who are willing to make it and therefore
interested in the capability.
The best option in this regard is probably to allow a dynamic (Ruby or
other DLR) class to be delegated to by a statically-defined wrapper.
Conceptually, such a wrapper could be automatically generated from the
Ruby class definition, but once defined it would be unalterable.
I think this is taking things a little too far. If you want the
advantages of a dynamic language, use a dynamic language coupled with
it’s
dynamic language runtime counterpart. If you’re simply interested in
using Ruby code as if it were a statically compiled language then
statically compile the code and then, as you point out,
once defined it would be unalterable.
–
/M:D
M. David P.
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: [email protected] | [email protected]
Mobile: (206) 418-9027
http://3rdandUrban.com | http://amp.fm |
http://www.oreillynet.com/pub/au/2354
On Mon, 04 Feb 2008 21:21:07 -0700, M. David P.
[email protected] wrote:
Expect an extended follow-up from me tomorrow.
It can be difficult to make a clean separation between what truly
matters
in life and what does not, a fact that can be easily seen if you were to
grab an iPhone out of an iPhone owners hands, throw it to the ground,
and
stomp it into itty bitty pieces. I’ve been writing code since I was 11
and
over the course of the 25 years that have since followed I have come to
understand the fact that the software projects we develop can quickly
become very much like our own children.
That may sound silly, but the truth of the matter is that we, as humans,
tend to attach our emotions to things that really don’t matter all that
much. As software developers the code we write can very easily become a
part of who we are, a fact easily seen at a tech conference while we
watch
the presenters gush over PowerPoint presentations as if they were
pictures
of their own children (We’ve all done it, so that’s not a statement of
exclusivity.) For Dr. Kelly and Professor Gough to have created such a
fantastically wonderful project to then make the determination that it
was
time to turn their attention elsewhere says a lot about their character,
a
decision I believe they should be commended for making.
I think it’s important to consider the fact that when it comes down to
it,
Dr. Kelly and Professor Gough are both computer scientists AND
educators
at heart. As both their jobs require them to keep an open mind and a
finger on the pulse of the industry. I have no doubt in my mind that
their decision to forego continued involvement with the Ruby.NET project
to instead work with the IronRuby team was both difficult and painful.
But
ultimately they had to do what was right for not only themselves but for
the students that look to them for guidance and direction as to where
they
should place the focus of their studies. As Dr. Kelly mentioned, the
DLR
and IronRuby are here and here to stay. It’s important that the CS
students of the world understand this and the best way to understand
these
two important projects is to roll up their sleeves and get their hands
dirty.
That doesn’t mean that the Ruby.NET project should just fold up and die.
It simply means it was the right decision for them to make, a decision
that, quite obviously, was not an easy decision to make for either of
them.
So then, where from here?
I believe that Ruby.NET is an important project for many reasons, first
and foremost because it works, works well, and works now. That said,
IronRuby and in particular the DLR has completely changed the game for
dynamic languages on the .NET platform. We all know that, so there’s no
point in pretending this is not the case. Ignoring this fact will come
back to haunt any dynamic language project targeted towards the .NET
platform.
Relating this to Ruby.NET, the answer as to whether or not the Ruby.NET
project should live on, in my own opinion, is to focus on the fact that
Ruby.NET works right now and can act as the perfect foundation for .NET
developers interested in getting their feet wet with Ruby and for Ruby
developers interested in getting their feet wet with the .NET platform
to
do just that. In this regard I see Ruby.NET as a way to start this
process sooner rather than later while at the same time helping to
expose
where the pain points are such that IronRuby can be a better overall
project as a result.
But there’s more to it than that.
As Ted Neward specified,
I still believe that there is room in the world for both a
statically-compiled Ruby and a dynamically-interpreted Ruby on the CLR.
One of the most commonly asked questions on the IronPython development
list – IronPython as we all know being the basis of what brought about
the DLR – is “Can I write my libraries in Python and then call those
libraries in my C# or VB.NET code?” While the answer is a bit more
complicated than this, for the most part the answer is “Probably not.”
This is one area of the DLR that both the IronPython and IronRuby teams
have specified would be nice to have, but at present time is a non-goal
for the 1.0 release of the DLR and the projects based on that release.
In this regard there is a clean separation between what Ruby.NET can
offer
the .NET developer right now and what IronRuby will not offer the
.NET
developer in the near term future. As such this is one area that I
believe
should be the core focus of the Ruby.NET project moving forward. But
not
from the standpoint of creating a competitive Ruby language project for
the .NET platform – that would be silly and prideful – and instead
from
the standpoint of merging the focus of the two projects together in such
a
way that interop between the two code bases is seamless. In other
words,
and in my own opinion, the purpose of the Ruby.NET project moving
forward
should not be one of being a separate project with a separate focus
and
instead,
- a stepping stone for the Ruby language on the .NET platform that Ruby
and .NET developers alike can use to get started with Ruby development
for
the .NET platform right now. - a way that someone can take the same code base they write for
IronRuby
and compile that code into a static and reusable assembly that is
portable
and reusable inside of any CLI-compliant language.
I don’t think it was by any strange coincidence that when Dr. Kelly
created this project on Google Code he chose rubydotnetcompiler as the
project name, as ultimately that’s what this project is all about.
Ultimately and eventually it may turn out that the IronRuby and DLR
teams
decide to enable static compilation. And maybe they won’t, deciding
instead to focus their time on making the dynamic nature of dynamic
languages that much more dynamic than would otherwise be the case.
In the mean time, however, there’s the Ruby .NET compiler project, a
project in which I believe should follow the direct path of the IronRuby
team, making it possible to take code targeted for IronRuby, statically
compile that code, and reuse the static assembly within any other .NET
code project. To me, anyway, this is an area of great desire with the
.NET development communities and as such the perfect focus for moving
this
project forward.
Thoughts from the communities at large?
–
/M:D
M. David P.
Co-Founder & Chief Architect, 3rd&Urban, LLC
Email: [email protected] | [email protected]
Mobile: (206) 418-9027
http://3rdandUrban.com | http://amp.fm |
http://www.oreillynet.com/pub/au/2354