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

51–60 of 158 posts

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

#51

Post by kh9sd »

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 shouldn't continue, and FP makes it obvious compared to more traditional imperative approaches.

And this idea extends into so many other things that people consider core, or at least originating from FP. Result/Option types come to mind, making the possible failure of "proof of work" explicit in the type signature, so people are forced to consciously handle it. It also leads into the whole idea of type driven design, one of my favorite articles, "Parse, don’t validate"[1], describes this as well, making types that clearly restrict and set the expectations needed for the "proof of work" to always be returned from a function.

[1] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

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

#52

Post by SatvikBeri »

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…

I wouldn't think of paradigms as strictly separate, but there are definitely clusters of related techniques that go well together. Higher order functions work best with immutability and pure functions, and struggle without them. Currying is somewhat useful by itself, but much more valuable with function composition or HOFs.

It's also important to teach the techniques together because functional programming tools are typically (deliberately) less powerful, which makes them easier to analyze, but means you need more tools.

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

#53

Post by ryandv »

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.

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

#54

Post by Barrin92 »

wk_end wrote: post #23
Barrin92 wrote: post #14

Earlier quoted context omitted.

>One of the foundational building blocks of FP is the closure Yes, because the closure solves a problem in functional programming by injecting a bit of OO . Closures are just stateful function objects with a single call method operator where the local context serves the same purpose as private variables in an object. It's exactly because FP otherwise lacks the coupling of data and methods that closures are so importa…

If paradigm A is defined, in part, by a particular concept that was created wholly independently of paradigm B, even if that concept has some analogs in paradigm B, it's a real stretch to say that it's merely "injecting a bit of" paradigm B into paradigm A. A more parsimonious ontology is that there's an underlying concept shared by both paradigm A and paradigm B, and that you're making your cut in the wrong place -…

> it's a real stretch to say that it's merely "injecting a bit of" paradigm B into paradigm A.

Not at all. Leibniz and Newton both invented the same thing independently, calculus, even though each probably called it something else. The reason why this whole discussion is so confused is because people tend to do what you proposed, which was argue from the top down by association. We say ML is "functional", ML contains closures, closures encapsulate state and behavior, therefore that's "functional programming". But that's like saying, Python is "object oriented", X is in Python, therefore that's object oriented programming. Which is of course not true, you can write functional code in Python just fine.

If we want a real ontology we've got to look at what structures in a program do, regardless of language. Closures behave like objects, modules that you brought up are basically just static classes. In fact the Ocaml manual gives a good example of how classes, modules and objects can be expressed in interchangeable ways (https://ocaml.org/manual/5.2/advexamples.html). There's a reason that Ocaml is a fairly logical extension of Caml, it didn't suddenly become the ontological opposite because you added the O to it.

Working up from clear conceptual differences I think also leads to a much more sensible conclusion, which is that a lot of languages combine both functional and object oriented features and that labelling an entire language as either one is just wrong.

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

#55

Post by myth2018 »

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

Mine too. I've worked for a shop adopting this practice some time ago. A very common pattern was to declare a relatively large Python dictionary with function calls and list comprehensions nested deep in the dict [sub]properties. Nice to glance, terrible to debug and reason about.

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

#56

Post by Dansvidania »

iLemming wrote: post #50
Dansvidania wrote: post #41

Earlier quoted context omitted.

I have the same experience. I learned Haskell because of the aura of prestige around it, and must admit I still love the syntax, but moved over to Clojure as my daily-driver as the practicality of "just use maps" is incredible. IMO the article misses the point there. Immutability is the "thing" in FP.

Yes! I spent months (maybe even years) trying to understand Haskell, and for the love of god, I just couldn't wrap my head around so many things. I just wanted to build stuff with it, but it felt like becoming a doctor - getting a bachelor's, passing MCAT, then four years in medical school, then residency program, then getting a license and a board certification. All that for the sake of knowing how to properly apply…

It definitely took me at least 3 years of reading and practicing to be able to get to -at least think- understand it, and I still think I would be considered pretty incompetent by people that do Haskell daily.

There is no doubt in my mind that the Purity concept in Haskell is taken to an impractical degree. I happen to like it, but it does not make developing software with it any less of a troubled experience. The defining concept in comparing Haskell and Clojure for me is the pareto principle :D Clojure gets 80+% of the way there, without 80% of the self flagellation.

There is also a consideration of static typing vs dynamic but that's a whole other can of worms.

Simply, in Haskell all mutability is delegated to the runtime while in clojure one has the freedom and responsibility to manage it directly, and boy does it gain in simplicity for it!

I know I am preaching to the choir but it's pleasant to find a similar experience and share thoughts!

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

#57

Post by smrtinsert »

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…

Most js code bases I see (frontends typically in react) have only a basic sense of functional programming/closures. It is a massive paradigm shift to move to clojure from where modern js is today. It was probably less so in the jquery days funny enough

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

#58

Post by Terr_ »

> 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 beater and 1 whisk, unable to treat them as statelessly-shareable or endlessly-duplicable?

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

#59

Post by carapace »

lihaoyi wrote: post #3

Author here. This blog post is actually kind of funny; I had a flash of clarity one afternoon that wouldn't go away so I spent 8 hours in a manic frenzy banging it out in one pass with no editing. Not how most of my writing happens (typically its a tedious slog with multiple passes of editing and refinement) Anyone who likes this article on my blog should check out this presentation on applying this philosophy to bui…

Have you read Backus' original FP paper "Can programming be liberated from the von Neumann style?: a functional style and its algebra of programs"?

https://dl.acm.org/doi/10.1145/359576.359579

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

#60

Post by binary132 »

lihaoyi wrote: post #3

Author here. This blog post is actually kind of funny; I had a flash of clarity one afternoon that wouldn't go away so I spent 8 hours in a manic frenzy banging it out in one pass with no editing. Not how most of my writing happens (typically its a tedious slog with multiple passes of editing and refinement) Anyone who likes this article on my blog should check out this presentation on applying this philosophy to bui…

Hi Li, appreciate your work. How do you feel the state of Scala is these days? I took the EPFL intro on Coursera years ago, but I was always disappointed by two things: the community feels very fragmented outside of IDEA (RIP ENSIME — oh, is it back now?), and it seems like Spark completely overwhelms the rest of the Scala ecosystem. I’ve mostly moved on these days but still think fondly of it from time to time.
Post reply on HN