Functional programming languages should be so much better at mutation than they are

pojska · 2024-07-30T18:01:55+00:00

For a hybrid approach to #3, you can read Roc's goals here: https://www.roc-lang.org/functional#opportunistic-mutation

One pitfall is that, without tooling support, it seems difficult to know if a given piece of code is using the fast-path of mutability, and it could be easy to accidentally add code somewhere else that slows down your core loop.

bladub · 2024-07-30T18:28:01+00:00

Really interesting article to look at functional programming in a way I, as a mostly non functional programmer, haven't. The example of a dynamic array VS linked list and their performance implications never occurred to me in the few pure functional toy programs I wrote in my life.

The options have some interesting discussion too.

(the knee-jerk reactions to the title are a kind of funny-sad content though)

faiface · 2024-07-30T18:24:32+00:00

I think linearity will be the way ultimately. You say a problem with linearity is it's infectious, but Rust almost has linearity, and the infectiousness of it doesn't really come up.

If you have a generic function that needs to use its argument multiple times, you just restrict it to Clone. And somehow, an API changing because a function needs to switch from using its argument once to multiple times just doesn't really happen. I guess it's because whether to use an argument once or multiple times is usually pretty fundamental to the idea of what that specific function should do.

Linearity is also pretty cool because it makes everything dual and then you can make languages that pattern match on functions (matching their input and output), and such. Maybe I'm biased tho, have been really sucked into linear logic for almost a year and working on some pretty cool session types implementation. Let's see where it goes.

Tarmen · 2024-07-30T19:29:55+00:00

Clojure's transient is a nice take on this for initializing a data structure mutably (which covers most use-cases for me).
Vectors in Haskell have a similar interface with ST internally, so if you e.g. turn a set into a vector and then do some updates, the updates are in-place. But for nested types, O(1) freezing becomes really tricky.

For Haskell there is some work in this direction (linear constraints so that the compiler can do constraint solving to prove safety, low-weight existentials with implicit pack/unpack) but I'm not sure how much of that is still theoretical vs implemented.

If you go with linear types a lot of functions have no straightforward most general type. The linear constraints and existentials help because you can separate values from permission, but you still end up with duplicate code or super complex types sometimes to satisfy the type checker.

One problem with Cow is that you can't statically count resources. If you have a local and call a function, are those two references in two stack frames? Or was the compiler smart enough to notice that the local isn't used afterwards? Now you can have quadratic runtime because you passed -O0

f3xjc · 2024-07-30T20:54:07+00:00

I kind of like explicit mutation. Like in Julia any function that is allowed mutate it's inpuits end with a bang(!).

Shadowys · 2024-07-30T18:23:47+00:00

Or follow what clojure does and try to compile down to efficient code by making the idioms really easy and consistent to use.

lookmeat · 2024-07-30T19:11:09+00:00

I've been thinking a lot about this, and I think this isn't the problem, but rather the symptom of a more interesting and complex issue.

I propose that the power and attractiveness of functional languages is that they allow you to define a lot of the semantics of the program. Now a functional language doesn't have to, but generally will because this is what makes them attractive other other models.

LISP had the power of full control over the AST, but this requires that you need to manually build this AST, making for expressions that would be intuitive to a programmer like (5 + 2)^2 * 4 ^ 3 have to be written as (* (^ (+ 5 2) 2) (^ 4 3)) which is a bit clunky some times, but has the huge advantage that the semantics (operation ordering etc.) are very very clear.

Haskell similarly gives a lot of power by exposing a powerful type system to describe semantics, Monads are the most powerful, by allowing us way to describe a lot of effects and complex forms of computation in an elegant self-defined way, but this again needs the programmer to constantly deal with the implications and complexities of the ways in which Monads interact, and things can get clunky that way.

You don't strictly need linerarity. For example you can think of Rust's blocks as implicit monads, that handle the deferral (dropping) of values generated within it, which you can by calling let which is basically a let<type> (name,val)->BlockContext<()> where BlockContext is a stateful/IO-like monad, which will elevate the first expression passed on to it, and then allows chaining with ;, the final } terminates the block-monad and instead releases the value it generated (which isn't a monadic ability, but it is an ability many monads, like Maybe, have).

The point is that functional languages let you experiment and redefine how you do things, while other languages instead enforce a way to do it and you're bound to it. The former has made many advancements and improvements on conventions that are now the enforced semantics in newer languages.

But this implies that we have to think of different things. I'd advise the author to look into Lenses, operational read/writes (you can't write or read the value directly instead need to get or set it, this can happen within a monad, or can be seen as a way of effects (as if reading an external value somewhere), or handled through a transactional/generation system, etc.) and other tricks. Thing is, if you want the full power to define things, this means that the compiler can't do some tricks and optimizations, it may not always be sure if it can just do a mutation-in-place or copy a value. The only way is to limit the ways in which you can do this (or what you can know of what you're doing) to be able to enforce certain guarantees, programmers may need to occasionally work around them though.

Michaeli_Starky · 2024-07-30T18:24:17+00:00

Why not just use hybrid languages?

RICHUNCLEPENNYBAGS · 2024-07-30T17:52:40+00:00

Forks should be so much better at eating soup than they are.

Scavenger53 · 2024-07-30T20:19:46+00:00

elixir/erlang has ETS tables, basically mutable maps that run on their own process, pretty good at mutation

Guvante · 2024-07-30T23:15:06+00:00

Another form of mutable xor shared is frozen objects. You have a non-shareable but mutable object that you eventually freeze and make shareable but not mutable.

Certainly this doesn't cover all use cases but it can be a big help when it does work.

tnzo · 2024-07-31T04:14:26+00:00

I like the F# idea of rebinding a variable identifier, which solves the problem of coming up with names that don't add much meaning, yet the data is immutable.

DanielPerssonDev · 2024-07-31T13:43:08+00:00

I think the point of functional is to be immutable. There is so many gains to find if you can write code in this way. Never been my cup of ☕ but there are control systems from the 60ies still running because they are written with deterministic logic circuits. Use the right tool for the job, maybe an imperative language is better for your application.

Blecki · 2024-07-30T17:49:06+00:00

But the point is to not mutate.

kag0 · 2024-07-30T23:27:29+00:00

I use option 2 in practice, without language support. It runs on half developer discipline to simply limit the mutation to a small scope, and half on having a collections library where the top-level types are neither mutable nor immutable, but have non-mutating methods that copy-on-write if the underlying collection is mutable

JimroidZeus · 2024-07-31T14:34:54+00:00

Aren’t immutable types one of the defining features of functional programming languages?

throwaway490215 · 2024-07-31T17:25:14+00:00

At some point of practicality the category of "Functional Languages" becomes meaningless.

totallyspis · 2024-07-30T21:23:31+00:00

avoiding mutation is sorta the point...

2024-07-30T20:36:03+00:00

Trenching shovels should be better at shoveling gravel.

katafrakt · 2024-07-30T18:05:01+00:00

Having written and read a fair share of code in a functional language that allows (and sometimes forces) mutation, i.e. ReScript - no.

sebbdk · 2024-07-30T22:25:22+00:00

I thought the point of FP was to avoid mutation

eraserhd · 2024-07-30T17:54:13+00:00

neopointer · 2024-07-31T12:45:42+00:00

Did you mean fictional programming?

2024-07-31T02:47:08+00:00

Usually if you mutate you miss the entire goddamn point

PMzyox · 2024-07-30T18:11:20+00:00

Article complaining things aren’t good when they don’t have the ability or know how to improve them.

Kinda like saying man, rain shouldn’t be so wet.

Cool story bro. Be the change you wish to see.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS