[whatnow37373]

> The interesting part is what you actually do in the middle to transforms inputs -> outputs.

Can you actually name something? The only thing I can come up with is working with interesting algorithms or datastructures, but that kind of fundamental work is very rare in my experience. Even if you do, it's quite often a very small part of the entire project.

[skydhash]

A whole web app. The IO are generally user facing network connections (request and response), IPC and RPC (databases, other services), and files interaction. Anything else is logic. An FP programs is a collection of pipes, and IO are the endpoints. With FP the blob of data passes cleanly from one section to another while in imperative, some of it sticks. In OOP, there’s a lot of blob, that flings stuff at each other and in the process create more blobs.

[whatnow37373]

A general "web app"'s germane parts are:

- The part that receives the connection

- The part that sends back a response

- Interacting with other unspecified systems through IPC, RPC or whatever (databases mainly)

The shit in between, calculating a derivative or setting up a fancy data structure of some kind or something, is interesting but how much of that do we actually do as programmers? I'm not being obtuse - intentionally anyway - I'm actually curious what interesting things functional programmers do because I'm not seeing much of it.

Edit: my point is, you say "Anything else is logic." to which I respond "What's left?"

[acuozzo]

> calculating a derivative or setting up a fancy data structure of some kind or something, is interesting but how much of that do we actually do as programmers?

A LOT, depending on the domain. There are many R&D and HPC labs throughout the US in which programmers work directly with specialists in the hard sciences. A significant percentage of their work is akin to "calculating a derivative".

[williamcotton]

There's lots left!

"When a customer in our East Coast location makes this purchase then we apply this rate, blah blah blah".

"When someone with >X karma visits HN they get downvote buttons on comments, blah blah blah".

[skydhash]

Yes! In most projects, those requirements are stretched across tecnicalities like IOs. But you can pull them back to the core of your project. It takes effort, but the end result is a pleasure to work with. It can be done with FP, OOP, LP,…

[perrygeo]

> Even if you do, it's quite often a very small part of the entire project.

So your projects are only moving bits from one place to another? I've literally never seen that in 20 years of programming professionally. Even network systems that are seen as "dumb pipes" need to parse and interpret packet headers, apply validation rules, maintain BGP routing tables, add their own headers etc.

Surely the program calculates something, otherwise why would you need to run the program at all if the output is just a copy of the input?

[whatnow37373]

Yes and I notice you still did not provide an interesting example. Surely parsing packets is not an interesting example of functional programming's powers?

What interesting things do you do as a programmer, really?

[perrygeo]

> parse and interpret packet headers, apply validation rules, maintain BGP routing tables, add their own headers etc.

That's a few more than zero. I don't do network programming, that was just an example to show how even the quintessential IO-heavy application requires non-trivial calculations internally.

[whatnow37373]

Fair enough. It's just that in my experience the "cool bits" are quickly done and then we get bogged down in endless layers of inter-systems communication (HTTP, RPC, file systems, caches). I often see FP people saying stuff like "it's not 100% pure, of course there are some isolated side-effects" and I'm thinking.. my brother, I live inside side-effects. The days I can have even a few pure functions are few and far between. I'm honestly curious what percentage of your code bases can be this pure.

But of course this heavily depends on the domain you are working in. Some people work in simulation or physics or whatever and that's where the interesting bits begin. (Even then I'm thinking "programming" is not the interesting bit, it's the physics)

[BoiledCabbage]

> my brother, I live inside side-effects. The days I can have even a few pure functions are few and far between. I'm honestly curious what percentage of your code bases can be this pure.

I've never seen what you work on so there is no way I can say this with certainty, but generally people unfamiliar eith functional programming have way more code that is / or can be pure in their code base than they realize. Or put the opposite, directly as is if you were to go line by line in your code (skipping lines of comments and whitespace) and give every line a yes/no on whether is performs IO, what percentage are actually performing IO? Not are related to IO, or are preparing for or handing the results of IO, but how many lines are the actual line to write to the file or send the network packet?

Generally, it's a much smaller percentage than people are thinking because they are usually associating actual IO with things "related to" or "preparing for" or "handing results from" IO.

And then after finding that percentage to be lower than expected, it can also be made to be significantly lower by following a few functional programming design approaches.

[skydhash]

> The days I can have even a few pure functions are few and far between. I'm honestly curious what percentage of your code bases can be this pure.

A big part of it, I'm sure, but it requires some work. Pushing the side effects to the edge requires some abstractions to not directly mess with the original mutable state.

You are, in fact designing a state diagram from something that was evolving continuously on a single dimension: time. The transition of the state diagram are the code and the node are the inputs and output of that code. Then it became clear that IOs only matters when storing and loading those nodes. Because those nodes are finite and well defined, then the non-FP code for dealing with them became simpler to write.

