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

121–130 of 158 posts

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

#121

Post by LegionMammal978 »

roenxi wrote: post #98
LegionMammal978 wrote: post #84

Earlier quoted context omitted.

In that sense, every programming language (as well as lambda calculus) is based on Java, since Java is a universal model of computation. So I don't think it's very useful to take "is based on" to be as broad as "is interpretable using".

Conspicuously absent in that thought is an alternative way to interpret "is based on". Because I suspect that in most senses that FP is based on lambda calculus we probably can claim it is also based on a subset of Java. Everything useful is multi-paradigm these days, programming paradigms turned out to not be a useful lens for developing useful programming languages.

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

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

#122

Post by ahf8Aithaex7Nai »

tome wrote: post #109
ahf8Aithaex7Nai wrote: post #102

Earlier quoted context omitted.

> Functional Programming” doesn't have a precise definition at all It may be that different people mean different things when they talk about FP. I come from the Haskell corner and from my point of view that's a completely insane claim, at least when it comes to pure FP. [ ] Are you writing a procedure that just processes its arguments into a return value? [ ] Does the procedure also operate on a non-static context?…

I also come from the Haskell corner and I agree with roenxi. I don't think that FP is a well-defined concept, nor do I understand your characterization of pure FP. Let's take a simple program main = do v and have a look at the conditions you laid out * Are you writing a procedure that just processes its arguments into a return value? No, it has no arguments and its return value is just (), but it does more besides. *…

main is never pure. Your `procedure` is also not pure (and also not referentially transparent). You can write impure code in Haskell, which your example demonstrates very well. But then it is necessarily IO code. Non-IO code, on the other hand, is always pure (and referentially transparent).

> but I don't see that that changes anything

It changes everything, but I can't explain it any better than I did above.

> So what is it that makes Haskell a pure functional language and Python not?

If you give me a Haskell procedure `f1 :: Int -> Int` without showing me the content, I still know that it is referentially transparent and pure. If f1 evaluates x to y once, I know that it ALWAYS evaluates x to y. If a main program in which f1 is used generates a screen output, for example, I can safely exclude f1 as the source of this side effect. If you give me a function `f2 :: Int -> IO Int` instead, I can't draw all these conclusions. In Python, these conclusions would be invalid from the start.

Now you can say, “So what? Who cares?” But it helps me enormously when designing and structuring programs, understanding programs, localizing program behavior, etc. If you don't see any added value in this distinction (ensured by the compiler), we don't have to argue about it. But I simply cannot agree with you that this does not represent a conceptual and formally justified difference between Haskell and Python.

Of course you can program purely functionally in Python. Just as you can program in a dynamically typed language as if you were dealing with static data types. Or in Java without throwing exceptions and null references around everywhere. Or in C without segmentation faults.

These are not normative or moral comparisons, but other examples of the fact that you can of course program in such a way that the code has certain properties, even if the compiler does not secure these properties. The question is whether you want that.

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

#123

Post by ninetyninenine »

dxbydt wrote: post #118
ykonstant wrote: post #87

Earlier quoted context omitted.

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 fibonacc…

Definition of formula does not preclude recurrence relations.

Evaluation of a formula will always require some form of "turning the crank" whether it involves recurrence or not.

The evaluation of the formula lives in sort of a separate universe then the formula itself. For example the integral or the limit of something represents something as a formula, but sometimes algorithmic evaluation of such things are not possible. A formula can exist EVEN when a algorithm or "turning the crank" evaluation doesn't exist. It's a seperate thing and does not influence the definition of "formula".

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

#124

Post by gr4vityWall »

marcosdumay wrote: post #13
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…

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.

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

#125

Post by mrkeen »

bazoom42 wrote: post #100
wk_end wrote: post #90

Earlier quoted context omitted.

At that moment, the student became enlightened.

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/

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

#126

Post by mrkeen »

roenxi wrote: post #68
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…

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.

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

#127

Post by mrkeen »

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 know if it's still relevant to make a strict separation between programming paradigms.

Consider whether the same input to your code will result in the same output (aka functions), that's a good place to draw the line.

You can stick 'FP' fancy types and closures into a method; that doesn't turn it into a function.

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

#128

Post by mrkeen »

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…

> You know with certainty that code doesn't have all the ...

You have this certainty to the extent that the compiler enforces it.

If you like language X because it's 'pragmatic' instead of 'religious', then you make the pragmatic choice of not knowing with certainty.

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

#129

Post by mrkeen »

magicalhippo wrote: post #63
Feathercrown wrote: post #22

Earlier quoted context omitted.

I think the point of the article is to illustrate why "no side effect" is important.

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?

It's not enough to take out the 'bad bits' - you have to put in 'good bits' too.

For example, Java collections are mutable, but enough ink has been spilled about the dangers of shared mutable state, that there are various recommended defences, e.g. make defensive copies when you return collections to a caller. Or use one of the immutable collections that will throw a runtime exception if someone tries to mutate it.

Now consider if you wanted to evaluate 3 + 5. Should you throw an exception which tells the caller off for trying to change the value of 3? No, the caller just wanted 8!

This is what's missing with the 'just make things immutable' approach to FP mimicry. I want to be able to combine collections together. The Java standard library Set still doesn't have union and intersection for christ's sake.

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

#130

Post by mrkeen »

leoff wrote: post #9

Interesting how the post doesn't mention the word "side effect" once. To me, all of this could be summarized by "no side effect".

Maybe the author was trying to avoid potential fallacies that follow that phrase around though:

* If you don't have side effects, you can't do anything.

* Haskell can do things? Then it has side-effects, so it's not functional.

* Computer getting hot is a side-effect.

* i++ is not a side-effect, because I intended to do it.

Post reply on HN