hi! Just in case someone do not seen this yet. http://groups.google.com/group/RubyDOTNET/browse_thread/thread/1752830c857620b0 regards, Slavo. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080205/400a426c/attachment.html
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 Collingbourne SapphireSteel Software Ruby and Rails In Visual Studio http://www.sapphiresteel.com -- Posted via http://www.ruby-forum.com/.
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
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 Collingbourne <lists at ruby-forum.com> wrote:> 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 Collingbourne > > SapphireSteel Software > Ruby and Rails In Visual Studio > http://www.sapphiresteel.com > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-- Michael Letterle [Polymath Programmer] http://michaeldotnet.blogspot.com
On Feb 5, 2008 2:16 PM, Michael Letterle <michael.letterle at gmail.com> 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 Akins Software Development Manager SSI Services http://kc.vanadium.com http://www.pghcodingdojo.org http://www.insomnia-consulting.org/monologue
On Feb 5, 2008 12:31 PM, Greg Akins <angrygreg at gmail.com> 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 Hagenlocher curt at hagenlocher.org
C# is looking into making it easy to talk with DLR objects. See http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Curt Hagenlocher Sent: Tuesday, February 05, 2008 12:43 PM To: gakins at insomnia-consulting.org; ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] The future of Ruby.NET On Feb 5, 2008 12:31 PM, Greg Akins <angrygreg at gmail.com> 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 Hagenlocher curt at hagenlocher.org _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
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 Borde <Shri.Borde at microsoft.com> wrote:> C# is looking into making it easy to talk with DLR objects. See > http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Curt Hagenlocher > Sent: Tuesday, February 05, 2008 12:43 PM > To: gakins at insomnia-consulting.org; ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] The future of Ruby.NET > > On Feb 5, 2008 12:31 PM, Greg Akins <angrygreg at gmail.com> 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 Hagenlocher > curt at hagenlocher.org > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080205/ceb8c109/attachment-0001.html
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Curt Hagenlocher Sent: Tuesday, February 05, 2008 2:58 PM To: ironruby-core at rubyforge.org 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 Borde <Shri.Borde at microsoft.com<mailto:Shri.Borde at microsoft.com>> wrote: C# is looking into making it easy to talk with DLR objects. See http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx -----Original Message----- From: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org> [mailto:ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of Curt Hagenlocher Sent: Tuesday, February 05, 2008 12:43 PM To: gakins at insomnia-consulting.org<mailto:gakins at insomnia-consulting.org>; ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org> Subject: Re: [Ironruby-core] The future of Ruby.NET On Feb 5, 2008 12:31 PM, Greg Akins <angrygreg at gmail.com<mailto:angrygreg at gmail.com>> 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 Hagenlocher curt at hagenlocher.org<mailto:curt at hagenlocher.org> _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org> http://rubyforge.org/mailman/listinfo/ironruby-core -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080205/8d6a5255/attachment-0001.html
On Mon, 04 Feb 2008 21:21:07 -0700, M. David Peterson <xmlhacker at gmail.com> 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, 1) 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*. 2) 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 Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 418-9027 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
On Tue, 05 Feb 2008 13:43:14 -0700, Curt Hagenlocher <curt at hagenlocher.org> wrote:> On Feb 5, 2008 12:31 PM, Greg Akins <angrygreg at gmail.com> 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 Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david at 3rdandUrban.com | m.david at amp.fm Mobile: (206) 418-9027 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354