[hansvm]

It's a matter of framing. Think of any of the following:

- Refreshing daily "points" in some mobile app (handling the clock running backward, network connectivity lapses, ...)

- Deciding whether to send an marketing e-mail (have you been unsubscribed, how recently did you send one, have you sent the same one, should you fail open or closed, is this person receptive to marketing, ...)

- How do you represent a person's name and transform it into the things your system needs (different name fields, capitalization rules, max characters, what it you try to put it on an envelope and it doesn't fit, ...)

- Authorization logic (it's not enough to "just use a framework" no matter your programming style; you'll still have important business logic about who can access what when and how the whole thing works together)

And so on. Everything you're doing is mapping inputs to outputs, and it's important that you at least get it kind of close to correct. Some people think functional programming helps with that.

[whatnow37373]

When I see this list all I can think of is how all these things are just generic, abstract rules and have nothing to do with programming. This, of course, is my problem. I have a strange mental model of things.

I can't shake off the feeling we should be defining some clean sort of "business algebra" that can be used to describe these kind of notions in a proper closed form and can then be used to derive or generate the actual code in whatever paradigm you need. What we call code feels like a distraction.

I am wrong and strange. But thanks for the list, it's helpful and I see FP's points.

[hansvm]

You're maybe strange (probably not, when restricted to people interested in code), but wrongness hasn't been proven yet.

I'd push back, slightly, in that you need to encode those abstract rules _somehow_, and in any modern parlance that "somehow" would be a programming language, even if it looks very different from what we're used to.

From the FP side of things, they'd tend to agree with you. The point is that these really are generic, abstract rules, and we should _just_ encode the rules and not the other state mutations and whatnot that also gets bundled in.

That implicitly assumes a certain rule representation though -- one which takes in data and outputs data. It's perfectly possible, in theory, to describe constraints instead. Looking at the example of daily scheduling in the presence of the clock running backward; you can define that in terms of inputs and outputs, or you can say that the desired result satisfies (a) never less than the wall clock, (b) never decreases, (c) is the minimal such solution. Whether that's right or not is another story (it probably isn't, by itself -- lots of mobile games have bugs like that allowing you to skip ads or payment forever), but it's an interesting avenue for exploration given that those rules can be understood completely orthogonally and are the business rules we _actually_ care about, whereas the FP, OOP, and imperative versions must be holistically analyzed to ensure they satisfy business rules which are never actually written down in code.

[codr7]

I agree.

Especially when reading Rust or C++.

That's code I would prefer to have generated for me as needed in many cases, I'm generally not that interested in manually filling in all the details.

Whatever it is, it hasn't been created yet.

[phlakaton]

You can name almost anything (these are general-purpose languages, after all), but I'll just throw a couple of things out there:

1. A compiler. The actual algorithms and datastructures might not be all that interesting (or they might be if you're really interested in that sort of thing), but the kinds of transformations you're doing from stage to stage are sophisticated.

2. An analytics pipeline. If you're working in the Spark/Scala world, you're writing high-level functional code that represents the transformation of data from input to output, and the framework is compiling it into a distributed program that loads your data across a cluster of nodes, executes the necessary transformations, and assembles the results. In this case there is a ton of stateful I/O involved, all interleaved with your code, but the framework abstracts it away from you.

[whatnow37373]

Thanks, especially two is very interesting. Admittedly the framework itself is the actually interesting part and that's what I meant with this work being "rare" (I mean how many people work on those kinds of frameworks fulltime? It's not zero, but..)

I think what I engaged with is the notion that most programming "has some side-effects" ("it's not 100% pure"), but much of what I see is like 95% side-effects with some cool, interesting bits stuffed in between the endless layers of communication (without which the "interesting" stuff won't be worth shit).

I feel FP is very, very cool if you got yourself isolated in one of those interesting layers but I feel that's a rare place to be.

[phlakaton]

Yeah, it's not that e.g. Haskell won't allow side effects, it's that side effects are constrained: 1) all the side-effectful operations have types that forbid you from using them outside of a side-effect context; 2) and it's a good thing they do, because Haskell's laziness means the results you would get otherwise are counterintuitive.

Other FP frameworks are far less strict about such things, and many FP features are now firmly in the mainstream. So no, I don't think this stuff is particularly rare, though Haskell/OCaml systems probably still are. There are pluses and minuses with structuring code in a pure-core-with-side-effect-shell way – FP enthusiasts tend to think the pluses outweigh the minuses.

Best, I think, to view FP not as dogma or as a class of FP-only languages, but rather as a paradigm first, a set of languages second.