> One of the fundamental concepts to remember is that microservices architecture is a share-as-little-as-possible architecture pattern that places a heavy emphasis on the concept of a bounded context, whereas SOA is a share-as-much-as-possible architecture pattern that places heavy emphasis on abstraction and business functionality reuse. By understanding this fundamental concept—as well as the other characteristics, capabilities, and shortcomings of both micro‐ services and SOA that I discussed in this report—you can make a more informed decision about which architecture pattern is right for your situation.
Or is this a distinction you would not make (or were not even aware of)?
[1] Mark Richards - Microservices vs. Service-Oriented architecture
First OO programming is a specific style of imperative programming. OO is simply imperative programming with state and functions scoped into instances. If you are doing OO, you are also still doing imperative programming.
You can't really compare OO to functional because it would be like comparing a very specific concept to a very general concept. Like comparing cars and planes, but instead you're comparing a 2020 tesla with all planes in general. No... either compare specific cars with specific planes or planes in general with cars in general.
Declarative programming, on the other hand, can be stateless or stateful so it doesn't really apply here. Declarative programming is sort of left field to all these programming styles because technically chatGPT is declarative. Declarative programming is more about linguistics, AI and natural language processing. It's completely orthogonal to state management.
Functional programming and Imperative Programming are the two correct categories to compare here. They are siblings in the hierarchy and they are distinct and in essence simply two different ways of handling state.
Case in point: If you change one thing in your imperative programs. One thing... then your imperative program immediately becomes functional.
This thing is immutable state. Imperative programming with immutable state IS functional programming. Change the way you manage state, then you essentially change the name of your programming style.
The two paradigms are in essence two different styles of state management. All the other stuff with OO and Declarative is sort of fluff and distracts from the true essence of the isomorphism the author noticed here.
It's about their meaning (as used for decades) within the developer community at large, as established and commonly understood.
And in that, there's absolutely a functional vs OO dichotomy, the first meaning Lisp, Haskell, etc, and the latter meaning Java/C++/Smalltalk and such (doesn't even matter if Smalltalk for example has a different conceptual model for its OO).
Doesn't matter if "well, actually" Lisp has CLOS and such -- OO and functional as commonly used (and as the author uses it) means the part of functional that's about first class functions and immutable data and purity, and OO means Java/C++ style classes and coding style.
Ditto for "imperative", which in TFA just means "C style more direct manipulation of state", even if OO in say C++ is still imperative in the term's sense.
>Declarative programming, on the other hand, can be stateless or stateful so it doesn't really apply here.
Again, for the purposes of TFA, it doesn't matter if declarative can be "stateless or stateful".
The author doesn't say that the programming language philosophies are about "different approaches to state across a single axis" (e.g. stateless vs stateful). He just says that they are about "different approaches to state" period.
In this case, regarding declarative programming, the difference is not "keeping state or not", but "the programming managing whether state is kept or not (and how)" vs "the language managing it and the programmer just declaring their intentions".
>This thing is immutable state. Imperative programming with immutable state IS functional programming.
Not in any colloquial use of the term. SSA form might be "functional programming", but it's not what 99% of devs (and the author) means by functional programming, which includes the trappings and idioms offered by traditional languages called functional programming languages.
No mistake made by me. The popular or even academic usage of the terms isn't relevant to the topic here. The reason is because the way these terms are used are highly inconsistent even in academia. They're not formally defined, they're just used for informal fuzzy communication.
I simply define a hierarchy here that's inline with our intuition to point out things the author and you completely missed.
I'm totally with you in that the popular usage is relevant in MOST cases. But in this specific context it doesn't work because the author attempts to do a very broad isomorphism across terms with fuzzy definitions stating that all of these styles are different forms of managing state and he misses the actual true meaning of what's going on.
Let's not get into language specifics like CLOS for lisp. Let's just focus on the core programming style without considering a specific language. All of these programming styles, more or less can imitate each other when managing state. None of them have a crystal clear way of handling state that's specific to their style. OOP can imitate Imperative and vice versa. In fact I'll list all the connections here:
OOP -> FP
OOP -> Imperative
OOP -> Declarative
Imperative -> OOP
Imperative -> FP
Imperative -> Declarative
Declarative -> OOP
Declarative -> FP
Declarative -> Imperative
Basically almost every programming style listed here is so similar they can practically imitate each other. An isomorphism is obvious and the differences in state management are trivial. However, there is one exception above. You will note FP is not at the left side of the table.
Functional programming Cannot imitate ANY of the other paradigms. Both the author and you completely missed this.
What I am saying is this, there's really only two basic ways of handling state and these two ways are fully exemplified between functional and imperative styles.
All the other styles including the SOA stuff is just fluff. Different ways of doing the same thing. It's like replacing every letter in the alphabet with a different symbol and calling it a new language even though it's still more or less the alphabet.
>Not in any colloquial use of the term. SSA form might be "functional programming", but it's not what 99% of devs (and the author) means by functional programming, which includes the trappings and idioms offered by traditional languages called functional programming languages.
This statement here is categorically wrong even when considering colloquial understanding of THIS concept. It is just factually completely incorrect. Have you tried doing this? map, reduce, recursion, and all FP patterns become your ONLY tools when things become immutable.
Try writing fibonacci with everything immutable in say something simple like JS or python. Good luck doing it without using recursion or reduce.
The isomorphism between FP and imperative programs that use immutable variables is something well known, but apparently, not by you.
SSA, no recursion, no reduce ;)
def factorial(X: int) -> int:
encode = lambda n: ((lambda N: lambda g: lambda f: lambda x: x if N == 0 else f(g(N-1)(g)(f)(x)))(n)
(lambda N: lambda g: lambda f: lambda x: x if N == 0 else f(g(N-1)(g)(f)(x))))
decode = lambda f: f(lambda x: x + 1)(0)
fact = (lambda f: lambda n: cond(vaut0(n))(lambda _: un)(lambda _: mult(n)(f(f)(pred(n)))))(
(lambda f: lambda n: cond(vaut0(n))(lambda _: un)(lambda _: mult(n)(f(f)(pred(n))))))(n)
return decode(fact(encode(X)))
Full form for those interested : https://termbin.com/cd3q
This snippet was clearly functional .
And the point is that this doesn't matter. It's not about C++ OOP being able to "imitate imperative" or not, it's about what C++ (or OOP in general) adds to the table regarding how programmers should think and hide state.
>All the other styles including the SOA stuff is just fluff. Different ways of doing the same thing.
Like above, you're still reasoning from lower levels of abstraction to point the similarities and underlying unity, whereas TFA is all about the level of working with each language and its "programming paradigm" as a programmer.
It's like you're arguing that "in the end, chemistry is just physics". Or worse, "in the end, cooking is just physics". Sure, but that is pedantically irrelevant information in a regular cookbook or when talking about cuisines.
>Try writing fibonacci with everything immutable in say something simple like JS or python. Good luck doing it without using recursion or reduce. The isomorphism between FP and imperative programs that use immutable variables is something well known, but apparently, not by you.
My whole point was that it's not about the isomorphism, but the higher level trappings.
Funny how you've managed to miss the whole argument, it's not even like I didn't spell it out (or like I haven't already said that SSA is nominally "functional programming") but it doesn't matter
That's your point. And MY POINT is that your point is missing the true relationship between these programming styles. C++ is not a topic here. That is a specific implementation of a programming style. We are talking about programming paradigms, not specific languages.
Additionally How is anything added to the table if every language can more or less imitate one another? Obviously you're referring to a bias that a language sort of pushes you toward. This is what YOU are saying. What I am saying is that YOUR perspective, again, is the one missing MY point.
Let me put it to you this way. When you notice everything is more or less isomorphic then you notice a true difference. FP is fundamentally different. Imperative and FP styles are MORE different then all the other styles of state management compared. Then from this you can see that there's a missing hierarchy within all these programming language paradigms. This is what I am pointing out. I'm presenting flaws of the original point, and making a new point.
>It's like you're arguing that "in the end, chemistry is just physics". Or worse, "in the end, cooking is just physics". Sure, but that is pedantically irrelevant information in a regular cookbook or when talking about national cuisines.
No I'm not. I'm saying that YOUR and the OP's point is wrong because the "everything is the same" result is what you get when you compare programming paradigms this way. You need a hierarchy and only sibling nodes in the hierarchy can be compared.
>My whole point was that it's not about the isomorphism, but the higher level trappings. Funny how you've managed to miss the whole argument, it's not even like I didn't spell it out (or like I haven't already said that SSA is nominally "functional programming") but it doesn't matter
In logic and in programming as you get more and more higher level things become more and more isomorphic until finally at the highest level of abstraction everything is the same thing. This follows logic.
In programming and in nature as you get more and more lower level things ALSO tend to become the same. But this does not follow logic. From our observations everything looks to be made out of atoms, and by design all programming styles compile into assembly instructions. But this doesn't follow any form of logic; it doesn't HAVE to be this way by logic, it is simply this way by observation or by design.
That being said, your comment about higher level trappings make no sense. Going in EITHER direction things should become more and more samey. Additionally I'm not even going to a higher level or a lower level. I am simply saying these programming paradigms have hierarchy. I am also saying within each paradigm, things are so flexible that there is no specific way of managing state. You can manage state the EXACT same way in all paradigms, except ONE style. By seeing it this way a clear hierarchy emerges. That is it.
SSA has nothing to do with this. This is a term from compiler design and you're accusing me of going to a lower level? Still I get your point and in SSA from the way you use it is not "nominally" functional programming. IT IS functional programming. Literally look at the other persons post who implemented fib. That's totally functional.
One of the tricks of making compilers is transforming the code into whatever form makes the thing you're trying to do easier. SSA is one of those forms, and it means that each variable has exactly one assignment. There is some "cheating" (phi nodes) involved to handle things like "if (...) { a = 0 } else { a = 1 }".
Notably, LLVM IR is SSA.
Since there's no mutation, it's technically a functional language.
SOA uses message passing only as the synch mechanism, but sharing memory allows for other strategies with synch primitives such as semaphores or mutexes (with the assumption that collaborating processes run on the same physical machine, or communicate through Remote Procedure Calls).
http://www.composingprograms.com/pages/48-parallel-computing...
Not really. They are orthogonal to dispatch, which is why you can have different dispatch strategies with all (or at least most) of them. Dispatch is an implementation detail.
In what industry? I'd agree that anyone making anything web-facing is using some form of SOA, but there are other things, too. Desktop apps (and to some extent mobile apps that aren't just a thin interface over a web API) still exist.
Unless you're arguing the maximalist approach, i.e., that anything with an API that tries to hide any form of implementation details is an example of SOA. In which case, that's not very interesting...
It is really about state, dispatch is an implementation detail and can be simulated in many languages.
The main difference between monoliths and microservices is in coherent and, if possible, atomic changes in state of different subsystems. Monoliths allow use of blocking primitives or atomic transactions in software transactional memory to achieve that, to do so with microservices is much harder.
The very existence of many implementations of database systems is an attestation that many, if not most, software systems require consistent and atomic transactional processing with regard to state.
State is central to all software.
With what dispatch method to achieve coherency in the processing of state changes is an implementation detail.
I've seen people set up a microservice architecture that was really a distributed monolith because multiple services were reading/writing from the same database table at the same time. I've also seen them use a central locking service as part of that.
That just shows that it's possible to carry forward the state management practices of a monolith into microservices. State management is not the differentiator.
You definitely can decouple teams to enable them to move independently in their software development lifecycles with monoliths too. Our team definitely do that.
And in realm of programming langages, the state management is a differentiator. For what it worth, the very difference between Turing machine and lambda calculus is the ability of computer (a human computer at the time) to rewrite some part of state when using rules of Turing machine.
Again, for what it worth, when you have arbitrarily modifiable state not all things are possible: https://www.mail-archive.com/[email protected]/msg797...
Two problems with this statement:
1. imperative & declarative are about dispatch, OO & functional are about much more (dispatch being one of the most negligible components)
2. dispatch is extremely concerned with state: e.g. for declarative, state is handled by the "dispatcher", whereas for imperative state is an extra responsibility of core logic - the approaches to state handling is one of the most important differentiators between these paradigms.
As for your 2nd & 3rd paragraphs, 100% agree but they don't seem to contradict the article so I'm not sure what point you're making.
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 category (OO, functional, imperative, or declarative).
Service-oriented architecture applies to both monoliths and microservices, and very few programmers still working in the industry have really seen what an alternative to service-oriented architecture actually looks like.