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

111–120 of 171 posts

Re: Functional programming is finally going mainstream

#111

Post by deltaonenine »

GuB-42 wrote: post #16
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…

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…

>I love pure functions, but in the end, I think it is just a tool. A solution to a set of problems,

I'm tired of seeing this analogy everywhere. Everyone knows it, there's nothing new here. When we talk about things like FP or OOP, the real opinions live at the extremes. Where one tool is definitively better than another tool or where some tools are complete garbage.

Saying that everything is a tool for different things or it's all apples and oranges says nothing about anything.

Re: Functional programming is finally going mainstream

#112

Post by singularity2001 »

vanjajaja1 wrote: post #80
LAC-Tech wrote: post #44

Earlier quoted context omitted.

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

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

this has nothing to do with OO, function chaining depends on the output of the previous function regardless

Re: Functional programming is finally going mainstream

#113

Post by singularity2001 »

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…

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!

Re: Functional programming is finally going mainstream

#114

Post by deltaonenine »

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

I don't think this is accurate at all. Debugging in a strict FP language is pretty much exactly like debugging in an imperative language. Debugging in a lazy FP language requires somewhat different approaches, but still does not have the problems you are implying here. > In the end, the result is wrong, good luck finding where. This is not true. If this was true, nobody would be able to build significant things in FP…

I like FP but debuggers fail with FP because debuggers are imperative tools. There's a definite miss match in both UI and concept. It's not the fault of FP itself, it's more the fault that we haven't come up with such an interface yet.

If you want an FP debugger the interface has to be able to step by step evaluate an expression. Since FP is just a giant expression, how is it evaluated step by step? Break points will be different and stepping through it will be different as well.

Take for example:

    (1 + 2) * 3 + 2
Stepping through it with a debugger would look like this (imagine the expression transforming at each step):

    (1 + 2) * 3 + 2
    (3) * 3 + 2
    9 + 2
    11
A break point would look like this (square brackets indicate a GUI marker)

    (1 + 2) + [(4 * 6)] + 1
A run until breakpoint will evaluate to this:

     (3) + [(4 * 6)] + 1
That's it. Debugging FP is about stepping through expressions. Debugging Imperative programming is about stepping through statements. And the unique thing about "stepping" through an expression is that the expression is getting reduced (aka changing) at every step.

You need a complete UI overhaul for FP to work. This tends to be harder in terms of building a UI, because text by nature is a one to one mapping to procedural instructions as text Lines are equivalent to instructions. However for FP everything can basically be on one line, so text doesn't really fit and thus you actually need a more dynamic UI for a proper FP debugger.

Re: Functional programming is finally going mainstream

#115

Post by deltaonenine »

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…

2. Copying memory around to enable to facilitate these immutable structures is SLOW.

This is categorically wrong. You actually don't know what you're talking about.

In an functional programming language, because everything is immutable, the compiler just MOVES everything around. There is ZERO copying in a functional programming language. In fact there's no explicit command for it either. There is zero reason for you to copy a variable that is immutable so there's no copy() function.

What you're referring to is more of what happens when someone is writing functional code in a language that's not functional.

Re: Functional programming is finally going mainstream

#116

Post by ChrisRackauckas »

singularity2001 wrote: post #113
LAC-Tech wrote: post #28

Earlier quoted context omitted.

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…

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

Re: Functional programming is finally going mainstream

#117

Post by xigoi »

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

You can have the chaining syntax without object-orientation, like in Nim, D, Koka, VimScript, …

Re: Functional programming is finally going mainstream

#118

Post by xigoi »

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…

Check out HVM, an experiment to make copying immutable data really fast: https://github.com/Kindelia/HVM

Re: Functional programming is finally going mainstream

#119

Post by spacetraveler11 »

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 approach but the end result is usually worth it. That said, FP can become a complex mess if your engineers are too dogmatic about it and bringing on new people who aren't as much into FP is almost impossible then in my experience.

Re: Functional programming is finally going mainstream

#120

Post by benrbray »

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…

Can you give any examples of useful non-terminating programs?

It seems to me all useful programs are terminating (or, we truncate some non-terminating procedure by some convergence criteria). The question is only whether we have the logical tools to prove termination at compile time.

Post reply on HN