Hacker News Reader

Comment by goto11 | Hacker News Reader

Well F# is based on OCaml, and it have been recognized for some time that C# is adopting more and more features from F#. As the article alludes to, this is not without controversy. Some feel that C# is becoming too bloated, and if you want to program in a functional style, you could just use F# in the first place. C# is much more widespread though, so this makes functional idioms more broadly available.

On the other hand, C# have also gotten deeper support for pass-by-reference and stack allocation which I consider more low level features. So I don't think the development is purely in functional direction.

View on HN

Every C# release, F# starts looking less and less compelling. There's already a level of friction, since so much of the underlying framework is C#-centric and littered with exceptions and nulls, and if you want to expose F# code to be consumed by C#, you have to dumb things down. And the tooling for F# is considerably less advanced than you get with ReSharper or even out-of-the-box in Visual Studio.

It's a bit of a shame; I suppose that is one of the reasons that some people in the F# community are really pivoting over to WASM and Fable for using F# in the browser.

I think you need less refactoring in F# in first place. Recently, i've tried fsbolero and was really impressed. No way I return back to C#.

C# can only go so far down the road towards F# without introducing currying and partial application. I can't see those ever being introduced into C#.

You can sorta get partial application using lambdas, or whatever they called in C#

Like a poor mans hacky partial application, one argument at a time.

     namespace Bored
     {
        using System;
        using System.Collections.Generic;
        using System.Linq;
        using static System.Console;
        internal static class Program
        {
           private static void Main()
           {
              var addFive = Add.Partial(5);
              addFive(6).Print(); // Prints 11
              Enumerable.Range(0, 5).Select(addFive).ForEach(WriteLine); // Prints 5 to 9
           }
           private static Func<int, int, int> Add = (int x, int y) => x + y;
        }

        internal static class Extensions
        {
             public static Func<T2, TR> Partial<T1, T2, TR>(this Func<T1, T2, TR> func, T1 t1) => t2 => func(t1, t2);
             public static void Print<T>(this T t) => WriteLine(t);
             public static void ForEach<T>(this IEnumerable<T> xs, Action<T> f) => xs.ToList().ForEach(f);
         }
     }

Define your partial extension method for each arrity to Func. I think it maxes at 16?

me to you can solve the same problem in 100 ways and each way can have its own tips and ticks and pors and cons! C# will be complex like c++ not for new developers only for experts!

While I don't entirely disagree with you, "default" c# style won't screw you up the way default c++ will, while masterful c# will give you a non-trivial amount of the benefits if they continue to make intelligent improvements.

Will it ever be perfect? Of course not. But I feel like the direction they are taking is a reasonable one.

This is the basic dilemma for any language. You can evolve and grow bigger, or you can stay simple and pure. I think history show languages have to evolve to stay relevant - "small and elegant" languages like Scheme and Smalltalk are not widely used. But since you can't really remove existing features, evolving leads to more complex languages.

Reply on news.ycombinator.com