[morelinq-dev] Controversial question

[Jon Skeet]

This is going to be highly controversial, but... I wonder whether MoreLINQ actually has much of a role now.

You see, I think most (if not all) of what we've got is also in Reactive Extensions in System.Interactive.

That's great - because it means it may be part of the framework in the future. As far as I can see, MoreLINQ has one advantage - it's a much smaller download for anyone who happens to want just a single operator. Oh, and being open source means anyone can have a peek, of course.

So, what future does MoreLINQ have if any? Should we keep developing (not that I've done anything for ages), mothball it, delete the project (I'd rather not do that) or what?

Jon 

--
You received this message because you are subscribed to the Google Groups "MoreLINQ Developers" group.
To post to this group, send email to moreli...@googlegroups.com.
To unsubscribe from this group, send email to morelinq-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/morelinq-dev?hl=en.

[Johannes Rudolph]

Hi all,

MoreLINQ certainly lost traction and we don't have that many users (roughly 350 downloads). I like seeing most of MoreLINQs ideas resembled in System.Interactive. As one could expect from Microsoft Research, they definitely put a lot of thought into it and their extensions are very consistent. This is definitely a big bonus for someone new to the topic. I haven't used System.Interactive so far, but I have read Bart De Smet's great blog post series on it, so please take everything I say about Rx with a grain of salt.

There is no sense in pursuing an open source alternative to their implementation, there's probably not much we could do better or more efficient. Another aspect is that I think there's only a limited demand for the operator extensions both projects provide.

Besides the .ToDataTable() operator, which I use heavily, my involvement with MoreLINQ has been driven by the desire to explore sequence operations using functional idioms. It's just exciting to see the clean abstraction that's going on when implementing a sequence operator.

Given the competition from Microsoft Research is closed source, I see MoreLINQ as a great way to learn about sequence operator implementation, how they do work, how primitives can be leveraged to compose other operators etc. 

As a conclusion, there are two roles I can imagine MoreLINQ would fit very well:

1. Educational purposes. (Like: How do I implement a xxx-like Sequence operator?)
2. "Personal playground" to explore implementation strategies, "cool" operators etc.

Kind regards,

Johannes

[Jon Skeet]

Those both seem like entirely reasonable motives for keeping MoreLINQ around :)

I suggest we explicitly "deprecate" the project and point to System.Interactive as an alternative - while keeping the project around and adding things to it as we see fit. We just don't need to worry so much about releases etc :)

Jon

[Johannes Rudolph]

I fully agree, you're the one with the right permissions to edit our landing page ;-)

Our codebase is in a pretty good shape (high test coverage, good and consistent documentation), we should try keeping our quality standards as they are. And yes, binary releases are probably not that much interesting, especially since our build process is really easy.

There are two things I forgot about in my last mail:

• Mono (Sup)port: That might be a good case for MoreLinq, I don't know if System.Interactive has licensing or technical issues with Mono. 
• Migrate MoreLINQ repo to Mercurial? This would make tracking our "experimental" operators easier, it's a pain in svn.

[Jon Skeet]

On 26 April 2010 17:23, Johannes Rudolph <jojo.r...@googlemail.com> wrote:

I fully agree, you're the one with the right permissions to edit our landing page ;-)

Yes, shame I have no time ;) I'll get round to it at some point...

 

Our codebase is in a pretty good shape (high test coverage, good and consistent documentation), we should try keeping our quality standards as they are. And yes, binary releases are probably not that much interesting, especially since our build process is really easy.

There are two things I forgot about in my last mail:

• Mono (Sup)port: That might be a good case for MoreLinq, I don't know if System.Interactive has licensing or technical issues with Mono. 

Currently Reactive Extensions is only available as a Windows installer file. I believe that the DLLs work with Mono after extraction though. But hey, MoreLINQ is certainly a smaller dependency :) 

• Migrate MoreLINQ repo to Mercurial? This would make tracking our "experimental" operators easier, it's a pain in svn.

I'd be very happy to do that -  partly because it would be a good project to practice on before I do the same to my Protocol Buffers port at some point...

Does anyone object to me pressing the button?

Jon

[Johannes Rudolph]

Just want to share two links on that topic:

This is the official hg wiki on that topic. It does not only deal with history conversion (our scenario) but also with interoperability scenarios. There are a variety of extension or third party scripts that make migrations possible.

Google officially recommends using the convert extensions.

[Jon Skeet]

Odd - I'd thought there was a server-side conversion tool.

I doubt that I'll get time to do this any time in the immediate future, but prod me again if I haven't done it in a month :)

Jon