I think the procedural paradox is mostly an acquired taste. There's been some research in computer science education, most notably by the people behind the Racket learning environment, that clearly demonstrate that it's easier for most people to learn functional programming first and learn effects on top of that later. I strongly suspect people who learn in that order would not feel the paradox you describe.
I'd like to challenge the idea that Alan Kay meant cells as "tiny things". The analogy of computers on a network is probably a better one for programmers: computers are fairly big, self-sufficient things. Cells are tiny compared to a human body, but we're very far from that level of complexity yet; cells are also self-sufficient, can perform a lot of functions, contain the whole DNA sequence of the individual, etc. In that sense a few thousand lines of code for an object doesn't seem that much (though obviously it would require better source code organization tools than typical Java-style classes to define the behaviour of a single object of that size). Alan Kay has reflected on multiple occasions that one of the big mistakes they made was making objects too small.
I like your decomposition of FP in data, effect and computation. I think most FP enthusiasts will agree that FP is what happens in the "computation" space, and that the "effect" part is a necessary evil. By that token, the functional paradigm would be to try to organize a piece of code such that the majority of the code is in that "computation" space, and as little as possible is in the "effect" one. Elm is a great example of how far a language can go: the language can be called "purely functional" because all of the side-effects are happening in the runtime, away from the programmer's code. FP is not about removing side effects from the program, it's about removing them from the (visible) code.
I would argue that these paradigms are not, as we often talk about them, properties of languages, but properties of sections of code: it's very hard to look at a list of language features and decide whether the language is functional or OO or procedural or, really, anything. It is much easier to agree on these properties for a given piece of code. Language features can nudge in one direction or the other, but that's as far as they go.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very good article!
I think the procedural paradox is mostly an acquired taste. There's been some research in computer science education, most notably by the people behind the Racket learning environment, that clearly demonstrate that it's easier for most people to learn functional programming first and learn effects on top of that later. I strongly suspect people who learn in that order would not feel the paradox you describe.
I'd like to challenge the idea that Alan Kay meant cells as "tiny things". The analogy of computers on a network is probably a better one for programmers: computers are fairly big, self-sufficient things. Cells are tiny compared to a human body, but we're very far from that level of complexity yet; cells are also self-sufficient, can perform a lot of functions, contain the whole DNA sequence of the individual, etc. In that sense a few thousand lines of code for an object doesn't seem that much (though obviously it would require better source code organization tools than typical Java-style classes to define the behaviour of a single object of that size). Alan Kay has reflected on multiple occasions that one of the big mistakes they made was making objects too small.
I like your decomposition of FP in data, effect and computation. I think most FP enthusiasts will agree that FP is what happens in the "computation" space, and that the "effect" part is a necessary evil. By that token, the functional paradigm would be to try to organize a piece of code such that the majority of the code is in that "computation" space, and as little as possible is in the "effect" one. Elm is a great example of how far a language can go: the language can be called "purely functional" because all of the side-effects are happening in the runtime, away from the programmer's code. FP is not about removing side effects from the program, it's about removing them from the (visible) code.
I would argue that these paradigms are not, as we often talk about them, properties of languages, but properties of sections of code: it's very hard to look at a list of language features and decide whether the language is functional or OO or procedural or, really, anything. It is much easier to agree on these properties for a given piece of code. Language features can nudge in one direction or the other, but that's as far as they go.