Most of us spend 90% of our time reading other people’s code. So even though writing a concise and elegant formula in J might be a satisfying puzzle, I personally don’t want to deal with the cognitive burden of point-free style when sifting through my colleagues’ pull requests.
A different view on Functional Programming
31–40 of 100 posts
Re: A different view on Functional Programming
#32In the author's example of the geometric mean, shouldn't the function return an error if any of the numbers were negative? Because the program shouldn't be sending negative numbers to that function to begin with so he/she should maybe get some hint that one of those functions producing said numbers isn't working properly. And if there are no positives, I sure as hell don't want a divide by zero error bringing the program to a complete stop when I could just simply display "Could not calculate geometric mean, check the inputs" to the user.
Re: A different view on Functional Programming
#33Have you considered that many people aren't particularly fond of deciphering complicated math equations? For them, your argument is in favor of avoiding functional languages. Too math-like! A step-by-step procedure might be simpler to understand.
> Too math-like! A step-by-step procedure might be simpler to understand.
A step by step procedure is exactly a mathematical process. Mathematical notation is just a shorthand for some procedures so you don't have to spell out every single step every time. You'd be well served by learning them!
Re: A different view on Functional Programming
#34This quote made me smile.. Thanks OP! Happy holidays!
> Just in case all that wasn’t enough to convince you about the superiority of the functional gospel, take this threat: FP will displace OOP, so start thinking along our lines our you will eventually lose your job
Re: A different view on Functional Programming
#35I wrote my own functional, Haskell-like, language, and after a couple of years and seeing a couple more code bases in various languages, I am now starting to firmly believe that currying should be strictly avoided (or at least highly discouraged). Obscure symbol operators with operator precedence are also a clear readability problem. But unlike what this article suggests, these traits are not essential to functional…
I'm mixed on currying. It really increases expressiveness, but it does allow obscure point-free composition styles that can look like line noise.
Re: A different view on Functional Programming
#36Earlier quoted context omitted.
Hi! I appreciate your honesty. Of course arriving at the Mathematical formula is the hard part, that's what it means to actually solve the problem. I consider the fact that you can't code your solution in this style until you have done so as a feature: you can't write code if you haven't really understood and solved the problem. (As opposed to imperative style which let's you implement a half done solution with hidde…
Understood. Just to be clear: I am saying that in most scenarios nobody understands the problem; people figure it out on the go. Overall I really like the article because it spells what is an essential feature of fp for me much better than I could have. It is just that it is too far from reality of most programming jobs (unless you happen to be Peter Norvig, working on the Mars rover).
I would be interested in seeing some more examples of that kind of jobs
Re: A different view on Functional Programming
#37I wrote my own functional, Haskell-like, language, and after a couple of years and seeing a couple more code bases in various languages, I am now starting to firmly believe that currying should be strictly avoided (or at least highly discouraged). Obscure symbol operators with operator precedence are also a clear readability problem. But unlike what this article suggests, these traits are not essential to functional…
I'm mixed on currying. It really increases expressiveness, but it does allow obscure point-free composition styles that can look like line noise.
And, quick, what's the type of
(.) (.) (.) (.) (.)
How about (.) (.) (.) (.) (.) (.)
Re: A different view on Functional Programming
#38One could also say that functional programming prefers expressions to statements —and treats functions as just another expression. When needed, statement-like things are constructed from expressions.
Equations in lambda calculus do seem to have a "preferred direction" specified by the evaluation rules, though referential transparency lets you go "in the other direction" in your head, when reasoning about your program.
Perhaps the programs ~ equations idea would apply even better to logic programming, or term rewriting?
Re: A different view on Functional Programming
#39In the author's example of the geometric mean, shouldn't the function return an error if any of the numbers were negative? Because the program shouldn't be sending negative numbers to that function to begin with so he/she should maybe get some hint that one of those functions producing said numbers isn't working properly. And if there are no positives, I sure as hell don't want a divide by zero error bringing the pro…
The functions in the article are not the geometric_mean. They are functions which first filter the list and then take the geometric mean. I only misnamed them that way for the sake of exposition. The only true geometric_mean in there is the J version
Re: A different view on Functional Programming
#40Earlier quoted context omitted.
I'm mixed on currying. It really increases expressiveness, but it does allow obscure point-free composition styles that can look like line noise.
And, quick, what's the type of (.) (.) (.) (.) (.) How about (.) (.) (.) (.) (.) (.)
Interestingly, (.) (.) (.) (.) (.) is equivalent to \ f g h -> f . g . h
I probably share your opinion on which is more readable :D