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

Functional programming is finally going mainstream

github.com

Post reply on HN
Print view View original

151–160 of 171 posts

Re: Functional programming is finally going mainstream

#151

Post by zelphirkalt »

kaba0 wrote: post #148
zelphirkalt wrote: post #143

Earlier quoted context omitted.

Yes, that is because in FP you limit yourself in what you are allowed to do. You refrain from doing things like mutating state. In OOP you do it all the time and that breaks assumptions about functions. If you then want to do something FP inside that OOP code, you will get impure functions, which do not compose well, because whatever part of the system you interact with from your FP part, you will have lots of side e…

I’m not sure FP limits you in any way. And I’m not just talking about Turing equivalence. When you are programming in FP, you are describing the program from another POV - taking the IO monad as an example, it just constructs a “list” of steps that should be taken at a given point vs just listing the steps in the program itself. In pure FP languages, immutability is enforced due to you describing a given state - it s…

You are correct in general about FP. I am talking about introducing FP in an existing OOP program though. You might want to use existing parts, but they are usually all impure, with lots of side effects. Any function in which you use those existing parts will be impure as well, unless you resort to things like IO monad. However, that makes it more complicated to implement things. You are building another layer of protection from the existing code and its state mutations everywhere.

Re: Functional programming is finally going mainstream

#152

Post by stickfigure »

zelphirkalt wrote: post #142
imtringued wrote: post #105

Earlier quoted context omitted.

I don't know what you mean. You can return a different type, the only constraint is that the methods don't return void and the subsequent method exists. This has nothing to do with the builder pattern.

You still have to do work though, to ensure, that always some fitting object with the correct methods is returned, so that you can chain further. Functions by definition (as opposed to procedures) return something and as long as that is the correct thing or type of thing for the next function, all is fine.

You don't have to do work; at any step you have the functions available that operate on the object returned (whatever it is). On the "Functions and Data" side you are similarly constrained by the possible functions that operate on that data.

Re: Functional programming is finally going mainstream

#153

Post by Akronymus »

zelphirkalt wrote: post #151
kaba0 wrote: post #148

Earlier quoted context omitted.

I’m not sure FP limits you in any way. And I’m not just talking about Turing equivalence. When you are programming in FP, you are describing the program from another POV - taking the IO monad as an example, it just constructs a “list” of steps that should be taken at a given point vs just listing the steps in the program itself. In pure FP languages, immutability is enforced due to you describing a given state - it s…

You are correct in general about FP. I am talking about introducing FP in an existing OOP program though. You might want to use existing parts, but they are usually all impure, with lots of side effects. Any function in which you use those existing parts will be impure as well, unless you resort to things like IO monad. However, that makes it more complicated to implement things. You are building another layer of pro…

I was actually talking about learning, rather than introducing to an existing codebase. But good points anyways.

Re: Functional programming is finally going mainstream

#154

Post by stickfigure »

cageface wrote: post #52
LAC-Tech wrote: post #35

Earlier quoted context omitted.

Sorry, I don't get what how that's harder. newData = f(oldData) VS newObject = oldObject.f()

Right that's one object. Often you need to change the state of a bunch of related objects in a transactional way. The way redux works for example. It's somewhat analogous to database transactions.

If you have a bunch of related objects that need to change together in a particular way, encapsulate them in a bigger object and offer methods that return the new, different bigger object.

Re: Functional programming is finally going mainstream

#155

Post by AlchemistCamp »

yowlingcat wrote: post #137
AlchemistCamp wrote: post #90

Earlier quoted context omitted.

I completely disagree with the kitchen sink language approach. The benefits in many coding paradigms really kick in once they're used 100%. For example, consider GOTOs. If 99% of your functions don't use any GOTOs but they other 1% does, you can't be sure how the flow of logic lead to any one function. Immutability works in a similar way. I have a far easier time debugging in concurrent code I'm unfamiliar with if it…

> have a far easier time debugging in concurrent code I'm unfamiliar with if it's written in Elixir than if it's written in JS/TS, even if the project in question uses Immutable.js heavily. How much of that comes from belief rather than reality, and potentially some room to grow on your end? I can debug well written code in any language I jump into, but I've found poorly written and hard to debug morasses can be writ…

> How much of that comes from a belief rather than reality, and potentially some room to grow on your end?

You know… suggesting that someone that they’re delusional and uninformed isn’t a very charitable way to discuss anything online.

The belief came from personal experience from 2016-2018 while I was much more experienced with JS/TS and relatively new to Elxir. It definitely influenced me to keep exploring and learning things outside the JS ecosystem I’d previously focused on. I’ve grown as a dev since and so has my appreciation of guaranteed immutability.

