Skip to content

Instantly share code, notes, and snippets.

@vjeux
Last active January 6, 2024 07:15
Show Gist options
  • Select an option

  • Save vjeux/cc2c4f83a6b60d69b79057b6ef651b56 to your computer and use it in GitHub Desktop.

Select an option

Save vjeux/cc2c4f83a6b60d69b79057b6ef651b56 to your computer and use it in GitHub Desktop.
Ocaml / functional programming

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

@frankandrobot

Copy link
Copy Markdown

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

@rwmjones

rwmjones commented Dec 23, 2017

Copy link
Copy Markdown

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.

@jonsterling

Copy link
Copy Markdown

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

@btnwtn

btnwtn commented Dec 23, 2017

Copy link
Copy Markdown

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

ghost commented Dec 23, 2017

Copy link
Copy Markdown

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 :(

@goofballLogic

Copy link
Copy Markdown

Worth reading the history on this one

@Delaunay

Copy link
Copy Markdown

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment