At the boundaries, applications aren't functional • Hacker News Board

Re: At the boundaries, applications aren't functional

#11

Post by ezy » Wed, May 04, 2022, 6:28 PM UTC

jerf wrote: post #4

I think you can say that at the boundaries, applications aren't anything . I tend to think of code in a cellular sense, as in, biology. Outside the cell is a big scary world that you don't control. There's a cell wall where you only permit certain things in. Inside the cell, the cell trusts that only good stuff has been let in. It may also have to package certain things on the way out to the next cell. In this case,…

Yea, I think a lot of programmers confuse the map for the territory. It's not only the data, but the program itself.

Almost no one actually cares how a particular program was written or how it understands it's input and output -- we care that it works with some level of quality. How one gets that result is irrelevant in the end. It could be written directly in twisty assembly code. Do not care[1]

Parts of these paradigms have useful tools for building working programs, but a great majority of the contents of these paradigms are simply about organization. This shows up most clearly in OO, and of course, functions are a way to organize code. This isn't a bad thing -- certainly helpful for humans working on a code base -- but it isn't actually relevant to the task the program itself performs or how fast or well it performs it.

So, of course, the input and output of a program aren't really conformant to any paradigm, because the paradigms are about organizing programs, not about performing a particular task.

[1] (it might even be more reliable, in some cases, because you would be forced to be careful and pay attention and all those little details you want to ignore are right there in your face (see: async) :-))

Re: At the boundaries, applications aren't functional

#12

Post by PaulHoule » Wed, May 04, 2022, 6:31 PM UTC

bigbillheck wrote: post #7

PaulHoule wrote: post #5

Earlier quoted context omitted.

I think it is more like somebody wrote a blog post that said "FP rules, OO drools" and then other people thought "I'll write a blog post like that!" Or maybe it is easy to find fault with programming languages you actually use and to idealize programming languages you don't use. I imagine a world where Common LISP won and reddit/programming would be kvetching all the details CL got wrong while asking "How can I get a…

> I imagine a world where Common LISP won and reddit/programming would be kvetching all the details CL got wrong Much unlike the current timeline in which CL did not win and people still complain about things it got wrong.

I like the CL spec as an early example of a spec for a language that balances performance and dynamism. In the big picture I'd say that it taught people how to write specs for languages like Java, Python, Javascript, etc.

CL was deeply unpopular at the time for quite a few reasons: it really had a 32-bit mindset which made it a bad fit for the machines many people had on their desktops at the time, also the language has enough performance-oriented details that it's not as simple as a LISP can be.

Re: At the boundaries, applications aren't functional

#13

Post by AnimalMuppet » Wed, May 04, 2022, 6:32 PM UTC

evocatus wrote: post #8

Correct. In more mainstream language, quoth Gary Bernhardt, "functional core, imperative shell." Functional programming is a convenient fantasy, a highly restrictive and controlled environment that allows us to make large assertions about bodies of code - "no network IO can take place here"; "your inputs will most assuredly be numbers that can be added together." It's the equivalent of assuming the cow is a sphere [0…

I think it's more like, out of this actual, physical cow, we are going to carve a perfectly spherical cow plus some... "other" parts.

That is, you can make chunks of your application functional - they just can't be chunks that touch the exterior. It's not a "mental model" - it's something you construct in the code.

Now, you may not be able to do that with all the "interior" code, either. Parts may have too much intrinsic state for functional programming to be a useful approach. But for other interior parts, hey, you like functional? Make it so.

Re: At the boundaries, applications aren't functional

#14

Post by munk-a » Wed, May 04, 2022, 6:32 PM UTC

cryptonector wrote: post #9

jerf wrote: post #4

I think you can say that at the boundaries, applications aren't anything . I tend to think of code in a cellular sense, as in, biology. Outside the cell is a big scary world that you don't control. There's a cell wall where you only permit certain things in. Inside the cell, the cell trusts that only good stuff has been let in. It may also have to package certain things on the way out to the next cell. In this case,…

> I think you can say that at the boundaries, applications aren't anything. I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially). That's not incompatible with FP. On the contrary, FP used properly lets you push all that procedural code to smallish kernels at the "boundaries" so that all the rest of the code can be pure (thus easily test…

Things might be sequential at the boundaries or they might not. A lot of hardware interacting applications are forced to handle concurrent and out of order inputs that are expected to be processed in a particular order.

Really, since the boundary is where we push all the awful stuff - that boundary (depending on the application) can be any sort of terrible.

Re: At the boundaries, applications aren't functional

#15

Post by jerf » Wed, May 04, 2022, 7:06 PM UTC

cryptonector wrote: post #9

jerf wrote: post #4

I think you can say that at the boundaries, applications aren't anything . I tend to think of code in a cellular sense, as in, biology. Outside the cell is a big scary world that you don't control. There's a cell wall where you only permit certain things in. Inside the cell, the cell trusts that only good stuff has been let in. It may also have to package certain things on the way out to the next cell. In this case,…

> I think you can say that at the boundaries, applications aren't anything. I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially). That's not incompatible with FP. On the contrary, FP used properly lets you push all that procedural code to smallish kernels at the "boundaries" so that all the rest of the code can be pure (thus easily test…

"I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially)."

You may be able to; I can't. I have a number of incoming event streams that are not necessarily ordered.

Now, like I said, you don't implement all code everywhere for all possible missteps, so you may have specific apps that get away with assuming orderedness. But it is not a general thing you can rely on.

Re: At the boundaries, applications aren't functional

#16

Post by monksy » Wed, May 04, 2022, 7:15 PM UTC

cryptonector wrote: post #6

> In 2011 I observed that at the boundaries, applications aren't object-oriented. For years, I've thought it a natural corollary that likewise, at the boundaries, applications aren't functional, either. On the other hand, I don't think I've explicitly made that statement before. The next and last paragraph does not then explicitly make that statement, instead ending with: > Functional programming offers an alternativ…

I couldn't have said it better myself.

Re: At the boundaries, applications aren't functional

#17

Post by monksy » Wed, May 04, 2022, 7:16 PM UTC

PaulHoule wrote: post #5

throwawaymaths wrote: post #3

Earlier quoted context omitted.

I think there are a lot of FPLs, like Erlang (and friends) and F# (which is in TFA), Julia, which are #1 and at least mostly #2, with their concommittant benefits, without the pain in the ass for small benefit of #3

I think it is more like somebody wrote a blog post that said "FP rules, OO drools" and then other people thought "I'll write a blog post like that!" Or maybe it is easy to find fault with programming languages you actually use and to idealize programming languages you don't use. I imagine a world where Common LISP won and reddit/programming would be kvetching all the details CL got wrong while asking "How can I get a…

This really feels like most online communication and promoted blogs on the social medias (hacker news included) have gone to the "we're optimizing for tribe click throughs" rather than technical due diligence and excitement.

Re: At the boundaries, applications aren't functional

#18

Post by cryptonector » Wed, May 04, 2022, 7:21 PM UTC

jerf wrote: post #15

cryptonector wrote: post #9

Earlier quoted context omitted.

> I think you can say that at the boundaries, applications aren't anything. I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially). That's not incompatible with FP. On the contrary, FP used properly lets you push all that procedural code to smallish kernels at the "boundaries" so that all the rest of the code can be pure (thus easily test…

"I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially)." You may be able to; I can't. I have a number of incoming event streams that are not necessarily ordered. Now, like I said, you don't implement all code everywhere for all possible missteps, so you may have specific apps that get away with assuming orderedness. But it is not a gener…

> I have a number of incoming event streams that are not necessarily ordered.

That doesn't make the application not-procedural. If it's having side effects, it's procedural in a sense.

Order, here, is not about inbound event order, but about ordered steps in processing any one event.

Re: At the boundaries, applications aren't functional

#19

Post by dragonwriter » Wed, May 04, 2022, 7:21 PM UTC

cryptonector wrote: post #9

jerf wrote: post #4

I think you can say that at the boundaries, applications aren't anything . I tend to think of code in a cellular sense, as in, biology. Outside the cell is a big scary world that you don't control. There's a cell wall where you only permit certain things in. Inside the cell, the cell trusts that only good stuff has been let in. It may also have to package certain things on the way out to the next cell. In this case,…

> I think you can say that at the boundaries, applications aren't anything. I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially). That's not incompatible with FP. On the contrary, FP used properly lets you push all that procedural code to smallish kernels at the "boundaries" so that all the rest of the code can be pure (thus easily test…

> I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially).

Well, side-effecting, yes, because that's literally how we define boundaries.

Sequentially? Not so much; concurrency (whether asynchrony or true parallelism) is important largely because simple sequential behavior doesn't capture what happens naturally at the boundaries well. (I suppose on an individual boundary, defined in the right way, there is likely to be a sequencing constraint, but not in aggregate across the boundaries of the system.)

Re: At the boundaries, applications aren't functional

#20

Post by cryptonector » Wed, May 04, 2022, 7:29 PM UTC

dragonwriter wrote: post #19

cryptonector wrote: post #9

Earlier quoted context omitted.

> I think you can say that at the boundaries, applications aren't anything. I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially). That's not incompatible with FP. On the contrary, FP used properly lets you push all that procedural code to smallish kernels at the "boundaries" so that all the rest of the code can be pure (thus easily test…

> I think you very much can say that "at the boundaries, applications are procedural" (i.e., they do side-effecting things sequentially). Well, side-effecting, yes, because that's literally how we define boundaries. Sequentially? Not so much; concurrency (whether asynchrony or true parallelism) is important largely because simple sequential behavior doesn't capture what happens naturally at the boundaries well. (I su…

You can parallelize as much as you want, but remember, you can't go faster than the slowest serial code. There will be some serial code. Again, I'm talking about order of steps in processing events that themselves may not arrive in any particular order.