Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A different view on Functional Programming

matiasmorant.wordpress.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: A different view on Functional Programming

#91

Post by quicksnap »

discreteevent wrote: post #65
quicksnap wrote: post #34

This 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

"The fact that the functions are collected into records and called methods is irrelevant. As a result, the typical object-oriented program makes far more use of higher-order values than many func- tional programs” - William Cook, On understanding data abstraction revisited. OOP, especially with a focus on immutability, is not that far away from FP. It's not like, say physics where two domains can be conceptually quit…

Objects as a higher-order abstraction, as an encapsulation of data and methods, are all fine and dandy. When I think of OOP, however, I think of deep inheritance. I'm not a great fan of the latter.

Re: A different view on Functional Programming

#92

Post by avmich »

lucio wrote: post #90
avmich wrote: post #89

Earlier quoted context omitted.

Size often correlates with complexity. I suspect a size of certain kind can serve as a definition of complexity. In programming it's often the case that a shorter program is preferred to a longer.

google code golf. In the productive world, an easier to understand program is better, even if that implies more code. Variable names like "TotalAmount" are better than "x". Also, a 10 line procedural code is better than a one-line function, just because is easier to understand, and easier to change in the right way when the specification change. (it will change 15 times before implementation)

Thank you. My experience tells me another story.

More code in terms of code size in bytes isn't always more complex. For example, sometimes one wants to emphasize the similarities and analogies and spends extra bytes to show that. But that in my experience is rare - and while it could be beneficial for a novice or for a substantially unfamiliar code, for good code if soon becomes burdensome.

TotalAmount instead of x would probably drive crazy most mathematicians. Or most APL programmers. And probably most people demonstrating code on a whiteboard. Even in more mainstream languages like Clojure or Haskell a lot of variables are rather short; it's unfortunate that C++ with history of Hungarian notation, Java or C# have a habit to use long names.

There is a reason why mathematical notation exist. F = gmM / (R^2) is often preferable to "force is proportional to both masses and to inverse of square of the distance with proportionality coefficient gamma".

My advice for you is to try develop a program in REPL fashion. Standard J package from Jsoftware has a good environment for that - you can launch a computation expressed in a line, see the result and if you aren't satisfied just copy the line, make changes and launch it again. Pretty convenient in comparison to classical save-compile-run-checkResults loop of, say, C++ development. One line is certainly easier to change 15 times before implementation when specification change.

Re: A different view on Functional Programming

#93

Post by Veedrac »

avmich wrote: post #88
Veedrac wrote: post #48

It should be obvious that if a transformation is syntactically trivial, it can only solve trivial problems. If programming is not-math, it's not going to become math just because you change the surface syntax. A mathematician's definition of a sorted list is different to a programmer's at least in part because a mathematician is interested in a sorted list and a programmer is interested in sorting a list. This differ…

> If programming is not-math Programming is _always_ math; was it Dijkstra who said "programming is one of the hardest branches of applied mathematics"? It's also engineering - as in "engineers have to do some math occasionally, even if they don't realize that". I often ask on the interviews to produce an expression returning sorted 3-element list using some simple primitives. I've found that with chosen primitives y…

On one hand, yes. On the other, classifying whether programming is a math or not doesn't help you decide whether you should use APL, or much else for that matter.

Re: A different view on Functional Programming

#94

Post by draw_down »

dllthomas wrote: post #41
tzahola wrote: post #31

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.

When it's appropriate, point free style doesn't increase cognitive burden. It's often inappropriate.

“Right tool for the job”, round and round we go.

Re: A different view on Functional Programming

#95

Post by draw_down »

avmich wrote: post #83
ridiculous_fish wrote: post #43

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?

