Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's functional programming all about? (2017)

lihaoyi.com

Post reply on HN
Print view View original

111–120 of 158 posts

Re: What's functional programming all about? (2017)

#111

Post by wruza »

Vinnl wrote: post #110
wruza wrote: post #104

It might look like a bit of a mess, but if you look carefully, you will see I “grasp” FP, but that pretty much sums up my experience with it. Half of its promises it delivers in the form of “you got used to read a multi-faceted inside-out mess”. I think FP is actually harmful, because it masks the fact we don’t properly teach regular programming.

While I agree that that's the case for the promises in many such tutorials, I think this article explicitly shows that that isn't inherent to the thing that FP is about. Your quote is specifically about the code formatted in such a way, with arrows drawn all over it, to match the box diagram. But if you look at the code as it would actually be written, in a functional style: def make_tiramisu(eggs, sugar1, wine, chee…

There’s nothing particularly FP about it though. A function taking a value and returning a new value is as “FP” as a good deed is “Christian”.

Re: What's functional programming all about? (2017)

#112

Post by ninetyninenine »

dxbydt wrote: post #69
ninetyninenine wrote: post #46

It’s hard to characterize what fp is. A lot of people think fp is a bunch of techniques like map, reduce, immutability or high level functions or monads. None of those things are exclusive to fp. They are just tricks developed by fp. Here’s how to get a high level characterization of what fp actually is: You know how in math and physics they have formulas? Formulas for motion, for area, etc. Functional programming is…

> Functional programming is about finding the formula for a particular program. Can be disproved trivially. Anyone can code up a program that generates the nth prime for some n, by iteratively accumulating n primes starting from 2 using trial division. otoh, an actual formula that produces the nth prime would be an earth shaking event.

Iteration doesn't exist in functional programming. If you ever used iteration in FP you're doing it wrong.

So I ask you... how does a functional program do the algorithm you ask for above?

Recursion and the ternary operator. All iterative programs can be written in recursion and vice versa.

Another way of thinking about this is rather then formula, think expression. Functional programming is about coding up an expression that can fit on one line.

Anything that breaks the program into multiple lines means you're turning your functional expression into a list of procedures.

Re: What's functional programming all about? (2017)

#113

Post by ninetyninenine »

dxbydt wrote: post #69
ninetyninenine wrote: post #46

It’s hard to characterize what fp is. A lot of people think fp is a bunch of techniques like map, reduce, immutability or high level functions or monads. None of those things are exclusive to fp. They are just tricks developed by fp. Here’s how to get a high level characterization of what fp actually is: You know how in math and physics they have formulas? Formulas for motion, for area, etc. Functional programming is…

> Functional programming is about finding the formula for a particular program. Can be disproved trivially. Anyone can code up a program that generates the nth prime for some n, by iteratively accumulating n primes starting from 2 using trial division. otoh, an actual formula that produces the nth prime would be an earth shaking event.

Hint: it's a recursive formula. There's a isomorphism

Re: What's functional programming all about? (2017)

#114

Post by magicalhippo »

fhasdfyuasd wrote: post #75
magicalhippo wrote: post #63

Earlier quoted context omitted.

While I agree, you can get all of that FP example from the article in say C++ by liberal const -usage. So is "const-y" C++ functional programming?

I think liberal const -usage breaks move optimizations so it's not used in practice.

Perhaps not these days, back in pre-C++11 days it was very liberally used. And something I miss in other languages, precisely because it allowed for much easier reasoning.

Re: What's functional programming all about? (2017)

#115

Post by Vinnl »

wruza wrote: post #111
Vinnl wrote: post #110

Earlier quoted context omitted.

While I agree that that's the case for the promises in many such tutorials, I think this article explicitly shows that that isn't inherent to the thing that FP is about. Your quote is specifically about the code formatted in such a way, with arrows drawn all over it, to match the box diagram. But if you look at the code as it would actually be written, in a functional style: def make_tiramisu(eggs, sugar1, wine, chee…

There’s nothing particularly FP about it though. A function taking a value and returning a new value is as “FP” as a good deed is “Christian”.

That's mostly a discussion about semantics, which isn't that interesting IMO. It demonstrates the use of pure functions that avoid side effects, and argues that this is how you can get some important benefits associated with functional programming without having to "read a multi-faceted inside-out mess".

If you have a definition of FP that intrinsically includes that mess, then sure, maybe that's harmful, but that seems orthogonal to the article in question.

Re: What's functional programming all about? (2017)

#116

Post by Reefersleep »

majoe wrote: post #92
yodsanklai wrote: post #35

As a programmer, I don't know if it's still relevant to make a strict separation between programming paradigms. You can use immutable types, pure functions, closures and so on in most languages. Conversely, you can define mutable types and imperative code in most functional programming languages. I'm always surprised reading comments on these topics, people saying they don't grasp FP. But don't we use higher-order fu…

True, the conceptual difference of (pure) functional and imperative programming is disguised by the many functional patterns most mainstream languages have absorbed. While these patterns are useful, there is more to say about pure functional programming. I recently gave a talk to some colleagues about that, which was divided into two parts: Practical functional programming patterns we can use today in our codebases (…

I don't understand the bit about the execution order, nor how it's relevant in your day-to-day programming.

Re: What's functional programming all about? (2017)

#117

Post by spratzt »

ryandv wrote: post #53
kh9sd wrote: post #51

Very nice article, I liked it a lot! It personally resonated with me and my own conclusion that the core "benefit" of FP is (for lack of a better work, stupid Bitcoin) "proof of work". Writing functions FP is essentially all about returning results from a function, which is proof that that a computation has occurred. If you don't have that return value, that proof, then obviously the rest of your code can't and shoul…

This is borderline nonsense.

You’re too kind. There’s nothing borderline about it.

Re: What's functional programming all about? (2017)

#118

Post by dxbydt »

ykonstant wrote: post #87
dxbydt wrote: post #69

Earlier quoted context omitted.

> Functional programming is about finding the formula for a particular program. Can be disproved trivially. Anyone can code up a program that generates the nth prime for some n, by iteratively accumulating n primes starting from 2 using trial division. otoh, an actual formula that produces the nth prime would be an earth shaking event.

There exist many formulas that encode the program you mentioned or other sieving methods, so it is unclear what you mean by "actual formula". See https://en.wikipedia.org/wiki/Formula_for_primes

I prefer to make a distinction between recurrence, identity, and formula. Otherwise the whole discussion is moot. For example, to compute the nth fibonacci, we have Binet’s formula. We don’t need to bootstrap - we just take the golden ratio and its conjugate, exponentiate, take the difference and scale by root 5. That’s a genuine formula. otoh If one says the nth fibonacci is just the sum of the previous two fibonaccis, that’s technically not a formula - you would need to bootstrap to get those previous ones, so that a recurrence - still very useful, but not a formula in the sense you can’t turn the crank and be done. In that specific sense, I agree with Wilf and Dudley that the procedures outlined by Mills, Wright, Wilson etc are essentially worthless as formulas. They are nice identities and recurrences, but not a genuine formula in that you can’t get the nth prime by turning the crank - you have to bootstrap with so many extraneous params it makes the whole exercise futile.

Re: What's functional programming all about? (2017)

#119

Post by codethief »

fhasdfyuasd wrote: post #77
deepsun wrote: post #72

Earlier quoted context omitted.

Yes, I feel you. As I said, we often need to sacrifice immutability to performance, and that's ok. If they insisted using immutable structures in high-performance applications, then functional programming won't help anyway.

Hopefully we won't have to make that trade off for too long https://www.microsoft.com/en-us/research/uploads/prod/2020/1...

Came here to write this.

There's also a (research) language that uses the Perceus algorithm: https://koka-lang.github.io/

Re: What's functional programming all about? (2017)

#120

Post by mbivert »

Reefersleep wrote: post #116
majoe wrote: post #92

Earlier quoted context omitted.

True, the conceptual difference of (pure) functional and imperative programming is disguised by the many functional patterns most mainstream languages have absorbed. While these patterns are useful, there is more to say about pure functional programming. I recently gave a talk to some colleagues about that, which was divided into two parts: Practical functional programming patterns we can use today in our codebases (…

I don't understand the bit about the execution order, nor how it's relevant in your day-to-day programming.

When you execute a function in a mainstream languages, the arguments are usually evaluated first, then the function is called with the result of that evaluation.

E.g. the following in JS will always print the confirm message. But in a lazy language like Haskell, as the x parameter is never used, it'll never be printed.

  (function(x) { return "bar"; })(confirm("foo"));
This can help with implementing things like infinite streams (e.g. iterate[0] in Haskell), which may be a pleasant patterns to solve some problems sometimes. On this example alone, I wouldn't qualify it as highly relevant for day-to-day work, but there may be more interesting use cases I'm not familiar with (I'd guess there might be interesting side-effects in concurrent settings).

[0]: https://hackage.haskell.org/package/base-4.20.0.1/docs/Prelu...

Post reply on HN