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

41–50 of 158 posts

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

#41

Post by Dansvidania »

gleenn wrote: post #28
iLemming wrote: post #19

Earlier quoted context omitted.

Same can be said about Clojure. Although Clojure usually described as an FP-language, it's not "purely FP". In general, I find that Lispers typically don't concern themselves with the popularity of certain tools or techniques; They don't care for things like MSFT marketing shoveled in your mouth. Die-hard pragmatists, they'd use an instrument if it makes sense. They don't give two shits about OOP propaganda or extrem…

As a dyed-in-the-wool Clojurist, I appreciate leveraging the functional aspects as much as immutable by default data structures. It takes a while to stand back and realize, but once you have a large program that is mostly all passing immutable hashmaps all around to static functions, testing becomes soo much easier and reasoning about how all the code is glued together becomes far easier. You know with certainty that…

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.

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

#42

Post by iLemming »

gleenn wrote: post #28
iLemming wrote: post #19

Earlier quoted context omitted.

Same can be said about Clojure. Although Clojure usually described as an FP-language, it's not "purely FP". In general, I find that Lispers typically don't concern themselves with the popularity of certain tools or techniques; They don't care for things like MSFT marketing shoveled in your mouth. Die-hard pragmatists, they'd use an instrument if it makes sense. They don't give two shits about OOP propaganda or extrem…

As a dyed-in-the-wool Clojurist, I appreciate leveraging the functional aspects as much as immutable by default data structures. It takes a while to stand back and realize, but once you have a large program that is mostly all passing immutable hashmaps all around to static functions, testing becomes soo much easier and reasoning about how all the code is glued together becomes far easier. You know with certainty that…

I know, right? It may feel weird at first - with immutability, parentheses and prefix notation, but once you grok REPL-driven interactivity and structural editing - so much about programming becomes intuitively simpler.

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

#44

Post by fire_lake »

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…

Mainstream languages are not expression orientated like true FP languages are. Most people working in mainstream languages aren’t aware of the significance of this and wonder why FP seems awkward in their language, despite it having closures, some immutable types, etc.

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

#45

Post by bazoom42 »

acchow wrote: post #37
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…

Monads are pervasive: async-await. We just don’t call them monads.

How is async-await monads? Isn’t it just syntax sugar over callbacks?

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

#46

Post by ninetyninenine »

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 about finding the formula for a particular program.

Typically when you code you write an algorithm for your program. In functional programming you are writing a formula. Think about what that means.

The formula has side effect benefits that make it easier to manage complexity and correctness. That’s why people like it. These side effects (pun) are not evident until you programmed with fp a certain amount.

Obviously though people naturally reason about things in the form of procedures rather then formulas so fp tends to be harder then regular programming.

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

#47

Post by ryandv »

bazoom42 wrote: post #45
acchow wrote: post #37

Earlier quoted context omitted.

Monads are pervasive: async-await. We just don’t call them monads.

How is async-await monads? Isn’t it just syntax sugar over callbacks?

Consider async-await a syntactic sugar over Promises (from JavaScript). Then, Promises constitute an instance of the Monad typeclass where monadic `bind` or (>>=) is `Promise.then()`, and `return` is `Promise::resolve()`.

Here is a translation of a modification of the example given in [1]:

    const promise1 = Promise.resolve(123);

    promise1.then(v => v * 2).then((value) => {
      console.log(value);
      // Expected output: 246
    });
into Haskell:

    ghci> let promise1 :: IO Int = return 123
    ghci> promise1 >>= (return . (* 2)) >>= print
    246
One key discrepancy worth pointing out is that in the `Promise.then()` API of JavaScript, the function provided to `then` (e.g. `v => v * 2` above) is implicitly composed with a call to `::resolve` in order to turn that function's pure return value, the `Number` 246, into a Promise resolving into the `Number` 246; in Haskell, this operation must be made explicit (hence the composed function `return . (* 2)` passed to the first application of (>>=) or `bind`).

You could say that the instance method `Promise.then()` expects an argument of type (a -> b), with the return value of type `b` being implicitly and automatically wrapped into a Monad `m b`, whereas Haskell's bind expects an argument of type (a -> m b) on that operator's right-hand side, with the return value explicitly wrapped into a Monad `m b` by the provided function argument itself.

[0] https://wiki.haskell.org/Monad

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#49

Post by agumonkey »

vundercind wrote: post #26
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’ve wondered for some time how this breaks down along preferences for math vs (human) language, or for proofs/formula thinking vs algorithmic. I find FP concepts easy enough to grasp (provided they’re not demonstrated in e.g. Haskell) and even adjacent stuff like typeclasses or monads or what have you aren't a stumbling block, and I'm plenty comfortable with stuff like recursion. … but I'm firmly on the language-is-…

To it wasn't really math, even though there was some of that, it was about the amount of concepts and devices that have to work together.

Ability to reason about expressions means everything can be run and have a result without side effects (unless you allow, say, lisp effectful builtins). The fact that everything is built around function means you can always unplug or compose them. All this with a very reduced set of ideas and syntax (at least for the core)

On the other hand most imperative languages required you to pay attention to state, which is rapidly a mental dead end, with a lot more ceremony and syntax. At least before the 2010s .. nowadays everybody has expression oriented traits and lambdas.

After learning ml/haskell and doing interesting things with a kind of clarity.. I tried going back to c/python and suddenly a lot of errors, issues and roadblocks started to appear.

Then you have the parallel case.

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

#50

Post by iLemming »

Dansvidania wrote: post #41
gleenn wrote: post #28

Earlier quoted context omitted.

As a dyed-in-the-wool Clojurist, I appreciate leveraging the functional aspects as much as immutable by default data structures. It takes a while to stand back and realize, but once you have a large program that is mostly all passing immutable hashmaps all around to static functions, testing becomes soo much easier and reasoning about how all the code is glued together becomes far easier. You know with certainty that…

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 a band-aid (or something). Except, with Haskell, there's no rigid structure, there's no single, proven, 100% guaranteed path to glory - it's all blur. There's no "10 steps to build a website with Haskell". And then I picked up Clojure, and OMG! everything suddenly started making so... much... sense... All the things in Haskell, for which I had either no clue or had some shallow understanding - that all became so much more intuitive.
Post reply on HN