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

21–30 of 158 posts

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

#21

Post by tromp »

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

He didn't need to mention it because it's implicit in data flow. Instead of the side effecting / state changing

    whip(cream)
that needs to be under flow control, you have

    whipped_cream = whip(cream)
describing the flow of data. Data flow describes the relationship between non-changing entities and thus there are no side effects.

While they could have mentioned it, it wouldn't really change the message.

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

#23

Post by wk_end »

Barrin92 wrote: post #14
wk_end wrote: post #10

Earlier quoted context omitted.

One of the foundational building blocks of FP is the closure, the purpose of which is to couple together data and the function operating on it. ML, one of the standard-bearing functional programming languages, is at least partially defined by its powerful module system. And an ML module serves a similar sort of encapsulatory purpose as the class does, often binding together a type and functions that operate on it - t…

>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 - that this concept is not where the split is.

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

#24

Post by oglop »

Barrin92 wrote: post #5

>The core of Functional Programming is thinking about data-flow rather than control-flow That's not right. The difference between data and control flow oriented programming is the difference between laziness and eagerness. The difference between imperative and functional programming is largely one of abstraction, not a feature in itself. The genuine core feature of FP is the separation of data and methods , that stan…

There's always some rambling answer in every FP post about what FP _actually is_ which then devolves into senseless drivel and arguments.

If you wrote this in a book and gave it to me as a way to learn what FP is, I'd be pretty pissed if I paid for that book is all I'm saying.

Also, what in the actual fuck are you on about? FP is many things and some of them are less enforced than others depending on implementation, but I'm pretty sure in each FP book I've looked at has mentioned exactly this idea of data-flow. So either you are an amazing genius who sees what others can't, or you are just generating nonsense. Either way I don't care, HN is kind of a joke to me anymore.

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

#25

Post by layer8 »

randomdata wrote: post #16
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…

> by injecting a bit of OO. OO is defined by message passing. What does a closure have to do with message passing?

In most OO languages, message passing is just a fancy term for function calling. It’s really not fundamentally different from functional application on a closure value in FP.

OOP is defined by encapsulation and subtyping (polymorphism and inheritance). In fact, the one thing that doesn’t exist in standard FP is inheritance. (Encapsulation sort-of exists with closures, and polymorphism exists with function values.)

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

#26

Post by vundercind »

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-more-natural-for-me side of things, and find non-algorithmically-oriented math writing incredibly difficult to follow—I have to translate it to something more algorithmic and step-oriented to make any headway, in fact. I find languages like Haskell nearly illegible, and tend to hate reading code written by dedicated FP fans in just about any language.

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

#27

Post by randomdata »

layer8 wrote: post #25
randomdata wrote: post #16

Earlier quoted context omitted.

> by injecting a bit of OO. OO is defined by message passing. What does a closure have to do with message passing?

In most OO languages, message passing is just a fancy term for function calling. It’s really not fundamentally different from functional application on a closure value in FP. OOP is defined by encapsulation and subtyping (polymorphism and inheritance). In fact, the one thing that doesn’t exist in standard FP is inheritance. (Encapsulation sort-of exists with closures, and polymorphism exists with function values.)

> In most OO languages, message passing is just a fancy term for function calling.

Having objects does not make a language oriented to those objects. By your definition C++ would be considered OO, but we know it is not. Kay quite explicitly stated that C++ is not OO. I expect you're thinking of Object-based programming.

If you look at the actual definition of OO, it basically is just a laundry list of Smalltalk features. It is probably not usable outside of Smalltalk for that reason, despite Joe Armstrong's playful insistence that Erlang is the only OO language in existence.

You might be able to include Ruby and Objective-C (and, iff you're really stretching, Swift with @objc enabled), but that's about the extent of it.

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

#28

Post by gleenn »

iLemming wrote: post #19
codr7 wrote: post #11

Earlier quoted context omitted.

FP doesn't have to be a religion; in Common Lisp it's just an idea, an ideal to aim for perhaps.

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 code doesn't have all the ordering problems that come with Objects, whether you called some random function on some object at aome time that cached some instance variable that should have been shared with some other object. Reasoning about that is nuts, and the status quo for most OO code I've seen. If you know that most code only is implemented with pure functions with immutable data, then the ordering questions are nearly completely gone. You can now refactor so much easier as well without risk of subtle ordering related breakage. And then Clojure has atoms and channels which are very nice, thread-safe constructs that also are far easier to know your code won't have memory safety issues. I have dabbled at learning Rust or Haskell or Swift but Clojure gets so much so right.

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

#29

Post by mbivert »

I believe that a good definition of the "core" functional programming is: it's a practical way of using the λ-calculus. Similarly, imperative programming is a practical way of using Turing machines.

It's always somewhat possible to express what are typically considered imperative features in a functional fashion (e.g. monad), or bend imperative languages to behave somewhat like functional ones: I think the differences become clearer once we reach out for the underlying theoretical models.

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

#30

Post by BoingBoomTschak »

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

Similar reaction, I searched for "lambda calculus" first thing first and was pretty weirded by the "0 results".

To me (someone who really doesn't like FP as a religion), FP is about function application: everything should just be "pure" function calls taking values (not references) and returning values; immutability is indeed a corollary of that, static typing really isn't (isn't Church's original LC untyped, btw?).

Post reply on HN