Also working with other languages, particularly Rust, in the past few years has only further underlined the point. It makes a strict delineation between variables, references and arguments that can be mutated and those that can’t. The language went with 100% guarantees instead of 95% guarantees for a good reason.

> I can debug well written code in any language I jump into

The phrase “well-written” may be doing a lot of lifting here. Different languages and ecosystems make different practices easy and tend to nudge users in different directions. People who don’t like learning often enjoy the idea that any Turing complete language is equivalent from the programmer’s perspective but it’s just not true.

Re: Functional programming is finally going mainstream

#156

Post by skavi »

ravi-delia wrote: post #26
LAC-Tech wrote: post #24

I'm not sure how I feel about this. If you look at my code in "multi-paradigm" languages like typescript, there's not a heck of a lot of loops, mutations or side effects. I like expressions, and immutability, and higher order functions. They make things shorter and means there's less state for me to keep track of - or screw up. But at the same time, I like objects. Almost all of mine are immutable. I went through a p…

With immutable objects, aren't you just left with syntactic sugar around structs and functions? I'm picturing CLOS, which is undoubtedly an OO system but lacks 100% of what you use objects for. Are there languages which let you use dot-syntax for "methods" which just wrap normal functions?

Koka has that [0].

a.f(b) == f(a, b)

[0]: https://koka-lang.github.io/koka/doc/book.html#sec-dot

Re: Functional programming is finally going mainstream

#157

Post by zelphirkalt »

stickfigure wrote: post #152
zelphirkalt wrote: post #142

Earlier quoted context omitted.

You still have to do work though, to ensure, that always some fitting object with the correct methods is returned, so that you can chain further. Functions by definition (as opposed to procedures) return something and as long as that is the correct thing or type of thing for the next function, all is fine.

You don't have to do work; at any step you have the functions available that operate on the object returned (whatever it is). On the "Functions and Data" side you are similarly constrained by the possible functions that operate on that data.

What I meant by "work" is, that inside your methods you have to return an object, which has the method, which is the next thing in your a().b().c()... chain. Often in OOP you would not return the object itself, unless you do the builder pattern. Of course you can return other objects, if it is intended, that the chain has a call to a method of another object next. However, you may only call methods of the returned objects and you must return objects.

In the function and data scenario, all that needs to be made sure is, that your functions have the return type, which the next function expects, otherwise it is a type error, regardless of whether the language complains or not. A function call chain implicitly assumes the types to be correct, otherwise you will likely run into an error.

The difference is, that in the functions and data scenario, you already have functions, which take data of some type and return data of some type. You do not change them in any way, while on the other hand with objects and methods you need to change the methods, so that they do return some fitting objects.

Re: Functional programming is finally going mainstream

#158

Post by yencabulator »

christophilus wrote: post #56
jayd16 wrote: post #50

Earlier quoted context omitted.

Why have immutable data structures not taken over in the general case if it's a strict improvement? Sometimes they're good and sometimes there not. The issue is functional programming needs them to be used in every case. Personally I'm of the opinion that purity is impossible so if a paradigm needs purity it's going to be an uphill battle.

FP doesn’t require their use in every case. For example, Clojure allows mutation as an optimization. But for the normal path, immutable data structures are just fine and help avoid a whole host of bugs.

I'd argue that means Clojure lets you use paradigms other than FP. FP is still FP.

Re: Functional programming is finally going mainstream

#159

Post by yencabulator »

ch4s3 wrote: post #59
dolni wrote: post #2

Functional programming with immutable state cannot possibly win in the general case. There are two truths that ensure the dominance of imperative software: 1. At some level of software complexity, programmers MUST start to organize data into composite objects. They have to do this because working outside of well-defined problem domains is a recipe for buggy software and spaghetti code. 2. Copying memory around to ena…

Immutable data structures often don’t copy a lot of data around. Immutable linked lists have tail references from each head. If something falls out of scope it gets collected by the garbage collector. Also if you don’t share memory between processes, you can free that memory once a process terminates, which may seem orthogonal but it’s a core principle in Erlang.

Those copy-on-write linked data structures, with the implied pointer chasing, have a cost. That's what the parent is talking about...

Re: Functional programming is finally going mainstream

#160

Post by deltaonenine »

Akronymus wrote: post #138
deltaonenine wrote: post #115

Earlier quoted context omitted.

2. Copying memory around to enable to facilitate these immutable structures is SLOW. This is categorically wrong. You actually don't know what you're talking about. In an functional programming language, because everything is immutable, the compiler just MOVES everything around. There is ZERO copying in a functional programming language. In fact there's no explicit command for it either. There is zero reason for you…

> What you're referring to is more of what happens when someone is writing functional code in a language that's not functional. And even then, there is the question of whethwr it is a deep or shallow copy on receiving or write.

just pass a const reference. It's immutable anyway.
Post reply on HN