5 ms·

We’re all slowing moving to functional programming. One day we wake up and decide we basically know Haskell, OCaml, etc and take off the training wheels?

fiveminds 7y ago
yes did you see the uncle bob video about programming future? before 11 years. --> it happing today
goto11 7y ago
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.
- fiveminds 7y ago
  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!
  - runevault 7y ago
    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.
  - goto11 7y ago
    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.
- thrower123 7y ago
  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.
  - Dolores12 7y ago
    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#.
- SuddsMcDuff 7y ago
  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#.
  - LandR 7y ago
    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?
jaked89 7y ago
The ability to change value by ref is crucial to most real-world apps. This is not surprising, as those apps are modeled to represent a real, dynamic world. Functional languages tend to disregard this, and demand composition over mutation. While this works for some domains, it's a burdensome complication for others. Imperative languages are here to stay.
- moomin 7y ago
  This is rather heavily debunked already. You might want to investigate that.
  - jaked89 7y ago
    You'd be more convincing providing a substantial response instead of referring me to "investigate". I've used FP extensively, and they all make mutation very hard, by design. Do you disagree with this premise? Do you disagree with my claim that the world is dynamic, and that FPs are limited in representing them? Please address my points specifically if you have anything meaningful to contribute.
    - moomin 7y ago
      I would be more convincing, but the whole point of my comment was that you need to do the work to get up to date with where the debate is. Don't ask other people to do the work for you. Anyway, FYI that's why you've been multiply downvoted. Not because there's some FP cabal who downvote pro-imperative comments.
      - jaked89 7y ago
        Didn't expect otherwise. You'd use a logical response if you had one. My comment is a direct response to the OP who implied FPs are going to "take over". I'm being downvoted probably by FP zealots who can't deal with the idea that their solutions aren't perfect or universal. BTW, I'm not "against" FP in general at all. I have used it in the past, and it has useful idioms to contribute to imperative languages, and it's perhaps useful on its own in some domains; I'm just pointing out its limitations.
mumblemumble 7y ago
I don't think so. Pattern matching and the like are just window dressing. The two true distinguishing features of Haskell are that it's lazy, and the compiler enforces referential transparency. Neither of those is something you can get by simply adding features to an existing language. And, if you aren't working within those strictures, you're still just not even in the same universe. No matter how many variables you make immutable, you'll still be able to log events by just executing a log statement, and you'll still be able to create a function that talks to a remote service, and call it from anywhere. So, you might use a few functional-inspired features when they're convenient, but the actual structure of your program is probably still imperative to the core.
- cultus 7y ago
  Haskell still doesn't have real referential transparency. It's all a matter of degrees and no language is pure, even Agda or Coq. The concept of IO as a world state you pass around is deeply flawed, especially with multiple cores. You cannot be in control of the world, so you don't really have equational reasoning. At any rate, there can be unsafePerformIOs lurking anywhere. I really think delimited-continuation based algebraic effects are the way to go.
- damnyou 7y ago
  It turns out that that "window dressing" is by far the most practically useful part of functional languages.
  - mumblemumble 7y ago
    I keep wondering what it would be like to work in a language that gave some compiler support for ensuring that functions remain mostly pure. Like, perhaps mutating variables that are visible outside the function or getting input from external sources are disallowed, but logging and writing debug output are still permitted.
    - cylon13 7y ago
      Haskell is like that with System.IO.Unsafe and Debug.Trace.
alkonaut 7y ago
I think the gravity is towards a middle ground that looks like imperative, but is quite functional compared to C, Java, C++ or early C#. Sum types, powerful type inference and and immutable-as-default. Kotlin, Rust, Typescript are all recent-ish languages an all fit into this category. Meanwhile F# approaches it from the other direction (start with OCaml and sprinkle on some imperative and OO).

fiveminds 7y ago

yes did you see the uncle bob video about programming future? before 11 years. --> it happing today

goto11 7y ago

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.

fiveminds 7y ago
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!
- runevault 7y ago
  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.
- goto11 7y ago
  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.
thrower123 7y ago
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.
- Dolores12 7y ago
  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#.
SuddsMcDuff 7y ago
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#.
- LandR 7y ago
  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?

jaked89 7y ago

The ability to change value by ref is crucial to most real-world apps. This is not surprising, as those apps are modeled to represent a real, dynamic world. Functional languages tend to disregard this, and demand composition over mutation. While this works for some domains, it's a burdensome complication for others. Imperative languages are here to stay.

moomin 7y ago
This is rather heavily debunked already. You might want to investigate that.
- jaked89 7y ago
  You'd be more convincing providing a substantial response instead of referring me to "investigate". I've used FP extensively, and they all make mutation very hard, by design. Do you disagree with this premise? Do you disagree with my claim that the world is dynamic, and that FPs are limited in representing them? Please address my points specifically if you have anything meaningful to contribute.
  - moomin 7y ago
    I would be more convincing, but the whole point of my comment was that you need to do the work to get up to date with where the debate is. Don't ask other people to do the work for you. Anyway, FYI that's why you've been multiply downvoted. Not because there's some FP cabal who downvote pro-imperative comments.
    - jaked89 7y ago
      Didn't expect otherwise. You'd use a logical response if you had one. My comment is a direct response to the OP who implied FPs are going to "take over". I'm being downvoted probably by FP zealots who can't deal with the idea that their solutions aren't perfect or universal. BTW, I'm not "against" FP in general at all. I have used it in the past, and it has useful idioms to contribute to imperative languages, and it's perhaps useful on its own in some domains; I'm just pointing out its limitations.

mumblemumble 7y ago

I don't think so. Pattern matching and the like are just window dressing. The two true distinguishing features of Haskell are that it's lazy, and the compiler enforces referential transparency. Neither of those is something you can get by simply adding features to an existing language. And, if you aren't working within those strictures, you're still just not even in the same universe. No matter how many variables you make immutable, you'll still be able to log events by just executing a log statement, and you'll still be able to create a function that talks to a remote service, and call it from anywhere. So, you might use a few functional-inspired features when they're convenient, but the actual structure of your program is probably still imperative to the core.

cultus 7y ago
Haskell still doesn't have real referential transparency. It's all a matter of degrees and no language is pure, even Agda or Coq. The concept of IO as a world state you pass around is deeply flawed, especially with multiple cores. You cannot be in control of the world, so you don't really have equational reasoning. At any rate, there can be unsafePerformIOs lurking anywhere. I really think delimited-continuation based algebraic effects are the way to go.
damnyou 7y ago
It turns out that that "window dressing" is by far the most practically useful part of functional languages.
- mumblemumble 7y ago
  I keep wondering what it would be like to work in a language that gave some compiler support for ensuring that functions remain mostly pure. Like, perhaps mutating variables that are visible outside the function or getting input from external sources are disallowed, but logging and writing debug output are still permitted.
  - cylon13 7y ago
    Haskell is like that with System.IO.Unsafe and Debug.Trace.

alkonaut 7y ago

I think the gravity is towards a middle ground that looks like imperative, but is quite functional compared to C, Java, C++ or early C#. Sum types, powerful type inference and and immutable-as-default. Kotlin, Rust, Typescript are all recent-ish languages an all fit into this category. Meanwhile F# approaches it from the other direction (start with OCaml and sprinkle on some imperative and OO).