[HN Gopher] Functional programming is finally going mainstream
___________________________________________________________________
Functional programming is finally going mainstream
Author : BerislavLopac
Score : 38 points
Date : 2022-07-12 15:28 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rvieira wrote:
| 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...
| dolni wrote:
| 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 enable to facilitate these immutable
| structures is SLOW.
| mholyland wrote:
| Are you considering the speed of persistent data structures,
| that have the same big-O as their mutable counterparts? [0]
|
| 0. https://en.wikipedia.org/wiki/Persistent_data_structure
| Avshalom wrote:
| Algorithmic complexity isn't the same as speed.
| mholyland wrote:
| True. My use of the word "speed" is incorrect, or at least
| imprecise.
|
| The parent comment claimed that immutable data structures
| are slow, because you would have to copy them around, an
| O(N) operation.
|
| I wanted to know if they considered that operations on
| immutable structures can be done without copying, and have
| the same algorithmic complexity as the mutable data
| structures, if they used persistent data structures.
| pjmlp wrote:
| 1. Mainstream FP languages have modules and OOP support as
| well.
|
| 2. Immutable structures aren't immutable at the runtime level,
| https://en.wikipedia.org/wiki/Persistent_data_structure
| jjtheblunt wrote:
| > 2. Copying memory ...
|
| the entire point of some of the immutable structures is hidden
| in their implementations, such that they are fast exactly
| because they do NOT copy unnecessarily. the side effect gets
| called "functional", so there's a strange reversal of
| importance of (kinda misleading) buzzwords at play here.
|
| The link(s) the others shared is a great article.
| miloignis wrote:
| 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 Koka,
| had Koka's functional and persistent Red-Black tree 10%
| _faster_ than the handwritten C++ version (std::map) [0], and
| the Roc language has a purely functional quicksort version
| competitive with standard imperative languages.
|
| So it seems we can have out cake and eat it too!
|
| [0] - https://www.microsoft.com/en-
| us/research/uploads/prod/2021/1...
| pyuser583 wrote:
| Koka-lang and Roc-lang? What are those?
| miloignis wrote:
| https://koka-lang.github.io/koka/doc/index.html
|
| https://www.roc-lang.org/
|
| Both working on making functional programming practical and
| very fast. Koka is more of a research language, also
| developing Algebraic Effects and making them practical,
| which is very cool.
| WkndTriathlete wrote:
| > Copying memory around to enable to facilitate these immutable
| structures is SLOW.
|
| "Optics". No one writing serious FP code copies memory around
| willy-nilly.
___________________________________________________________________
(page generated 2022-07-12 23:02 UTC)