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

151–158 of 158 posts

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

#151

Post by vilunov »

kelnos wrote: post #62
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 don't think we should think of things as having a strict separation, but certainly some languages push you harder than others toward certain programming paradigms, and some make other paradigms difficult or awkward to use. For example, while I can do FP in Rust, I would not really call Rust a FP language. It does have some features that make doing FP possible, but a lot of the code I see (and write) is a mix of imp…

For-comprehensions are actually not functional programming, their raison d'etre is to embed traditional imperative programs in expression-based referenetially transparent FP programs.

I think if Rust had Scala's for-comprehensions, it would be a strictly worse language than it is now. FP langs' do- and for-comprehensions are highly unergonomic, not least due to all the ways it could be overloaded. Haskell has tons of extensions, Scala's is basically desugaring to flatMap calls. This has a lot of abuses in the wild, and with how it depends on implicits causes practical problems when you write that code.

Scala's new wave of direct syntax and general direction from Monads to algebraic effects is more sane in how it presents compiler messages, and opens ways to have better performance.

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

#152

Post by vilunov »

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.

Async-await in Rust isn't a Monad.

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

#153

Post by LegionMammal978 »

roenxi wrote: post #147
LegionMammal978 wrote: post #121

Earlier quoted context omitted.

> Conspicuously absent in that thought is an alternative way to interpret "is based on". "Has designers who consciously adopted significant ideas from" seems good enough for me.

That is a path-dependent property though. So if we interpret it that way we can't tell if a language is based on lambda calculus without interviewing the author. Indeed, the definition admits that we could have two almost identical languages but only one of them is based on lambda calculus. I don't think it is a reasonable way to interpret "is based on", it requires too much knowledge of history. It is more proper to…

C'est la vie: it's always going to be a very fuzzy concept when applied, short of broadening it until it's unrecognizable. Not every property of a thing needs to be perfectly decidable with no room for guesswork.

To put it pithily, "This popular notion is provided 'as is', without warranty of any kind, express or implied, including but not limited to fitness for a particular purpose." If you really want a property that's fully intrinsic, I'd suggest disregarding fuzzy 'based on'-ness and instead considering some particular aspect you care about, e.g., "How difficult is it to express such-and-such a technique in this language?"

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

#154

Post by mrkeen »

explaininjs wrote: post #148
bazoom42 wrote: post #145

Earlier quoted context omitted.

So having Promises be monads would make them less useful? This is an interesting point. It seems to confirm the argument that monads are not that useful or pervasive outside of Haskell.

We might consider promises “applied monads” or “engineered monads”. Monodic in inspiration and they solve the same core problem, but they aren’t straightjacketed into the ivory tower “laws” in absolutely every edge case (they do satisfy them in the vast majority of cases). Which is good, because it means we never need to write things like “await await await await await foo()”

> Which is good, because it means we never need to write things like “await await await await await foo()

But what your describing is the actual value proposition of monad though! It's literally the construct you use to avoid excessive unwraps.

Look at the type signature of bind:

  m a -> (a -> m b) -> m b
It returns m b. Not m (m b). Not m (m (m b)).

> but they aren’t straightjacketed into the ivory tower “laws” in absolutely every edge case

In other words, you can't abstract over them. If you have libraries that manipulate monads, they will be incompatible or buggy, because they will assume (by design) behaviour that a non-monad will not live up to.

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

#155

Post by explaininjs »

mrkeen wrote: post #154
explaininjs wrote: post #148

Earlier quoted context omitted.

We might consider promises “applied monads” or “engineered monads”. Monodic in inspiration and they solve the same core problem, but they aren’t straightjacketed into the ivory tower “laws” in absolutely every edge case (they do satisfy them in the vast majority of cases). Which is good, because it means we never need to write things like “await await await await await foo()”

> Which is good, because it means we never need to write things like “await await await await await foo() But what your describing is the actual value proposition of monad though! It's literally the construct you use to avoid excessive unwraps. Look at the type signature of bind: m a -> (a -> m b) -> m b It returns m b. Not m (m b). Not m (m (m b)). > but they aren’t straightjacketed into the ivory tower “laws” in ab…

I should not need to explain to you that the problem is when b itself is internally an (m b’). Or when it is a sum of many types, of varying m-nests.

I can assure you that JS libraries work with Promises just fine.

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

#156

Post by tome »

ahf8Aithaex7Nai wrote: post #150
tome wrote: post #144

Earlier quoted context omitted.

> main is never pure. Your `procedure` is also not pure Ah, it's possible I misunderstood you. I missed that you said "Purely functional languages force you to program this way by default". I mistakenly assumed you were saying that in a purely functional language you can only program purely. So you are saying that Haskell is a pure functional language, but you can also write non-pure things in it? So being a "pure la…

This will be a bit more detailed. I apologize in advance. > So being a "pure language" is more a case of what sort of style is encouraged rather than what sort of style is possible? The crucial point is that the (potentially) impure code is clearly and explicitly differentiated from pure code (IO code vs. non-IO code. Haskell uses the type system to draw this distinction. >> (and also not referentially transparent) >…

> This will be a bit more detailed. I apologize in advance.

No need to apologize. Thank you for your detailed response!

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

#157

Post by acchow »

bazoom42 wrote: post #141
mrkeen wrote: post #125

Earlier quoted context omitted.

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/

Promises in JavaScript are not monads as far as I can tell. While they have a somewhat similar interface, they do not appear to obey the monad laws.

I was not actually thinking of Javascript (or any particular language) when I mentioned async-await. I was just referring to the concept.

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

#158

Post by acchow »

__MatrixMan__ wrote: post #78
fire_lake wrote: post #44

Earlier quoted context omitted.

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.

One thing that struck me while learning nushell is that instead of: $ echo "hello world" hello world I can do: $ "hello world" hello world Is this an indication that it is expression oriented? (just checking that I've understood the phrase).

Yes.

Essentially, statements have no value (or return no value). Expressions have a value.

Post reply on HN