I hope this does not come across to negative, definitely a nice project, but is this really useful in practice? If you want F# or Haskell syntax, why not just use F# or Haskell? Why bent C# until it looks like something that already exists? If you work together with (pure) C# developers, you will just confuse them. If you work together with Haskell or F# developers, you can just use that languages.
If this is just a fun project, scratch what I said, I love building useless stuff myself, but if it is intended to be used seriously I don't get the point.
I'm involved with a 9 year old C# project, it has seen almost every version of C#. When generics turned up that was nice, then LINQ, very nice, etc, etc. I like to see how far I can bend the language in general, but that wasn't the main driver.
Over the past few years I've done some Haskell and also we've started creating satellite projects around our core project that are developed in F#. F# has been great to work with, and I love how a few key language decisions can make whole classes of bugs disappear. It's frustrating to run back into those bugs when returning to C#.
It's great to see the direction that C# is going in, it's clearly going toward a more centrist position midway between OO and functional. But a few key things won't go away, ever. null for example, won't ever leave the language. Mutable first won't either. And because of this I'm always trying to think of ways of removing those classes of bugs that hurt the most.
This library is currently just a pet weekend project (so it's exactly 5 days old at the moment). But I would like to take it further if there's enough interest. As I say in the introduction, I know it won't sit well with plenty of people, and that's fine.
> Why bent C# until it looks like something that already exists?
Because in the industry at large, JVM == Java and .NET == VB.NET == C#.
So bending Java, C# and C++ to have features from OCaml, F#, Haskell... is the only way many of us can ever aspire to do FP at work.
For example, on my case we always use the software stack that is already in place and used by the customer IT. It is expected that the software gets built with the said tools.
Our organization (big C# codebase, newer apps in scala) has doubled down on extremely functional C# (using the NICTA XShapx library which has a lot of overlap with this one). It's been a tremendous help. C#'s linq comprehension makes it one of the most powerful languages doing functional style (w\ Haskell and then scala at the top).
Since LINQ supports any monad and with extension methods, you can write a lot of pure, concurrent/parallel code with minimal fuss. This has mainly been helpful from a testing perspective, since the majority of our logic is 'pure', we can run more tests without having to set up test DBs/Webservers, etc.
How is C# at all "programmable"? Even all the neat C# features, like async or duck typing are hard-coded into the language and not extensible or generic.
Yes I remember the days when you edited a line by using the arrow key to go up then copying character by character, then edit the bits you want as you go along. Or something like that. Magic!
It took me a while before I realised you could do that. Before that I would type the whole thing out again. When I realised you could copy parts of the line my mind was blown! Ah.. those were good days..
I was a big proponent of functional C# and even started writing s book on it, back in 2008. But my final conclusion is that C# is ultimately too clumsy and verbose to really work with highly generic and highly functional code. You end up fighting too much.
This librarydoes look nice, and top-level findings really do make a difference. But I doubt it's enough to really make up for all of C#'s shortcomings. But if you're stuck with C#, might as well make the best out it.
It is not just 'syntax'. Also I think a substantial portion of developers or the programming industry at large do not think these sort of tools are `useless`.
I am not saying the functionality is useless, but it already exists in other languages. Why force C# to look and behave like F# instead of just using F#?
I think most of the people creating and using these libraries would use F# if they could sadly. (However I am one of the lucky ones doing clojure in my day job.) Also a lot of existing software that needs to be maintained in C# would benefit from this library or others like it, just like they would benefit from having tools like linq, immutable collections, tpl available.
If this is just a fun project, scratch what I said, I love building useless stuff myself, but if it is intended to be used seriously I don't get the point.