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.
I really think delimited-continuation based algebraic effects are the way to go.
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.
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.
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);
}
}
Will it ever be perfect? Of course not. But I feel like the direction they are taking is a reasonable one.
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).
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.
Another example might be a text editor buffer. Immutable persistent data structures allow one to get many features for free such as versioning, undo, lockless autosave. Memory is cheap now, there's less of a need to throw away some my edits with destructive updates. Even filesystems and databases have realised this is good idea. Destructive updates are bad for valuable data.
Imperative programming is only better for writing low-level system code, which is full of state that ultimately no one in the real world cares about.
Imperative programming is the dominant programming model that 99.99% of all real world code for the last 60 years has been programmed in. It very well may be due to be replaced, but certainly cant just be hand-waved away
Imperative programs can have isolated, pure subsections of functionality which are based on composition and immutability, without having to deal with the "ideological" strictness of FP.
You're considering only a minute aspect of large systems. Any real banking system has much more than a ledger to deal with. And most of it involves huge amounts of state, which you can't just pile on top of RAM, or waste CPU on. Anything that doesn't serve a real business/user purpose is just waste.
And text editors don't need FP to support undo either. I'm not sure what point are you trying to make.
The most successful editors in the market, supporting all the features you mentioned, do quite fine with imperative, and in fact, I'm not aware of any meaningful editor written in a FL.
> Memory is cheap now
Not really. This comment strikes me as if it comes from someone who never dealt with significant amount of data.
FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs. They waste object-container data, pointer data, and scatter the list items, causing cpu cache misses.
Claiming that imperative is only better for low-level is extremely disconnected from reality. Try writing a game with FP, and I assure you no one will care for code "beauty" when FPS sucks.
Sometimes, arguing with FP purists feels like debating socialists.
Also: go ahead and downvote me, as apparently FP zealots can't tolerate questioning their religion.
And functional programming languages can support imperative programming and mutation, even Haskell. It's a question of what should be the default, which depends on the domain you are working in.
> Any real banking system has much more than a ledger to deal with.
Most banking systems are cobbled together from third-party components and libraries. Low-level languages aren't really needed. Many banks use Python, which is orders of magnitude slower than Haskell.
> This comment strikes me as if it comes from someone who never dealt with significant amount of data.
Actually I have a background in distributed computing, where functional programming abstractions have made processing large amounts of data much easier (MapReduce, Spark).
> FP can be extremely wasteful; take head-tail lists for example, which are the default container in many FPs.
This is a strawman. I can write inefficient code in any language. C++ code can be littered with pointer indirection and memory barriers.
> Sometimes, arguing with FP purists feels like debating socialists.
I am a socialist.
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.
Anyway, FYI that's why you've been multiply downvoted. Not because there's some FP cabal who downvote pro-imperative comments.
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.
One day we wake up and decide we basically know Haskell, OCaml, etc and take off the training wheels?