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

41–50 of 171 posts

Re: Functional programming is finally going mainstream

#41

Post by ebingdom »

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 is a really uninformed opinion. I'm disappointed that it's currently the top comment.

You really think functional programmers don't build composite types?

Re: Functional programming is finally going mainstream

#42

Post by riku_iki »

Koshkin wrote: post #13
WkndTriathlete wrote: post #11

Earlier quoted context omitted.

> Copying memory around to enable to facilitate these immutable structures is SLOW. "Optics". No one writing serious FP code copies memory around willy-nilly.

No, but the compiler may do it for you.

why it would copy and not be passing immutable data by reference?

Re: Functional programming is finally going mainstream

#43

Post by gnulinux »

stickfigure wrote: post #36
GuB-42 wrote: post #16

Earlier quoted context omitted.

The biggest problem I have with functional programming is debugging. On imperative code, execution is easy to follow. Instructions go one after the others, loops loop, function calls and local variables go on the stack, globals are always visible. Optimization aside, what you code is what the computer runs. You often have a debugger to step through your code, or some logging facilities, even if it is just a printf. O…

This isn't my experience at all. Imperative code with side effects is harrowing to debug because it may do different things depending on what execution path got you there. Pure functions are easy to debug. Run it, check the result against expectations. Step in if necessary.

I think this comes down to experience. My favorite programming language is Agda and I have a lot experience writing code in Haskell and Lisp variants. I personally also find it trickier to debug in functional languages. I believe this comes down to how you debug: I am comfortable using a debugger for debugging but I simply find it easier to debug using prints (for context switching reasons) but this is not always an option in a purely functional context without any IO. This does push me out of my comfort zone sometimes, and I would say it's accurate that I debug much faster in imperative languages. Even though I write better and safer code in functional languages (and even though I like them better).

Re: Functional programming is finally going mainstream

#44

Post by LAC-Tech »

stickfigure wrote: post #39
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()

Furthermore, it chains nicely and offers pleasant autocompletion in your IDE: newObject = oldObject.f().g().h().i().j().k() VS newData = k(j(i(h(g(f(oldData))))))

Just to steel man the "Functions and Data" side of the equation in a lot of FP languages that'd be something like

    newData = oldData |> f |> g |> h |> i |> j |> k

Re: Functional programming is finally going mainstream

#45

Post by gnulinux »

anon_d wrote: post #18
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…

Functional programming doesn't actually compete with imperative programming. In practice, functional programming is a way of organizing imperative programs. Kind of like how OO is a way of organizing imperative programs. Almost all applications written in Haskell use the IO monad quite a bit, for example. Large Haskell projects generally use a lot of C libraries, and sometimes even directly include C code for perform…

I think part of the problem is no implementation has an exciting story about writing the "shell" part in a different language. I love love love writing purely functional code. Probably my favorite thing to do. But what a lot people who also like functional programming are missing is writing imperative code in functional languages almost invariably sucks. At the end of the day we all have to write the "shell" part of our Haskell programs, and my programs always end up in a horrific mess of IO, State and other monads.

Re: Functional programming is finally going mainstream

#46

Post by charlieflowers »

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…

Have you seen the AWS go sdk? It basically builds linked lists (no locality) of everything and marshals to and from json over and over like it's free. I mean there's no thought whatsoever to making efficient use of memory, getting locality for improved performance, etc.

And if you think about it, most things using the aws sdk are network i/o bound anyway, which is probably why they burn ram and generate garbage like it's free.

So immutable data structures (especially persistent ones) aren't a problem at all in many domains.

Re: Functional programming is finally going mainstream

#47

Post by zumu »

stickfigure wrote: post #39
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()

Furthermore, it chains nicely and offers pleasant autocompletion in your IDE: newObject = oldObject.f().g().h().i().j().k() VS newData = k(j(i(h(g(f(oldData))))))

Chaining is one way of making function composition more ergonomic, but there are others. Functional languages tend to have an operator (e.g. |> in Elixir. Think x |> f() |> g() |> h() |> i(), etc.) that gives the same benefits of chaining, but the functions don't have to be methods providing greater flexibility.

Re: Functional programming is finally going mainstream

#48

Post by timbit42 »

chaostheory wrote: post #17

I thought it was already mainstream based on features of long popular languages. Features that debuted about a decade ago.

Most of these languages are functional-ish, meaning they have some capabilities derived from purely functional languages, but they don't have all of the features or power.

Re: Functional programming is finally going mainstream

#49

Post by mbrodersen »

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…

Well written compilers for functional programming language do not copy immutable data. I recommend searching for “Immutable Data Structures” to see how you can implement very high performance immutable data structures. Haskell and Closure (for example) does this and Haskell is faster than most imperative languages out there. I recommend learning more about this subject.

Re: Functional programming is finally going mainstream

#50

Post by jayd16 »

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…

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.

Post reply on HN