
Pissed off about functional programming (2005) - yiransheng
http://www.perlmonks.org/?node_id=450922
======
viraptor
Maybe I'm missing something, but points 3 and 4 don't make much sense to me.
Could someone tell me why I'm wrong here?

In myth 3 he seems to mix words of description and the words describing
logical equivalence. "even though equals('three',3) is true, length('three')
does not equal length(3)" \- while this is correct, it only seems to say
anything about the myth because of the function name. Try this instead "even
though foobar('three',3) is true, length('three') does not equal length(3)" \-
does this really prove anything? You could never substitute "three" with 3 at
any point in the first place.

Specifically he hid a "$lut{ $str }" in equals(). It's not that 3 can be
substituted with "three" \- it can be substituted with "$lut{"three"}".

In myth 4 he seems to play a similar trick of talking about the variable
names. Sure, perl allows you to create a new block with a new variable of the
same name. I'm not sure what does that have to do with functional programming
as a whole. It's just the language implementation that allowed you to play
this trick - referring to a new thing by a name you used before.

------
moron4hire
>> I just had an long and very frustrating conversation with a young
programmer who recently discovered functional programming, and thinks it can
solve every problem in the world.

I'm struck by A) the arrogance of such a statement, and B) how completely
unsurprised I am by it. The fact that the rest of the article is nitpicky
stuff of no real consequence, with a heaping helping of strawmen and goal-post
moving, only supports this. This is a person who fears _being wrong_ and is
defending their turf.

For the proverbial "you", because this is an endemic problem in our industry:

It's not necessary to defend turf, both if you are right and if you are wrong.
Obviously, if you are wrong, it saves you time to have someone else figure it
out for you and then you can adjust accordingly (you're going to adjust once
proven wrong, right?).

But if, in some weird happenstance that has yet to be demonstrated in history,
you're right, you have expended no effort to defend your position. Sometimes,
you have to let people learn their lessons the hard way. Let the youngsters
run in their enthusiasm and trip and fall on their face sometimes. It's the
only way to build a _healthy_ fear of novelty-for-the-sake-of-novelty, and
instill some critical thinking as a matter of course.

It's not necessary to be "right" all the time. Just because there are people
in the world who are "Doing it Right" versus "Doing it Wrong", doesn't mean
you have an ordained duty to inform them.

Because I'm really getting sick and tired of being asked "why didn't you use
<whatever I like> for that <whatever you wrote>?"

------
judk
I assume this post is here to show us that the stupid argumentation about FP
vs OOP vs DWIM have been going in circles forever and we should just stop and
get back to work.

~~~
CmonDev
Yep, there is no need to choose. I use both.

~~~
tormeh
I think Odersky said something along the lines of "mutate with caution".
Sometimes it's just the best way to do things, but with caution.

