This project is read-only.

Checkout this GitHub project for helping C# 6.0 developers to adopt a more functional programming style

Topics: General
Nov 19, 2014 at 8:18 PM
This looks very cool, check it out and get involved.

https://github.com/louthy/language-ext
Nov 20, 2014 at 4:46 PM
Edited Nov 20, 2014 at 4:50 PM
Frankly speaking this looks like an unidiomatic abuse of C# and the author is honest about it:
"Using and abusing the features of C# 6 to provide lots of helper functions and types, which, if you squint, can look like extensions to the language itself."
Good for experimenting, learning and researching. Not so good for seeing in production (unless whole codebase is done this style).

Why not simply use F# (apart from modern tooling being almost completely absent)?

"Null reference problem", "if( arg == null ) throw new ArgumentNullException("arg")" - C# 6 specifically addresses that.

"Option" - there is like 5-6 NuGet packages implementing Maybe/Option already.

"Poor tuple support" - looks very similar to proposed record types, at least from the point of view of pattern matching. And since tuples aren't meant to be used outside of method bodies / private state, anonymous types should get you covered.

He makes C# syntax look verbose:
In C# it looks like this:

var list = new int[] { 1, 2, 3, 4, 5 };
Or worse:

var list = new List<int>();
list.Add(1);
list.Add(2);
list.Add(3);
list.Add(4);
list.Add(5);
Actual idiomatic C# code:

var arr = new [] {1,2,3,4,5};
var list = new List<int> {1,2,3,4,5};
Also range:

// Creates a list of 1001 integers lazily.
var list = range(1000,2000);
How about simply importing a standard class in C# 6 and doing this:

http://msdn.microsoft.com/en-us/library/system.linq.enumerable.range(v=vs.100).aspx

Range(1, 1000);//Notice the idiomatic upper casing.
Some of the standard list functions are available. These are obviously duplicates of what's in LINQ.
Really? Can I read that "standard"?
This has to be one of the most awful patterns in C#:

int result;
if( Int32.TryParse(value, out result) )
{
...
}
else
{
...
}
There's all kinds of wrong there. Essentially the function needs to return two pieces of information:

Whether the parse was a success or not
The successfully parsed value
By now everyone has this (not difficult to implement, can use null coercion in C# 6 to avoid result null checking):

int? result = Int32Ex.TryParse(value);

PS: HN discussion thread - https://news.ycombinator.com/item?id=8631158
PPS: sorry if I sound a bit negative.
Nov 22, 2014 at 1:00 AM
Edited Nov 22, 2014 at 8:08 PM
PPS: sorry if I sound a bit negative.
I think you doth protest too much.
Why not simply use F# (apart from modern tooling being almost completely absent)?
Is Visual Studio not a modern tool? I do use F#, but I also maintain a large C# web application. I am simply trying to find ways to reduce some of the problems the language brings up regularly.
"Null reference problem", "if( arg == null ) throw new ArgumentNullException("arg")" - C# 6 specifically addresses that.
How exactly? I'm not aware of any new feature that catches null references passed to a method.
"Option" - there is like 5-6 NuGet packages implementing Maybe/Option already.
Is there a reason why you find that problematic? I've tried to provide a far more complete implementation than you'll find anywhere else... with Option and Either functions like: count, forall, fold, exists, map, bind, match etc. And a general mechanism for converting to enumerables. And this implementation deals with the null problem, which very few others do.
Actual idiomatic C# code:
Yes, I'd forgotten about the C# 5 syntax for list initialisation, I have already updated the documentation. It's still bulkier, but I agree it's not as bad as I made out. However, it's still mutable; that initial section was mostly leading into the idea that if you want to pursue a more functional development style, then you're more likely going to want to use immutable structures, including collections. ImmutableList.Create<string>() is creating negative inertia in that sense.
Poor tuple support" - looks very similar to proposed record types, at least from the point of view of pattern matching.
In the real world where code is being written now we can't wait for the glacial development of the language. The pattern matching branch of Roslyn hasn't been touched for months. I doubt we'll see that feature any time soon. Luckily we've now been given then tools to do some of these techniques, so I'm taking advantage of them.
And since tuples aren't meant to be used outside of method bodies / private state, anonymous types should get you covered.
What rulebook did you get that from? Tuples are product types, and can be used in anyway you wish. A tuple isn't the same as a record (even though records are also product types). Tuples create a 'shape' based on the types that form its definition, not its types and names. One can then create functions with 'holes' in; holes that the shape fits into. It allows one to create genuinely generic functions based on shape and not name. In the functional world where methods and private state are barely used, they're a staple. Your statement is incorrect.
Really? Can I read that "standard"?
I'm talking about the accepted names like: map, reduce, filter, fold, etc. From what I understand those were the original names of the LINQ methods, but the BCL 'naming committee' made the C# team change the names (I vaguely remember Eric Meijer talking about it, probably on a Channel9 video). Find me a mainstream functional language where they don't exist and I'll buy you a drink.
By now everyone has this
Again, what are you protesting? The idea of this library is to create a 'prelude' which is similar to typing 'using System;'. If you're happy with the way C# is, fine, it's not for you. If you're hankering for a functional toolkit then it is. C# is clearly repositioning itself; not to the extreme of being 'functional first' like F#, but it's definitely getting closer to the midpoint like Scala. However the idioms (or dogmas as they should really be called) are still stuck in C# 1.0 mode which were in turn inherited from Java. It's clear the C# team get this, but there's some stuff they just can't change. Like null.

There's many things on my wishlist for C#. Structs that call a default constructor when unitialised is currently top.
Nov 22, 2014 at 7:48 PM
This looks very cool, check it out and get involved.
Oh, and thanks @KevinRansom. It's nice to get some MS love :)
Nov 23, 2014 at 10:01 AM
Edited Nov 23, 2014 at 10:02 AM
I think it's a very valuable thing to try to do. It is clear that functional idioms offer some clear benefits in modern programming, and trying to make those available to C# and VB developers is going to benefit users of those languages. For sure you will get flamed in the effort, however, the effort is itself valuable and useful so keep at it. Also get involved in the proposals of Neal and Mads around language design for C# both of those guys are fans of F# and will be interested in your feedback on their designs. Similarly if there are ways to close the impedence mismatch when interoperating between F# and C#, & VB you should bring up those issues over on the F# project as well as here.

Kevin
Nov 23, 2014 at 2:49 PM
Edited Nov 23, 2014 at 5:11 PM
For sure you will get flamed in the effort, however, the effort is itself valuable and useful so keep at it.
Will do! I have been amazed at the positive response so far. I never expected it to get as much attention as it has.
Also get involved in the proposals of Neal and Mads around language design for C# both of those guys are fans of F# and will be interested in your feedback on their designs.
I have to admit I have only occasionally glanced over at the proposed features list on here. What's the best way to get involved in that sense?

My primary 'want' from C# is that everything can be programmed as expressions:
  • Make 'if' return a value
  • Make 'switch' return a value (obviously pattern matching would be great)
  • Turn 'void' into a real type so it can be used in generics, and therefore be useful in monads
  • 'foreach' and 'while' return void (the properly typed void, not the typeless void)
  • Tail recursive calls
  • Concise language grammar for creating lists, sequences, arrays and tuples
  • A reeeeeally nice feature would be to expand LINQ into the same Computation Expression system as F#. LINQ is already awesome; being able to extend that programmatically would be amazing.
Thanks again for the encouragement,

Paul