Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pissed off about functional programming (2005)

perlmonks.org

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Pissed off about functional programming (2005)

#21

Post by JimmyM »

JoeAltmaier wrote: post #17
SeanLuke wrote: post #16

Wait, since when did functional programming imply immutability? I think fifty years of lisp would like to have a few words with this fellow.

Don't all scalable modern functional languages depend on immutability? So they can move function execution to different processes/virtual machines freely. Or something.

Most modern functional languages encourage immutability to a greater or lesser extent, but allow or even encourage workarounds. I don't think they depend on immutability but it's a bigger deal than it is in some other paradigms.

Re: Pissed off about functional programming (2005)

#23

Post by tel »

SeanLuke wrote: post #16

Wait, since when did functional programming imply immutability? I think fifty years of lisp would like to have a few words with this fellow.

Functional Programming is so poorly defined.. It clearly means whatever the op appears to think it means for the context of the current discussion.

Re: Pissed off about functional programming (2005)

#24

Post by wyager »

>It's theoretically possible that the 'f()' or 'x' might change between the lazy evaluation of step one and the lazy evaluation of step three million.

You can't re-bind values in the lambda calculus, so no, they never will change. This is why languages like haskell are immutable.

His complaint #3 also relies on the false assumption of a mutable language.

Complaint #4 was solved by monads, quite a while ago.

Re: Pissed off about functional programming (2005)

#25

Post by amithgeorge »

As a beginner with knowledge of only F# and Clojure, I feel a lot of his issues are solved with having immutable values.

> It's theoretically possible that the 'f()' or 'x' might change between the lazy evaluation of step one and the lazy evaluation of step three million. Trying to prevent that is what we programmers call a 'hard' problem.

and the examples he gives in Myth 3 & Myth 4 where he reassigns `x` to mean something else. Both of these can be avoided had x been immutable.

I agree with the conclusion in Myth 2. I didn't understand the latter half of Myth 3, so can't comment on that.

Am I missing something wrt my assumption of immutable values solving most of the issues?

Re: Pissed off about functional programming (2005)

#26

Post by amithgeorge »

kelvin0 wrote: post #15

I don't quite get why the 'Substitutability' code snippet fails? Is it because the both vars 'point' to the same RAM address initialized with '3'? If that is the case, I would argue the language is somewhat broken, or at least it`s a major caveat ... Please explain?

Isn't because after the increment operation, x has the value 4. Thus even if y has the value 3 and equals 3, it doesn't equal x.

Re: Pissed off about functional programming (2005)

#27

Post by bad_user »

SeanLuke wrote: post #16

Wait, since when did functional programming imply immutability? I think fifty years of lisp would like to have a few words with this fellow.

Functional programming means working with referential transparency by definition and an expression is said to be referentially transparent if it can be changed with its value without changing the behavior of the program (i.e. you receive the same output for the same input). And that's actually the definition of functions in mathematics that children learn in school - functional programming does not refer to the "functions" that we know from regular imperative programming ;-)

This implies immutability, because pieces of code, or functions that mutate variables / objects / data-structures are NOT referentially transparent.

> I think fifty years of lisp would like to have a few words with this fellow

LISP is not really a family of FP programming languages, even though LISP in general does apply concepts from lambda calculus and does have everything needed for FP. LISP in general is more like a multipurpose swiss army knife. For example the style people use to develop in Common Lisp is often very far away from FP. There are exceptions of course, like Clojure, which comes with immutable data-structures by default, strived to make uncontrolled mutation more painful and the culture around it does encourage FP.

Re: Pissed off about functional programming (2005)

#28

Post by kelvin0 »

amithgeorge wrote: post #26
kelvin0 wrote: post #15

I don't quite get why the 'Substitutability' code snippet fails? Is it because the both vars 'point' to the same RAM address initialized with '3'? If that is the case, I would argue the language is somewhat broken, or at least it`s a major caveat ... Please explain?

Isn't because after the increment operation, x has the value 4. Thus even if y has the value 3 and equals 3, it doesn't equal x.

The code line which 'fails' is $y == 3 , I think we are both confused ...

Re: Pissed off about functional programming (2005)

#29

Post by [deleted] »

amithgeorge wrote: post #25

As a beginner with knowledge of only F# and Clojure, I feel a lot of his issues are solved with having immutable values. > It's theoretically possible that the 'f()' or 'x' might change between the lazy evaluation of step one and the lazy evaluation of step three million. Trying to prevent that is what we programmers call a 'hard' problem. and the examples he gives in Myth 3 & Myth 4 where he reassigns `x` to mean so…

[deleted]

Re: Pissed off about functional programming (2005)

#30

Post by tel »

discreteevent wrote: post #20

"Even a side-effecting function call in C has a well-defined "value" as a state transformer that maps states to pairs of states and values (the so-called "monad" in functional programmers' terminology). The reluctance of functional programmers to call such languages "referentially transparent" merely implies that they are reluctant to admit such complex mathematical/conceptual objects as "values". On the other hand,…

I don't think people who really understand referential transparency would claim that it's impossible to give C a referentially transparent semantics. It's pretty easy. (This essentially feels like looking at the meaning of the language from "the inside" versus "the outside" if that makes sense.)

There's a difference between being able to imagine such a semantics and having that semantics be in common and widespread use or having it be useful to explain functions of the language or common techniques.

The nice thing about, e.g., Haskell is that these referentially transparent semantic models are really just shoved into your face. Purity makes it hard to ignore referential transparency. Monads make it incredibly clear when you have regions of code which aren't referentially transparent.

So, much like the whole contentious "vacuous type system" arguments from a day ago---these analyses exist naturally for practically any language you can think of but their value varies a lot depending on whether or not they are natural.

Post reply on HN