------
tel
While knowledgable sounding... I kind of feel like he was missing out on what
pure FP can and does achieve. There were many statements to the effect of
"don't pretend X is Y because while Y is obviously great, it's also true that
any lang which does Y could not operate (here's an example in Perl)".

I reject that last bit, that these things Y lead to a useless language though
I do think the proof was far from the pudding 9 years ago.

~~~
mpweiher
"I kind of feel like he was missing out on what pure FP can and does achieve."

So what exactly was he missing? When I was programming in FP languages, the
process didn't seem all that different from other languages, except generally
more cumbersome.

~~~
radmuzom
"except generally more cumbersome".

So true. Especially if the domain is not "naturally" functional - say an HTML5
game. I am sure brilliant programmers will come up with a functional model
even in such cases, but I don't think that is how most people would think. I
am more fond of languages like JavaScript, which has features associated with
functional programming (higher-order functions, closures) but feels as natural
to me as C.

~~~
acjohnson55
You should look into [http://elm-lang.org/](http://elm-lang.org/). A lot of
the examples are specifically for web games. I haven't used it myself, but
from research I did into it months ago, I remain very intrigued.

------
discreteevent
"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, they seem
perfectly willing to call a state transformer a "value" when it is put in
their own favourite syntax and dressed up with a buzz word like "monad". I
have to say that they are being entirely inconsistent, even if we grant it to
them that their idea of "referential transparency" has some coherence."

[http://stackoverflow.com/a/11740176](http://stackoverflow.com/a/11740176)

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

~~~
l_dopa
I think this is somewhat misleading. It's easy to give a semantics for a toy
C-like imperative language. As far as I know, a semantics that is mostly
faithful to the C standard becomes extremely complicated and requires modeling
e.g. code layout in memory. The equational reasoning you get from that kind of
semantics is terribly weak: essentially, only terms that have the same byte-
for-byte effect on memory are really equivalent. So I wouldn't say that
exploiting "referential transparency" in Haskell is somehow more obvious, but
that it's useful at all.

~~~
tel
I think we're in agreement on content if not tone... and, honestly, I think
your tone is probably closer to reasonable while mine was a bit facetious.

I said it that way to emphasize the argument that _existence_ of a
referentially transparent semantics isn't enough, though. You need extant and
_useful_.

~~~
AnimalMuppet
Very true. In fact, that's true of every language feature. Way too often,
people waste time bikeshedding about how language X can do Y. But if it can't
_usefully_ do it, who cares?

------
efnx
I think his argument held more weight in 2005. Even though Haskell at that
point was 10 years old I dont think it was quite the poster child of FP it is
today.

It's my guess that he's talking about non-pure FPLs like Lisps and MLs, which
today don't seem nearly as FP as Haskell, Idris, Agda, Coq - the langs that
are now carrying the FP torch.

~~~
weeksie
Haskell was _absolutely_ the poster child of FP in 2005.

~~~
duaneb
I disagree; I think, at the time, functional programmers were primarily using
OCaml and various lisps. This is purely anecdotal, mind you, and haskell was
definitely on the FP radar big time.

~~~
weeksie
I dunno. I remember it being all over LtU and most every programming language
discussion was that or scheme, but always treating Haskell like it was the
ideal (and it had become default on research papers instead of OCaml)

------
andrus
Relevant discussion on LtU: [http://lambda-the-
ultimate.org/node/678](http://lambda-the-ultimate.org/node/678)

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

------
ExpiredLink
Here's another myth: "Functional programming solves the concurrency problem".

[http://www.infoq.com/presentations/java-
performance](http://www.infoq.com/presentations/java-performance)

Scroll to 41:05

~~~
seanmcdirmid
Has anyone ever seriously believed this? I guess it's just easier to
coordinate resource sharing when resource sharing isn't allowed.

My favorite is "Functional programming is becoming more relevant
because...multi-core" so your 100x slower functional code would get a 4x speed
up and only be 25x slower?

~~~
jackfoxy
Here's another myth, functional code is 100x slower (than what?). Here's the
counter example, Microsoft Research chose the functional first language F# to
build arguably the most advanced and useful quantum computer simulator in
existence. [http://research.microsoft.com/en-
us/projects/liquid/](http://research.microsoft.com/en-us/projects/liquid/)
There's no incentive to rewrite it in C++. It already solves real quantum
computing problems like molecule simulation
[https://channel9.msdn.com/Events/Speakers/dave-
wecker](https://channel9.msdn.com/Events/Speakers/dave-wecker)

~~~
seanmcdirmid
There isn't anything in this project that implies immutabilty was extensively
used for shared state in this case. F# is a pragmatic language, you can do
what you want.

------
sdegutis
To be fair, I've done a fair bit of Clojure and Ruby in my short career, and
while it's technically possible to write Ruby code in a Clojure-esque style,
it's very ugly and Ruby does not make it very easy. When you write in Ruby,
use classes or you will have a headache on your hands!

~~~
virmundi
After years of trying to force things in various languages and frameworks
(like MVC ala Struts on top of WebForms), I've learned this simple thought:
don't kick against the bricks; they don't care and you'll get hurt. If you're
in Ruby, program idiomatic Ruby. If you're in Python, program idiomatic
Python. If you're in PHP, get a new language.

~~~
AnimalMuppet
And if you're in Ruby or Python or whatever, and the language is a bad fit for
the problem, use a different language for that problem.

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

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

~~~
orclev
Most modern FP languages (and quite a few non-FP languages these days as well)
do immutable by default, with carefully controlled explicit mutability where
necessary. It's basically the flip of older traditional languages where unless
specifically stated otherwise everything was mutable. Doing immutable by
default encourages you to use mutability only where you really need it.
Immutable references allow all kinds of desirable compiler optimizations to be
implemented which leads to better performing code with fewer bugs, but it
doesn't need to be an all or nothing, you can have both mutable and immutable
references in the same code, it just means the mutable parts don't benefit
from the same optimizations the immutable parts do.

------
kelvin0
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?

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

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

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

