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

91–100 of 171 posts

Re: Functional programming is finally going mainstream

#91

Post by nyanpasu64 »

miloignis wrote: post #6
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…

Ah, but you don't always have to copy memory around to facilitate immutable datastructures. Koka lang and Roc lang are at the forefront of a functional-but-in-place (FBIP) style of memory management that use hyper-fast ref-counting and if a function owns the sole reference to a datastructure can mutably modify it instead of deallocating & reallocating. The most recent Perceus reference counting paper, implemented in…

Does Perceus differ substantially from using https://lib.rs/crates/im and writing code which looks identical to imperative code, but cloning is faster and mutations are slower (and copy internal structures as necessary)?

Re: Functional programming is finally going mainstream

#92

Post by ncmncm »

lvass wrote: post #89
ncmncm wrote: post #86

Earlier quoted context omitted.

The big mistake is in believing there is any value in this - or that -oriented programming, or in a this - or that -oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every b…

"Subproblem" is likely an exaggeration here, otherwise I vehemently disagree. Take Erlang for example, it's theoretically a general purpose language but highly specialized. Would WhatsApp reach a billion users with 50 engineers without this specialization? I doubt it. It's absolutely fine for things to be heavily specialized, as it is fine for our entire civilization to rely division of labor. As the number of develo…

There are very successful insects.

Re: Functional programming is finally going mainstream

#93

Post by danielscrubs »

ncmncm wrote: post #86
kstenerud wrote: post #68

My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.

The big mistake is in believing there is any value in this - or that -oriented programming, or in a this - or that -oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every b…

“Everything is Turing complete” isn’t true. You can get quite interesting languages by making sure it isn’t. See strong functional programming for examples.

https://en.m.wikipedia.org/wiki/Total_functional_programming

Re: Functional programming is finally going mainstream

#94

Post by miloignis »

nyanpasu64 wrote: post #91
miloignis wrote: post #6

Earlier quoted context omitted.

Ah, but you don't always have to copy memory around to facilitate immutable datastructures. Koka lang and Roc lang are at the forefront of a functional-but-in-place (FBIP) style of memory management that use hyper-fast ref-counting and if a function owns the sole reference to a datastructure can mutably modify it instead of deallocating & reallocating. The most recent Perceus reference counting paper, implemented in…

Does Perceus differ substantially from using https://lib.rs/crates/im and writing code which looks identical to imperative code, but cloning is faster and mutations are slower (and copy internal structures as necessary)?

It does the same mutate-if-unique optimization as im, but it does so automatically and more broadly as a part of its optimized reference counting. Perceus can go beyond what im can do by re-using allocations between static types - one of their examples involves doing a tree traversal with O(1) extra space by using a zipper which gets optimized by Perceus into a Morris traversal - and the programmer doesn't have to do anything special to get the benefit! (of course, writing code in such a way that you know it will be optimized has performance benefits if you do know how it works) This sets up this wonderful situation where you can write easier-to-maintain and easier-to-verify-correct algorithms that get optimized into very efficient versions that would be hard to write by hand even in a mutable/imperative language.

Their papers and online docs are very good, I highly recommend them for more information!

Re: Functional programming is finally going mainstream

#95

Post by pjmlp »

ncmncm wrote: post #86
kstenerud wrote: post #68

My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.

The big mistake is in believing there is any value in this - or that -oriented programming, or in a this - or that -oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every b…

I like very much how Wirth puts it, Programs = Algorithms + Data Structures.

Everything else is syntactic sugar.

Re: Functional programming is finally going mainstream

#96

Post by ncmncm »

danielscrubs wrote: post #93
ncmncm wrote: post #86

Earlier quoted context omitted.

The big mistake is in believing there is any value in this - or that -oriented programming, or in a this - or that -oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every b…

“Everything is Turing complete” isn’t true. You can get quite interesting languages by making sure it isn’t. See strong functional programming for examples. https://en.m.wikipedia.org/wiki/Total_functional_programming

That you can code certain solutions in a non-Turing-complete language is of identically null benefit.

Re: Functional programming is finally going mainstream

#97

Post by yobbo »

kstenerud wrote: post #79
peheje wrote: post #73

Earlier quoted context omitted.

What languages? Did you performance profile before to see what was slow?

C++, Python, Kotlin, some others I can't remember anymore. The most common issue is hidden O(n) situations, which don't show up except in production. So what we end up with is a mix of various paradigms worthy of Dr Frankenstein, and a debugging nightmare. I've been in engineering long enough to see most trends repeat at least twice (Javascript UIs are ALMOST back to the point of the 90s for example). After awhile yo…

> hidden O(n) situations

How are these faster in imperative code?

Re: Functional programming is finally going mainstream

#98

Post by penguin_booze »

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...

Agreed. I'd have preferred a top-level discriminant, like Reddit has with /r and /u paths at the top.

Re: Functional programming is finally going mainstream

#99

Post by ncmncm »

pjmlp wrote: post #95
ncmncm wrote: post #86

Earlier quoted context omitted.

The big mistake is in believing there is any value in this - or that -oriented programming, or in a this - or that -oriented language. An engineer uses what is available to produce an economically balanced solution. Done well, that may involve a few OO-ish bits, some functional bits, data-oriented bits, reactive bits, plus hybrid combinations of those and others. The problem dictates the form of the solution. Every b…

I like very much how Wirth puts it, Programs = Algorithms + Data Structures. Everything else is syntactic sugar.

If that were true, the past 30 years of progress in programming languages would be meaningless. But it is not: a more powerful language enables expressing what a weaker language does not.

A language meant for use by professionals should get powerful features, without regard to any spurious notions of "purity".

Re: Functional programming is finally going mainstream

#100

Post by occamrazor »

yobbo wrote: post #97
kstenerud wrote: post #79

Earlier quoted context omitted.

C++, Python, Kotlin, some others I can't remember anymore. The most common issue is hidden O(n) situations, which don't show up except in production. So what we end up with is a mix of various paradigms worthy of Dr Frankenstein, and a debugging nightmare. I've been in engineering long enough to see most trends repeat at least twice (Javascript UIs are ALMOST back to the point of the 90s for example). After awhile yo…

> hidden O(n) situations How are these faster in imperative code?

They are usually not hidden, so they are at least easier to identify.
Post reply on HN