A different view on Functional Programming • Hacker News Board

Re: A different view on Functional Programming

#61

Post by kortex » Mon, Dec 25, 2017, 10:46 PM UTC

mikebenfield wrote: post #28

Arainach wrote: post #20

Earlier quoted context omitted.

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…

Look at the top 7 languages used in industry: C/++/#, Java, JS, Python, and VB.NET.

They all more or less follow "C-like syntax".

In fact compare APL or J to any of the Tiobe 20, and you'll see they are wildly different in look and feel.

https://www.tiobe.com/tiobe-index//

Re: A different view on Functional Programming

#62

Post by skywhopper » Mon, Dec 25, 2017, 10:46 PM UTC

HumanDrivenDev wrote: post #12

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…

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.

Re: A different view on Functional Programming

#63

Post by SwellJoe » Mon, Dec 25, 2017, 10:49 PM UTC

dahart wrote: post #57

> it’s usually defined by some of its features, such as: reification of functions, avoidance or banning of functions with side-effects, use of higher-order functions and so on. But, doesn’t that sound like a collection of random features? What’s the motivation behind them? 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…

"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, but I don't know enough to know if APL or J is among them.

Python is, perhaps, more readable than most languages, but I've seen people learning Python have a hard time with many of its choices, so we really have to consider whether we find some version of the code more readable only because we've read a lot more of that kind of code.

Most of the time "easy to use" just means "what I'm used to", and I don't think programming languages are an exception to that.

Re: A different view on Functional Programming

#64

Post by kortex » Mon, Dec 25, 2017, 10:50 PM UTC

euske wrote: post #60

I kinda agree with the idea; functional programming turns your program into a series of tubes.

This is exactly it. I don't write 100% functional code, but when given a possibility of implementing functionality using state vs pure function, I aim for the pure function whenever possible.

Re: A different view on Functional Programming

#65

Post by discreteevent » Mon, Dec 25, 2017, 10:51 PM 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

"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 quite different. OOP and FP are just two programming tools meaning that their variation is quite limited by the domain they are in.

Re: A different view on Functional Programming

#66

Post by skywhopper » Mon, Dec 25, 2017, 10:54 PM UTC

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…

It's not even always about "can we spec this?" or "do we even understand the problem?". But when you get into the real world on a non-isolated system, you have to deal with invalid data, unexpected input, network failures, hardware failures, software bugs, security probing, user errors, memory limitations, timing issues, remote system failures, corrupted data, network failures, data storage failures, network failures, network failures, and network failures.

Did I mention network failures? Also, as beautiful as side-effect-free programming is, any non-trivial program will have side-effects outside the program itself. And your beautiful functional code must account for that.

Re: A different view on Functional Programming

#67

Post by [deleted] » Mon, Dec 25, 2017, 10:56 PM UTC

[deleted]

Re: A different view on Functional Programming

#68

Post by [deleted] » Mon, Dec 25, 2017, 11:02 PM UTC

mrob wrote: post #55

mikebenfield wrote: post #26

Earlier quoted context omitted.

> 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 highly ambiguous. See recent discussion of the alleged proof of the ABC conjecture ( https://news.ycombinator.com/item?id=15971802 ). If it was really unambiguous then we could parse it like computer code and decide if it is correct or not without all the controversy about what it really means.

[deleted]

Re: A different view on Functional Programming

#69

Post by dxhdr » Mon, Dec 25, 2017, 11:04 PM UTC

jjaredsimpson wrote: post #58

maxxxxx wrote: post #9

Earlier quoted context omitted.

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.

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…

> Because I'm tempted to respond that there are no inherently messy problems, only insufficient solutions.

Really? There are entire industries which only work on "messy problems." ie game dev: implement a controller where jumping is both responsive and fun.

Re: A different view on Functional Programming

#70

Post by dgreensp » Mon, Dec 25, 2017, 11:05 PM UTC

you might know that it’s usually defined by some of its features, such as: reification of functions, avoidance or banning of functions with side-effects, use of higher-order functions and so on

The "function" in "functional programming" and the "function" in "avoidance or banning of functions with side-effects" are two different words, by the way! FP is named after the math word, not the programming language word, which means different things in different languages but usually means a kind of subroutine. FP means programming in a style that emphasizes composition of mathematical functions, and in an imperative language this generally amounts to writing your subroutines in a certain way. It just so happens that many imperative languages call subroutines "functions."