51–60 of 100 posts
Say we changed the problem to the geometric mean of non-negative numbers (instead of positive). This allows us to early-out if zero is encountered. It's obvious how to change the imperative code: `if (x[i] == 0) return 0;` What would this optimization look like in APL or J?
It does, we only need to change the syntax (semantics will stay the same), and the underlying mathematical structure will flourish before your eyes.
Hold on. Does this guy think "mathematical" just means "expressed as a string of symbols instead of words"?
I 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.
Try this: https://www.braveclojure.com/multimethods-records-protocols/
Have 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.
Have 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…
I trained as a classical musician and when I picked up the guitar, I was too lazy to learn the notation and learnt the songs by ear and feel instead (this may be why my guitar is collecting dust in a corner). Conversely I know a lot of "amateur" musicians, some pretty advanced, who have learnt songs by ear and can't decipher musical notation of any kind, or understand any music theory.
Chinese looks complicated even to the Chinese, hence Simplified Chinese arriving in the 1950s (and according to Wikipedia, they've started another round of simplification in 2013). Without an alphabet, there are thousands of characters to learn (8,000 in the 2013 version). Ask any Western-born Chinese how fluent they feel and how easily they can read it...
It's a bummer to pose that question as though there isn't an answer, when the answer is well known and very important.
The motivation of avoiding side effects is because we humans make more mistakes when there are side effects. Functional programming is about making a piece of code not depend on anything outside itself. When you do that, it's easier to get right, and harder to screw up the code. In a word, it's safer.
> I’ll present you a view which, at least to me, makes that set of features seem coherent; and functional programming, like a deep and beautiful paradigm: Functional programming attempts to reduce programs to equations.
We also make more mistakes when we make things too abstract, remove specificity. Write code that is too concise, and you lose meaning, context, and readability.
The "functional python" is the best looking code in the article to my eyes. It explains what it does to the reader, semantically. The APL & J examples aren't very enticing to me. I'm curious about them, but I wouldn't want to work in a codebase where if you don't know what the name of the function means, you can't figure out what it does.
Making code mathier is good occasionally, when working on mathy problems, but generally I'd rather have words and const statements in my functional programs than a concise expression with single letter variables.
I 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…
I always envy people who can work on something that can be expressed with math or some other kind of consistent logic. Most company problems are inherently messy and you just end up with a litany of convoluted code.
What problem could possibly exist that only could be implemented in a convoluted way?
Sounds more like: me and my team made trade offs that were, in retrospect, bad and now we don't know how to transform our code into a new program will fulfills the same requirements but is easier to inspect and understand.
How do I learn/get/run APL or J? How do I even type the APL code given? What does the J code even mean?
As for the content...
"makes code super concise (less room for bugs)"
Unfortunately, while this sounds great, it does not logically follow. And while geometric mean is well-defined and understood, most functions I'm probably going to write in whichever language are going to be more complicated and less well-defined. So, how does APL/J/pure-functional help/make my non-trivial code more beautiful/concise/bug-free/provable?