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

131–140 of 158 posts

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

#131

Post by deepsun »

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

Even reference counting needs memory management. Granted, allocations are very fast on the JVM heap, but cannot be faster than no allocations.

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

#132

Post by KolenCh »

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.

You are talking past each other on what formula means. In FP, a recursive function is a valid “formula”. P.S. I’m not arguing for that characterization.

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

#133

Post by mrkeen »

yCombLinks wrote: post #43

My problem usually appears when rather than clearly laying out the types of each returned value like in the article, all the FP guys I've worked with want to build giant chains that look like : return beat(whip(mix....(eggs)))

Likewise with the OO guys.

  Eggs.mix()
      .whip()
      .beat();
There's even a term for it - 'fluent API' - described as:

> Fluent API is a way of implementing object oriented API in a way that it provides readable code. [https://www.progress.com/documentation/sitefinity-cms/for-de...]

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

#134

Post by mrkeen »

Terr_ wrote: post #58

> Anything vertically separated can be done in parallel. This assumes no contention on a limited number of bowls or having only one kitchen tool for beating or whisking etc. :P I point that out not to demand that the metaphor be bulletproof, but because I think it may help explore something about state-handling and the FP/imperative split. How might this tiramisu-tree model change if we were limited to N bowls and 1…

You're describing (safe) locking of resources, best put forward by Dijkstra in 1965 as the Dining Philosophers problem.

I have yet to see a more practical, elegant solution than Haskell's STM for this: https://www.adit.io/posts/2013-05-15-Locks,-Actors,-And-STM-...

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

#135

Post by dumbo-octopus »

mrkeen wrote: post #125
bazoom42 wrote: post #100

Earlier quoted context omitted.

Callbacks are not the same as monads if that is what you are implying.

That's right, but only because it's a 1-to-many comparison error. Callbacks are one particular monad, not monads in general: https://jsdw.me/posts/haskell-cont-monad/

But then CPS machinery is often used to implement Monads.

> Programming with monads strongly reminiscent of continuation—passing style (CPS), and this paper explores the relationship between the two. In a sense they are equivalent: CPS arises as a special case of a monad, and any monad may be embedded in CPS by changing the answer type.

https://cs.uwaterloo.ca/~david/cs442/monads.pdf

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

#136

Post by marcosdumay »

gr4vityWall wrote: post #124
marcosdumay wrote: post #13

Earlier quoted context omitted.

It's possible that what makes functional languages easier to reason about and debug is the fact that they allow the types to capture a lot more information than the imperative languages. What would also explain why Prolog has none of those benefits. If you don't use the extra information, it can't do any good. But if it is really just that, it can be replicated over imperative languages. Anyway, Rust is evidence that…

Not disagreeing with you, though I'd say Rust syntax also feels very hard to understand most of the time. I think function signatures is something that I distinctly remember getting very complicated sometimes. Which is unfortunate, as I like the principles behind it. I wonder if someone will ever write a Rust-like language that has a syntax closer to Java or Haxe.

Oh, Rust type signatures are harder to use than even Haskell.

But that's because there are a lot of low level detail that must go into them. Most of the complexity that C developers tend to ignore (and create wrong programs) goes there, explicitly. If you don't want the detail, you can make them simpler.

That said, I have a long rant about how Haskell-like types ignore the entire "algebra" thing from algebraic types, and could be way more expressive and simpler to use.

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

#137

Post by ninetyninenine »

mrkeen wrote: post #126
roenxi wrote: post #68

Earlier quoted context omitted.

There is an interesting trend where things with a strong mathematical definition tend to have the advantage. "Functional Programming" doesn't have a precise definition at all as far as I know, so it is likely it doesn't refer to a real thing. Most of the paradigms are similar as they don't seem to actually mean anything. People seem to want to describe something (in today's article, data flow) but they don't quite ha…

Here's a good enough definition: "The same input yields the same output". > "functional programming is a programming paradigm where programs are constructed by applying and composing functions" This is only seems like a useless truism if you take 'function' to mean 'method' or 'procedure'. If you nail down 'function' to sameinput->sameoutput then it starts to make more sense.

No. You missed it the meaning. The paradigm is referring to the fact that the ENTIRE program must be constructed this way.

So let's say you have this in your code:

   x = 1
   b = x + 2
   x = b + x
You have composed three procedures here in order. This is illegal. You must ONLY construct the programs via composing functions there can be no other way.

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

#138

Post by ninetyninenine »

culi wrote: post #70
roenxi wrote: post #68

Earlier quoted context omitted.

There is an interesting trend where things with a strong mathematical definition tend to have the advantage. "Functional Programming" doesn't have a precise definition at all as far as I know, so it is likely it doesn't refer to a real thing. Most of the paradigms are similar as they don't seem to actually mean anything. People seem to want to describe something (in today's article, data flow) but they don't quite ha…

It's funny you say that because I'd say FP has a much more well defined mathematical foundation compared to OOP. In fact, before it became as dominant as it is today, it was often criticized as being too scholarly and theoretical. It's built mostly on the foundations of Lambda Calculus (and maybe some Type Theory). I don't think OOP ever had nearly as strong of a mathematical/scholarly foundation as FP has

FP is math. There's not much distinction. The language of math is FP.

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

#139

Post by ninetyninenine »

kelnos wrote: post #64
gr4vityWall wrote: post #6

The article itself was well written, although I'd appreciate if the author was more "to the point" with the examples. FP never resonated with me and never fit the mental model I have for programming. I tried learning Prolog and Haskell a few times, and I never felt like I could reason about the code. This line from the article: "[..] With functional programming, whether in a typed language or not, it tends to be much…

I think I find a lot of FP code harder to both write and read (even code I've written myself), but when the FP code is written and compiles, it is much more likely to be correct. It's an annoying trade off, to be sure. With a language that makes writing FP code ergonomic and idiomatic, though, I'm usually going to choose to write that way. But even in languages where writing in an FP style is a chore (if it's even po…

>I think I find a lot of FP code harder to both write and read (even code I've written myself), but when the FP code is written and compiles, it is much more likely to be correct.

You're probably thinking about haskell. It's like this because of the type checking combined with the FP makes haskell especially robust.

That being said FP is programming nivana. The FP function is the most modular unit of computation in CS. By writing an FP program composed of functions you have broken down all sections of your program into the smallest form by definition.

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

#140

Post by hollerith »

ninetyninenine wrote: post #137
mrkeen wrote: post #126

Earlier quoted context omitted.

Here's a good enough definition: "The same input yields the same output". > "functional programming is a programming paradigm where programs are constructed by applying and composing functions" This is only seems like a useless truism if you take 'function' to mean 'method' or 'procedure'. If you nail down 'function' to sameinput->sameoutput then it starts to make more sense.

No. You missed it the meaning. The paradigm is referring to the fact that the ENTIRE program must be constructed this way. So let's say you have this in your code: x = 1 b = x + 2 x = b + x You have composed three procedures here in order. This is illegal. You must ONLY construct the programs via composing functions there can be no other way.

Not so fast. This next is legal Haskell:

  let x = 1
      b = x + 2
      x = b + x
  in
The third line creates a second binding of x which shadows the first binding, and shadowing is considered by most people to be within the functional paradigm. What is not considered functional by most people is assigning a variable in a loop although even here you can do it in Haskell. Specifically, you can call readIORef and writeIORef every loop iteration, but last time I tried, that was about 1000 times less efficient than in an imperative language.
Post reply on HN