71–80 of 254 posts
Earlier quoted context omitted.
Former long time anarchist, current long time FP proponent, presently having a laugh with you on this.
Out of curiosity, why former?
Earlier quoted context omitted.
I think what you're missing is that functional programming is about referential transparency. There should be no need for an instruction pointer in your mental model.
Not really. Try to interact with DB in FP. Yes, there is a referential transparency ... when combining functions which call DB (e.g. using monads). As a result you get a composite function, which is the same every time you run that composition. Who cares really? When you execute that composite function though you will potentially get different results and your "referential transparency" goes out the window. Of course…
We’re talking about something that starts with things like reduce vs. a for loop with mutable variables to accumulate values. Once the language forces you to think in terms of stateful operations to perform even basic tasks, the reflexive tendency is to use mutable state to perform any task. At that point, nobody really knows what a functional does because you have to understand the entire system to know what the output of a function will be.
OOP: OK, I mostly had enough fun, can we try to tame the bit-flipping chaos with real-world analogies, without deflating all the fun?
Functional: Any Monad is by definition an Endofunctor, which also means it's an object in the category of Endofunctors, where the monadic μ(flatMap) and η(unit) operators satisfy the definition of a Monoid in that particular Monoidal Category. You got that?
Declarative: I'm gonna need a corner office with a view, and $200K/y.
The article is grouping things together that don't belong in the same categories. OO, functional, imperative, declarative: these are ways of controlling dispatch . Monoliths and microservices are both ways to organize codebases and teams of programmers and control whether dispatch is intermediated by the network or not. Either way, both of these options are implemented by some kind of language in the previous categor…
This article makes an error: All programming philosophies are about state, but they're not _just_ about state.
Disagreeing with someone's thesis is not the same as them making an error. Like maybe you don't find their argument compelling, but that's not the same as them making a factual error.
But the philosophy of p. is also dealing with ways of creating abstractions, because you can't view everything exclusively on a very low level of abstraction, without loosing your mind.
As someone coming from a functional perspective I would humbly characterize my position as: > Functional - Modifying state is hard to get correct; so let's focus on the rest of the problem (the part we can get right!) Pushing state to the edges is actually just a consequence of this impulse. In the end it isn't a satisfying solution, because you end up with every bit of low-level, inconsequential state percolating up…
Originally Riak shipped its data around as part of Erlang’s standard messaging mechanism, the process mailboxes. Over time that was recognized as a bottleneck and data started being handled differently (honestly it’s been such a long time I don’t remember the details, or how far down that road we went).
I have no conclusion to this ill-formed rumination, I’m afraid, just that your point about managing state independently reminded me of that conversation.