Ocaml / functional programming

x.md

I'm taking down this post. I just posted this as a side comment to explain a sentence on my latest blog post. This wasn't meant to be #1 on HN to start a huge war on functional programming... The thoughts are not well formed enough to have a huge audience. Sorry for all the people reading this. And please, don't dig through the history...

@tripl3dogdare thanks for the thorough response!

Lambdas

<MyComponent onClick={(value)=> setNewValue(value)} />
<MyComponent onClick={(value)=> setNewValue(value)} />

Without Lambdas

<MyComponent onClick={this.incrementValue} />
<MyComponent onClick={this.decrementValue} />

less functions with lambdas but less readable too

@vjeux, I think you are just misleading beginners in FP. As you can see all who know FP are telling you that you just need to practice more on FP to understand the benefits. This article is same thing like a beginner on plane will tell everyone that planes sucks and let's drive on cars only, because planes are not understandable at all (I don't want to compare planes with cars now, that was just a comparation ). Please just practice more, or not, but writing something like this being blind, is not professional. There are a lot of really good articles about FP downsides, even made by FP gurus, and there are very well described technical problems (hashmaps, trees, sorting).

@tripl3dogdare

by far the majority of the problems he raised become non-issues to start with if you have a decent knowledge of functional programming

But the comment didn't point out how this was true, it just asserted that it was. (Unlike your own previous comment)

Like, you can use this argument to defend anything. "X isn't bad, you're just seeing X from a non-X perspective, so it seems bad". Ok.... but you need to explain how from some other sane perspective, X is good. Otherwise you're not ruling out the possibility that X is just a bad perspective to look at things from.

I will join the crowd of people who say that this is an uninformed opinion by someone who does not know sufficiently well what they are talking about. Certain things take time to understand, and they cannot be explained easily in comments to a gist. People take whole courses in programming to get used to a new way of programming, be it functional, imperative or quantum computing. There's nothing wrong about not knowing functional programming, but I would respectfully advise that the next time around you phrase your objections as questions to the FP community, rather than uninformed criticism. You will get a much better reponse, and you might learn something instead of spend time arguing.

(My background: I do research in programming languages, and I teach theory of programming languages.)

But you missed the point of Functional Programming Paradigm. There were no constructive criticizm just some kind of personal opinion of what you do not like with FP in general. It is even potentially dangerous for newcomers and people that read it "from distance". I could go into detail with everything that I think didn't do the justice to FP, but I see no point in doing so.

Partial reply to the following point from your lists paragraph

you cannot easily go backwards

Here is a suggestion for a parent linked tree in a functional language (F#)

I consider the above point important because it has been mentioned even in the first paragraph of a recent article and because I believe that parent linked trees are really needed in real world e.g. to get the path of node. I guess this use case was missing.

"passing values around (reduce)". so the alternative is the go style where everything is explicit. in practice the first problem is that it can be tedious to write. reduce/map are geared for increasing velocity because you can do the same with less. the second problem is that the explicitness can encourage bad practises. imagine mutating the first variable at the end of a long sequence of for loops... I'd argue that that can be just as bad if not worse.

the bottom line is that writing good code takes practice because it's an art.

I've been programming OCaml for years and I too miss early returns. However there is a good solution. There was a long discussion about this on the OCaml mailing list a few months back, and there are various with_return modules. My contribution to the art is this implementation.

at least now I know it must be pretty easy to get a job at fb, in case i need a backup

@jonsterling you seem like a wonderful person to work with.

There is a lot of really good reasons why functional programming isn't good for every use-case. It would be meaningless to enumerate them here as they're obvious if you take a bit of time to look for them. This gist (unfortunately) doesn't make any good arguments against using the paradigm :(

Worth reading the history on this one

He is right, this is exactly how I felt when I first switched to functional programming.
Nevertheless, with time, you start to adapt yourself and get it and FP starts to make sense.

Although, I still dislike the way FP people thinks brevity increase readability... I mean look at APL, it is short.
Furthermore the examples they pick are always too simplistic to make a point.

Finally, the performance of FP is something I am very interested in and I was never able to found something about it.
I am also worried about the cache unfriendliness of lists but everybody seems to forget about processor cache when working on distributed systems, on a other side Scala does allow you to use arrays instead of lists and I am mainly using arrays anyway.