Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cohost.org

Post reply on HN
Print view View original

171–180 of 188 posts

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

#171

Post by tsimionescu »

andrepd wrote: post #127
tsimionescu wrote: post #94

Earlier quoted context omitted.

No, the more memory you give them, the more efficient they are, and generally they are much more efficient than an equivalent program using malloc() + free() for every piece of memory that gets allocated. Take the extreme case of a program where every allocation is permanent. The GC allocation will be much much faster than malloc() (GC allocation is normally just bumping a pointer to the end of the heap, while malloc…

GC does force you into a memory layout for your objects that negates any advantage in the allocation routines proper.

I'm guessing you're referring to the fact that the most popular GC languages allocate almost every object on the heap, even when used as a field of another object. This is by no means a constraint of the GC, it is a separate design choice.

And in fact C# has always supported "value objects", which do get allocated in-place, Java is adding the same support probably in the next release, and Go actually defaults to it.

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

#172

Post by xigoi »

nikhilsimha wrote: post #66
pornel wrote: post #8

> Rust's shared XOR mutable references […] makes linearity nearly useless or inevitably creates a parallel, incomplete universe of functions that also work on linear values. Yup. Rust can't abstract over mutability. For owned values, it defaults to exclusive ownership, and needs explicit Rc and clone() to share them. For references, in practice it requires making separate `foo()` and `foo_mut()` functions for each ty…

i personally like nim’s approach to memory management - implicitly refcounted, but exposes clean manual memory management when needed

Also it automatically uses a tracing GC for cyclic types to avoid leaks (but this can be turned off per type or globally).

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

#173

Post by tome »

ColonelPhantom wrote: post #138
tome wrote: post #117

Earlier quoted context omitted.

> By simulating exceptions, do you mean a `Result t e` type (which Haskell calls `Either l r`)? Yes, exactly. > The semantics of these are.. interesting, mostly thanks to lazy evaluation. For example, `fst (5, error "second") ` is safe to evaluate because the second half of the tuple is a thunk and does not get evaluated Correct, and the semantics of loops is also.. interesting. For example `fst (5, last [1..])` is a…

Hm yeah, I'm not sure what astrange's point was, other than probably dissatisfaction with the combination of exceptions and Either (which I think is awfully named, as it implies a certain 'equality' between l and r). I haven't used Bluefin, but don't Bluefin exceptions suffer from the same issue where it, essentially, 'infects' the program flow? For example, `fst (5, error "second")` seems like it would translate to…

You're right, but my response would be that

    fst (5, error "second")
and

    head [] = error "empty list"
    head (x:xs) = x
are simply not things you should be writing. They're not good program design and it's not a weakness that Bluefin doesn't support them unaltered.

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

#174

Post by DanielHB »

jerf wrote: post #144
jmull wrote: post #128

> A lot of people think that functional programming is mostly about avoiding mutation at all costs. People should try to stop thinking of mutation as something to be avoided, and start thinking of it as something to be managed. Mutating state is good. That's usually the whole point. What's bad is when you create "accidental state" that goes unmanaged or that requires an infeasible effort to maintain. What you want is…

I like to say that immutability is a really good idea in the 1990s, especially considering how counterculture it would have been at the time. I don't mean that as diminutive or patronizing, I'm serious. It was a good cutting edge idea. However, nobody had any experience with it. Now we do. And I think what that experience generally says is that it's a bit overkill. We can do better. Like Rust. Or possibly linear type…

All this immutability discussion is more about going against "old school object orientation" which promoted keeping state spread out around a lot of mutable object instances.

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

#175

Post by neonsunset »

tsimionescu wrote: post #121
naasking wrote: post #96

Earlier quoted context omitted.

> 2. GC performance is harder to predict and reason about than certain other allocation strategies I'm not sure what you mean by this being the least understood. It seems like it's very well understood: GC introduces latency if you want good throughput, or it reduces throughput if you want excellent latency (sub-100us is possible). Of course, that doesn't mean you can predict what specific throughput or latency prope…

The point is that it's very hard to predict how much of an impact the GC will have a priori. You can of course measure after the fact, and try to improve, but it's hard to architect your system in a way that you can more or less guarantee will get good GC performance (other than just not allocating any memory, of course). Malloc actually suffers from a similar problem: it's just hard to know a priori if your access p…

Respecting generational hypothesis is a good step towards engineering a GC-friendly design. Mind you, this brings back the necessity to reason about object lifetime, something a GC-based language absolves you from, but it does help. It tends to teach you a lesson that sometimes higher allocation count of objects that die in Gen 0 is preferable to fewer larger allocations which have higher chance of surviving until Gen 1 (.NET has three main generations for GC objects - 0 and 1 aka ephemeral and 2 aka long-lived, there are also LOH, POH and NonGC-heap).

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

#176

Post by p_l »

eru wrote: post #168
p_l wrote: post #137

Earlier quoted context omitted.

If you compile your immutable program with LLVM, literally one of the cure steps is transforming it into functional form that does not allow mutations. This is called Single Static Assignment form and its denial of mutation is crucial to optimization, from common expression removal, to efficient register allocation, and all sorts of control flow analysis.

> If you compile your immutable program with LLVM, literally one of the cure steps is transforming it into functional form that does not allow mutations. You probably wanted to write something like 'If you compile your _mutating_ program with LLVM, [...]'?

Yes. Unfortunately I wrote the answer on the phone, and completely missed the (way more common in my writing) word replacing the right one :/

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

#177

Post by pjmlp »

AdieuToLogic wrote: post #170
jerf wrote: post #144

Earlier quoted context omitted.

I like to say that immutability is a really good idea in the 1990s, especially considering how counterculture it would have been at the time. I don't mean that as diminutive or patronizing, I'm serious. It was a good cutting edge idea. However, nobody had any experience with it. Now we do. And I think what that experience generally says is that it's a bit overkill. We can do better. Like Rust. Or possibly linear type…

> I like to say that immutability is a really good idea in the 1990s, especially considering how counterculture it would have been at the time. I don't mean that as diminutive or patronizing, I'm serious. It was a good cutting edge idea. > However, nobody had any experience with it. Now we do. Working intimately with C++ in the '90s, immutability as a concept was neither considered counterculture nor without signific…

Indeed, my 1990's C++ code is full of const methods.

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

#178

Post by pjmlp »

andrepd wrote: post #127
tsimionescu wrote: post #94

Earlier quoted context omitted.

No, the more memory you give them, the more efficient they are, and generally they are much more efficient than an equivalent program using malloc() + free() for every piece of memory that gets allocated. Take the extreme case of a program where every allocation is permanent. The GC allocation will be much much faster than malloc() (GC allocation is normally just bumping a pointer to the end of the heap, while malloc…

GC does force you into a memory layout for your objects that negates any advantage in the allocation routines proper.

Only if speaking about languages without system programing capabilities alongside their GC features.

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

#180

Post by rrishi »

jerf wrote: post #144
jmull wrote: post #128

> A lot of people think that functional programming is mostly about avoiding mutation at all costs. People should try to stop thinking of mutation as something to be avoided, and start thinking of it as something to be managed. Mutating state is good. That's usually the whole point. What's bad is when you create "accidental state" that goes unmanaged or that requires an infeasible effort to maintain. What you want is…

I like to say that immutability is a really good idea in the 1990s, especially considering how counterculture it would have been at the time. I don't mean that as diminutive or patronizing, I'm serious. It was a good cutting edge idea. However, nobody had any experience with it. Now we do. And I think what that experience generally says is that it's a bit overkill. We can do better. Like Rust. Or possibly linear type…

>And I think what that experience generally says is that it's a bit overkill. We can do better. Like Rust.

Or OCaml perhaps ? They have taken a very pragmatic approach to fp and allow mutations because thats the pragmatic choice sometimes.

Post reply on HN