Live data from Hacker News

Functional programming is finally going mainstream

github.com

141–150 of 171 posts

Re: Functional programming is finally going mainstream

#141

Earlier quoted context omitted.

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.

I’m not a functional programmer by trade, but I think you’re alluding to (and should reframe your argument to discuss) concurrent reads and the implications of immutable data in a multithreaded scenario. It’s about simplifying your programs state machine. If I have some object A in an OO world, some N threads may act on said object concurrently resulting in some degree of non-determinism for any function of A. In FP,…

Can I make a stupid example? Lets assume you got some building with people inside. One person exits the building. mybuilding.leave(person) or so. What does .leave(...) do? Ah, it needs to reduce the counter of people in the building by 1. Oh and by convention this means, that the person is checking out, so lets update their schedule to account for that. Ah they are also currently "out of office". Ah and the person at the door, who keeps watch has now seen another person leaving. Maybe the person went through a scanner. The scanner statistics need to be updated.

And so on and on. All kinds of objects need updates for their states. You need to direct all this stuff, without forgetting things. Otherwise the state of your objects will become inconsistent and at some point it will show as some kind of bug. At that point you might find yourself debugging the whole thing, to find out when the inconsistency starts or what causes it.

No need for multiple threads or any of the kind. Complications from splitting the state up and parking it in various objects and having to tell the computer how to update these objects. Instead of looking at 1 function at a time, which only works on its inputs and gives an output, you have to remember to call all the appropriate methods across some reasonable part of your entity landscape.

Re: Functional programming is finally going mainstream

#142

Earlier quoted context omitted.

And to straw man the OO way a little... newData = oldData.f().g().h().i().j().k() wont work by default unless you also happen to return the object after every method (builder style) which looks weird and is not standard

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.

Re: Functional programming is finally going mainstream

#143

Learning generalized concepts of FP just make a lot of sense IMO. Knowing that you can map all functors the same way wether it's an Optional, List, Future or Either is a useful tool to have. Using it in a language with syntactic sugar to compose map and flatMap (>>= in Haskell) operations helps to write clean code a lot. For me, solving problems in a functional way is not always as intuitive as the imperative approac…

IME it is much easier to start with FP and later on introduce OOP rather than the other way around. And yeah, sometimes stepping down into mutability and such is necessary for performance.

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 effects being triggered.

Re: Functional programming is finally going mainstream

#144

Earlier quoted context omitted.

IME it is much easier to start with FP and later on introduce OOP rather than the other way around. And yeah, sometimes stepping down into mutability and such is necessary for performance.

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…

[deleted]

Re: Functional programming is finally going mainstream

#145

Earlier quoted context omitted.

React functional components have nothing to do with functional programming. Hooks are stored in global variables.

Is Erlang functional programming? Anything in an Ets table is a global variable. There's even mutable state hiding in the process dictionary! You might have to access a database, which is global state! The horrors!

In Joe Armstrong's own words: Erlang is either the most object-oriented or the least object-oriented language.

It also very much discourages mutation and favors pattern matching and pure functions, so I would say it is quite FP in nature.

Re: Functional programming is finally going mainstream

#146
post #65

Earlier quoted context omitted.

I do not think it is reasonable to call JS a Functional programming language.

No but it popularized practical functional programming through react.

React does have little to do with it, I would say. Its components are quite the opposite of FP actually. They are closer to OOP bundling state and behavior together.

Re: Functional programming is finally going mainstream

#147

Earlier quoted context omitted.

I suggested this wonderful feature to julia but it was rejected:( Glad to hear D has it. as OP said it would make functional languages more ergonomic (especially for OO folks) and most importantly enable code completion!

There already is a syntax for that: a |> bar |> foo

neat, thanks!

it's still a bit unergonomic to type but a very useful beginning!

Reminds me of hurting my fingers in c where you had to type '->' instead of '.' !

Re: Functional programming is finally going mainstream

#148

Earlier quoted context omitted.

IME it is much easier to start with FP and later on introduce OOP rather than the other way around. And yeah, sometimes stepping down into mutability and such is necessary for performance.

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 simply doesn’t make sense to change something there.

Re: Functional programming is finally going mainstream

#149

Earlier quoted context omitted.

No but it popularized practical functional programming through react.

React functional components have nothing to do with functional programming. Hooks are stored in global variables.

And Haskell compiles down to C- as a step, which is as imperative as it gets. I don’t see how an implementation detail determines the degree of FP.

Re: Functional programming is finally going mainstream

#150
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…

Copying is an implementation detail, it doesn’t have much to do with FP in itself. If anything, due to the compiler knowing that variables can’t change, it can optimize away copies much much more aggressively than a “traditional” PL.
Post reply on HN