A different view on Functional Programming • Hacker News Board

Re: A different view on Functional Programming

#81

Post by beached_whale » Tue, Dec 26, 2017, 1:54 AM UTC

maxxxxx wrote: post #72

jjaredsimpson wrote: post #58

Earlier quoted context omitted.

Example please? Because I'm tempted to respond that there are no inherently messy problems, only insufficient solutions. 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 un…

In big companies requirements often change when strategy changes or some top manager has set his mind to something. So you are always behind the curve and you never get a set of stable requirements. Unfortunately that's reality in many companies. I pity people who have to work with SOAP or Salesforce.

Look at codifying legislation. It's all gray and nuanced. I have seen others use tools like JRules to help but people are kludgy

Re: A different view on Functional Programming

#82

Post by platinumrad » Tue, Dec 26, 2017, 1:57 AM UTC

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

That unnecessary addendum made my eyes roll so hard they still haven't recovered eight hours later.

Re: A different view on Functional Programming

#83

Post by avmich » Tue, Dec 26, 2017, 1:57 AM UTC

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_mean2 =: (+/ % #) &. (^."1) @: (>. -)
      geometric_mean2 _2 4 8
   4
      geometric_mean2 2 4 8
   4

Original geometric_mean probably meant to be

      geometric_mean =: (+/ % #) &. (^."1)

- note the copula (assignment symbol) and rank of first verb (^.) .

Re: A different view on Functional Programming

#84

Post by oh-kumudo » Tue, Dec 26, 2017, 1:57 AM UTC

The example is so simplistic and toy-like that it is not remotely convincing.

Re: A different view on Functional Programming

#85

Post by oh-kumudo » Tue, Dec 26, 2017, 2:00 AM UTC

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.

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.

Re: A different view on Functional Programming

#86

Post by avmich » Tue, Dec 26, 2017, 2:06 AM UTC

wvlia5 wrote: post #78

skywhopper wrote: post #59

This is an interesting post, and the code sample from APL got my attention. I have questions. 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 probab…

>How to type APL characters They are unicode characters. Type them the way you would type any unicode character. If you have not yet found a practical way of doing it, there are plugins for editors to help you type APL characters with no hassle. >How to learn APL? There's a Dyalog APL manual which is quite clear, Google it. Also, you can use the GNU APL interpreter. I would recommend learning APL first, only by readi…

>> what good will J do for me?

> The best would be to learn it and see it for yourself.

I've found the statement on the front page of jsoftware.com to be rather accurate:

"If you are interested in programming solutions to challenging data processing problems, then the time you invest in learning J will be well spent."

And "data processing problems" could be understood pretty widely. I've had a case when I first spent about 45 minutes producing a prototype (a program which would generate realistic plans for floor of an office building) using J, then converted that prototype in functionally equivalent (no embellishments) program in C# spending a couple of hours. Certainly working on a prototype took several failed attempts, yet it was still faster than doing the same in C# after the algorithm was already clear.

Re: A different view on Functional Programming

#87

Post by avmich » Tue, Dec 26, 2017, 2:11 AM UTC

dahart wrote: post #73

SwellJoe wrote: post #63

Earlier quoted context omitted.

"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." Is it possible that APL and J fail this test only because you (and I) don't know how to read APL or J? I think there are some languages that end up being difficult to read due to failings of the language, bu…

> Is it possible that APL and J fail this test only because you (and I) don't know how to read APL or J? Yes and no. :) Its a great point; familiarity and practice is a big part of comfort and productivity, absolutely. I love playing code golf in Python. You can make Python very concise, and very unreadable. But I don't write professional code that way, and I definitely don't have a goal of making production code as…

A good example of a good approach working with J: http://archive.vector.org.uk/art10005770

Re: A different view on Functional Programming

#88

Post by avmich » Tue, Dec 26, 2017, 2:17 AM UTC

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 you still can model different approaches - and even though in all cases the result is an expression ("sorted list is..."), the structure of that expression can model imperative style ("first do this, then this...")

Re: A different view on Functional Programming

#89

Post by avmich » Tue, Dec 26, 2017, 2:18 AM UTC

oh-kumudo wrote: post #85

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.

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.

Re: A different view on Functional Programming

#90

Post by lucio » Tue, Dec 26, 2017, 3:15 AM UTC

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.

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)