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

51–60 of 171 posts

Re: Functional programming is finally going mainstream

#51

Post by ravi-delia »

Jtsummers wrote: post #27
ravi-delia wrote: post #26

Earlier quoted context omitted.

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?

What does CLOS lack that you want from an OO system?

Nothing! I mean I personally just use defstruct unless I want inheritance, but that's certainly not because CLOS lacks anything. I meant "you" as in the person I responded to, who wants immutable data structures with tightly coupled functions. It's because CLOS is among the most object oriented systems I know of that I used it as an example; there seem to be some basically orthogonal traits which nonetheless wind up highly correlated, and CLOS is the purest OO you can get this side of Smalltalk while looking different from what you see in Java or whatever.

Re: Functional programming is finally going mainstream

#52

Post by cageface »

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

Earlier quoted context omitted.

The problem with state in objects is that in more complex systems you often need to change a bunch of related state at one time. When it's all bound up in individual objects that manage their own state this becomes very complicated.

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.

Re: Functional programming is finally going mainstream

#53

Post by ravi-delia »

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

Earlier quoted context omitted.

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?

With immutable objects, aren't you just left with syntactic sugar around structs and functions? Yeah I've gone down this thought experiment. Conclusion I came to is that while you could view it that way, there's something powerful about Just Having One Thing, not structs + functions. It's almost a mindset shift as well, like you're requesting the object to do something and don't care how. Are there languages which le…

> It's almost a mindset shift as well, like you're requesting the object to do something and don't care how.

I definitely see what you mean, a lot of FP encourages very general abstractions rather than something domain specific. That being said, I think Elixir has a pretty good handle on using functions as sort of black-box interfaces you can change later. Not sure if that's a language thing or a culture thing though.

> Yeah, Dlang has that.

Ooo, that's really nice. Super simple but a definite improvement to readability. Reminds me of |> in Elixir (or ~> in Clojure), particularly the chaining part. It clicks differently though, and definitely makes things readable for many programmers. Now that I'm writing this out, doesn't Rust have something like this? Like functions strapped right to a struct?

Re: Functional programming is finally going mainstream

#54

Post by LAC-Tech »

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.

Not sure what you mean here. Redux changes the state of one piece of data - the thing inside the redux store. Really not hard to imagine that with one big object in the exact same fashion.

Re: Functional programming is finally going mainstream

#55

Post by gurjeet »

rvieira wrote: post #9

Side note, GitHub's URL scheme is so counter-intuitive. I spent the first 10s wondering who this readme user was and how could they have such a different main page. Then there's the orgs at the same level as users...

I guess the mods here need to create an exception for such paths, and simply label them as 'github.com', rather than the usual scheme of showing the user/org name.

Re: Functional programming is finally going mainstream

#56

Post by christophilus »

jayd16 wrote: post #50
naasking wrote: post #21

Earlier quoted context omitted.

> At some level of software complexity, programmers MUST start to organize data into composite objects. I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean. > Copying memory around to enable to facilitate these immutable structures is SLOW. Slower than what and in…

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.

Re: Functional programming is finally going mainstream

#57

Post by phillipcarter »

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…

This comment is a fine example of what it's like to have strong opinions about something you've never used.

Re: Functional programming is finally going mainstream

#58

Post by gurjeet »

naasking wrote: post #21
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…

> At some level of software complexity, programmers MUST start to organize data into composite objects. I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean. > Copying memory around to enable to facilitate these immutable structures is SLOW. Slower than what and in…

Note: the log (aka write-ahead-log) in Postgres, and its ilk, enables the D(urability) of ACID. MVCC in Postgres is implemented by storing the visibility info of each row in the row-header (search: xmin, xmax).

Some commercial RDBMSs do use their logs for MVCC, though.

Re: Functional programming is finally going mainstream

#59

Post by ch4s3 »

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.

Re: Functional programming is finally going mainstream

#60

Post by AtlasBarfed »

This is the year of Lisp on the desktop! Or was that Linux goes functional programming? Haskell in the database? Immutable documentdb goes webscale?

Javascript was an ugly thing on the browser, I do hope that webassembly helps with that, but I highly suspect that webassembly will be for evil programming that is even harder to decipher in compiled-bytecode format.

Alas, the article is riddled with many of the same problems that FP evangelism is usually saddled with, but this time with slightly more colorful fonts.

1) do not say or show the symbol for "lambda".

2) immutable: such a harsh, harsh word.

3) Yup, there's the word "pure". Heil, comrade, happy sharia to you.

4) AHHHH, "higher order". Expanding the consciousness. Take a puff, man.

Well, at least he didn't say anything about monads, functors, or category theory. And there's no implementation of the fibonacci sequence.

Post reply on HN