Geometric mean is nth root of product of n numbers. If you replace any of those numbers with 0, it will all collapse to 0 - perhaps not what you want. But it's not hard to write such a program: geometric_mean1 =: (+/ % #) &. (^."1) @: (0&>.) geometric_mean1 2 4 8 4 geometric_mean1 _2 4 8 0 If you want to replace negative numbers with their positive counterparts, you may first replace a number with its absolute value:…

    geometric_mean1 =: (+/ % #) &. (^."1) @: (0&>.)
Just this makes me want to cry. Good lord. Even if you like functional programming why would you want it to look like this?!

Re: A different view on Functional Programming

#96

Post by oh-kumudo »

avmich wrote: post #89
oh-kumudo wrote: post #85

Earlier quoted context omitted.

True. I think some FP people, especially the new converts, seem to hold a weird view that simple == shorter code, which is SIMPLY not true.

Size often correlates with complexity. I suspect a size of certain kind can serve as a definition of complexity. In programming it's often the case that a shorter program is preferred to a longer.

> Size often correlates with complexity.

It can correlate with complexity positively and negatively.

Which one explanation below is easier to understand?

Photosynthesis? Or 'process used by plants and other organisms to convert light energy into chemical energy that can later be released to fuel the organisms' activities'?

You could argue that Photo+Synthesis might be enough to imply the essential underlying mechanism of the process itself, but I think more people would prefer the latter just for clarity.

Re: A different view on Functional Programming

#97

Post by marssaxman »

mikebenfield wrote: post #26
skybrian wrote: post #7

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.

Mathematical notation is not one thing; it is a whole poorly-specified family of context-dependent micro-notations. While I have spent my entire career enthusiastically educating myself on a wide variety of topics beyond anything I was exposed to in school, I have found it essentially impossible to learn any new mathematical notation beyond that which was taught formally. I am capable of understanding novel computer-science concepts perfectly well once they have been translated into a more accessible notation, and of putting those concepts into practice in my own engineering work; but as long as I am struggling through papers which express those concepts in mathematical notation, I understand little and get only as far as I can by inferring what the underlying abstractions must be from the surrounding English text. It very much is complicated, if you aren't already part of an academic system capable of passing it along to you, and so far as my experience has gone there is basically no other way to bootstrap yourself into it. I have spent rather more of my life educating myself outside any academic system than I ever did within one, so the value of a notation with such limited learnability strikes me as being considerably lower than what people who have made a career inside academia might naturally assume.

Re: A different view on Functional Programming

#98

Post by tabtab »

skywhopper wrote: post #62
HumanDrivenDev wrote: post #12

Earlier quoted context omitted.

How do you mean? I don't find myself scribbling down mathematical equations when doing things like chaining promises in javascript or transforming sequences with LINQ or marking fields as const. I realise functional programming can go in very different directions to things less mundane, but the general principle of avoiding side effects has been a huge win for me when programming in any language, even C++. It's just…

Yeah as the other response said, side-effect free programming is great. And while it's a side effect of pure-functional programming, there's absolutely nothing that ties it to a functional approach.

"Lab toy" examples often use simplistic or unrealistic requirements to demonstrate some grand catchy abstraction. But real-world problems often end up being difficult to shoe-horn into the needed patterns. Perhaps the best and brightest can reformulate real-world requirements to fit, but they haven't codified the techniques yet. The last part seems the hardest.

Re: A different view on Functional Programming

#99

Post by kaeluka »

wvlia5 wrote: post #10
jlg23 wrote: post #5

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…

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…

What's the mathematical formula that describes a text box GUI item? Languages that look like math might be great for... mathematical problems. But programs are much more than math.

Re: A different view on Functional Programming

#100

Post by avmich »

oh-kumudo wrote: post #96
avmich wrote: post #89

Earlier quoted context omitted.

Size often correlates with complexity. I suspect a size of certain kind can serve as a definition of complexity. In programming it's often the case that a shorter program is preferred to a longer.

> Size often correlates with complexity. It can correlate with complexity positively and negatively. Which one explanation below is easier to understand? Photosynthesis? Or 'process used by plants and other organisms to convert light energy into chemical energy that can later be released to fuel the organisms' activities'? You could argue that Photo+Synthesis might be enough to imply the essential underlying mechanis…

I don't think example with photosynthesis suggests anything here. Naming and describing are different things. You can certainly name verbs in J, like functions in other languages, and get the code both shorter and easier to understand, because it would be distracting to always read the long definition. I think more people actually prefer former almost always, except when defining what that the photosynthesis is.
Post reply on HN