Python with numpy has a pretty concise solution
np.exp(np.mean(np.log(a[a>0])))
A different view on Functional Programming
21–30 of 100 posts
Re: A different view on Functional Programming
#22I get the idea (doing fp for a living for 15 years) but the article lives in a bubble populated by mathematically pure unicorns: This strength/feature of fp can only weigh in where we have the mathematical formulas, arriving at those is the hard part in most programming jobs - most of the time those who "define" the product/spec cannot even do it in plain English (because they have to make up things as they go, no cr…
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…
> Of course arriving at the Mathematical formula is the hard part, that's what it means to actually solve the problem.
Most business problems can't be solved with a formula, or with a thousand formulas, or with a million formulas, especially if the problem is “our organization is an illogical clusterfuck” or “we don't even know what we should be doing”.
> I consider the fact that you can't code your solution in this style until you have done so as a feature
It's a feature of programming discipline and intellectual honesty, not of functional programming.
> As opposed to imperative style which (...)
Functional programming doesn't prevent you from implementing “half done solutions with hidden bugs, not covering all corner cases”.
Re: A different view on Functional Programming
#23Have 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.
A good analogy would be music notation (pentagram) I could describe a piece of music in English prose, telling you were to put your fingers and for how long. The language itself would be easier to understand, but the efficiency of information transmission would be very low. Chinese looks complicated, unless you know Chinese. The ultimate criteria to judge a language should be how efficiently (concisely) it expresses…
> The ultimate criteria to judge a language should be how efficiently (concisely) it expresses the concepts of the subject matter.
Some might say that the ultimate criteria to judge a language should be how quickly an inexperienced user starts to be fluent in it.
I studied math (so the syntax isn't really an issue), but I think functional programming is completely inappropriate for general purpose programming tasks (e.g. writing a website, writing an iPhone app, etc.).
Re: A different view on Functional Programming
#24I am something like an intermediate programmer and this is useful. I want to understand how FP replaces OOP in a similarly concise example. I have a sense that it involves a reconsideration of why OOP is useful, and solving that issue with a widely new approach, but I am not there yet myself. I’d love to see something like these Python comparisons but involving the demolition of an OOP implementation.
Having messed with Haskell I'd say the hidden data in OOP becomes "public" and that data is processed in pipelines.
In C# you sometimes objects with just public getters/setters and static methods using linq manipulating those objects. This is kind of a functional style.
Re: A different view on Functional Programming
#25I 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 programming. As long as you stick to functions which given values return other values, and your language has support for passing functions to other functions as well, you can reap most of the benefits of functional programming.
Re: A different view on Functional Programming
#26Have 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.
> aren't particularly fond of deciphering complicated math equations?
But it's not complicated. One of the great things about mathematical expressions is that they are simple. But two of the other great things are that they are concise and unambiguous, and it's those two that unfortunately lead many students to think they are complicated.
Re: A different view on Functional Programming
#27Earlier quoted context omitted.
A good analogy would be music notation (pentagram) I could describe a piece of music in English prose, telling you were to put your fingers and for how long. The language itself would be easier to understand, but the efficiency of information transmission would be very low. Chinese looks complicated, unless you know Chinese. The ultimate criteria to judge a language should be how efficiently (concisely) it expresses…
> The ultimate criteria to judge a language should be how efficiently (concisely) it expresses the concepts of the subject matter. Some might say that the ultimate criteria to judge a language should be how quickly an inexperienced user starts to be fluent in it. I studied math (so the syntax isn't really an issue), but I think functional programming is completely inappropriate for general purpose programming tasks (…
> Some might say that the ultimate criteria to judge a language should be how quickly an inexperienced user starts to be fluent in it.
The ultimate criterion to judge a formal language (such as a programming language) is how easily anyone (regardless of expertise level!) can express their ideas in a precise and unambiguous fashion in it.
It isn't clear that this criterion favors any known programming style.
Edit: grammar
Re: A different view on Functional Programming
#28Earlier quoted context omitted.
A good analogy would be music notation (pentagram) I could describe a piece of music in English prose, telling you were to put your fingers and for how long. The language itself would be easier to understand, but the efficiency of information transmission would be very low. Chinese looks complicated, unless you know Chinese. The ultimate criteria to judge a language should be how efficiently (concisely) it expresses…
Understandability is more important than conciseness in a team environment. In a team, you're not writing code for you - you're writing code to be reviewed by other people, integrated with other people's code, and maintained by other people in the future. In the example from this article, all developers I've ever worked with would understand what the "good old C" example is doing within seconds. Most would understand…
> J is even worse. I stared at the J code for a full minute without any comprehension of the language syntax or what was being accomplished. That code isn't readable or maintainable. It is bad code.
But why does code need to be readable to someone who doesn't know the language? Yes, it's true that Python and some other languages are pretty readable even to people who haven't written any of that language, and that is a nice feature in many contexts... nevertheless, if I'm hiring a Python programmer, I'm either going to hire someone with experience in Python, or I'm going to accept that they're not going to hit the ground running and be massively productive right out of the gate... so how is it really such a loss to write in J and accept that non-J programmers won't understand my code?
Re: A different view on Functional Programming
#29Have 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.
A good analogy would be music notation (pentagram) I could describe a piece of music in English prose, telling you were to put your fingers and for how long. The language itself would be easier to understand, but the efficiency of information transmission would be very low. Chinese looks complicated, unless you know Chinese. The ultimate criteria to judge a language should be how efficiently (concisely) it expresses…
But if you don't know Chinese, it would take quite a compelling argument to convince you to give it a serious try, no? If you're not in China, why not continue in English?
Of course leaning more math isn't nearly as hard as Chinese (for the non-Chinese), but this analogy isn't working in your favor.
Re: A different view on Functional Programming
#30Python with numpy has a pretty concise solution np.exp(np.mean(np.log(a[a>0])))
That's what the J sample is doing (minus the filtering)