6 ms·

The article is grouping things together that don't belong in the same categories. OO, functional, imperative, declarative: these are ways of controlling dispat

by _skel 4y ago

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 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.

noduerme 4y ago
I agree this is mixing apples and oranges. To the degree that server architecture has to preserve state in various situations, though, coming from running my own dedicated monoliths and federated systems to service-oriented architecture about a decade ago, I have to grudgingly admit that the service model really is just cleaner and easier to wrangle. I'm thinking right now of a major version DB upgrade I have to pull this week where I'm going to have a go at the new blue/green provisioning provided by RDS. The old way would have required major downtime, rewiring web services, lots of risk of data collision, not to mention time on the phone with a datacenter just to get up and running. Ultimately the old ways always felt duct taped in some regard, like trying to switch the scenery of a stage production in the middle of an act. I hate that I'm so reliant on Amazon now, but it's just wildly more efficient.
- auggierose 4y ago
  Would you say that this distinction between SOA and micro services is correct, which I found in an O'Reilly report [1]: > 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
  - noduerme 4y ago
    To be honest, I've never really thought of the architectures I work on as being divided along those lines. I think it may be a more important distinction for larger teams. In general I think in terms of separation of duties and authority; my preference is for loose coupling and lazy loading, separate data stores and applets for separate purposes, what might be called microservices; but referring to SOA I really just mean the sharding of different parts of the stack to independent services (several RDSs, S3 buckets, EC2 instances that run cron tasks to sync disparate data systems, beanstalks for some app frontends, etc). I guess some applications within that paradigm are more "micro" than others. Some have custom APIs and others are bound more tightly to central software functions. But perhaps I don't really understand what others are talking about when they stress this distinction.
kilgnad 4y ago
There is a bit of categorical mixing going on and the author fails to identify actual hierarchies within the programming styles. But he does see, correctly, that it all has to do with state management. I'll point out what he got mixed up: 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.
- coldtea 4y ago
  I think your mistake is that it's not about the "abstract"/academic/philosophical or etymological meaning of those terms (functional, imperative, etc). 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 or different dispatch mechanism, etc). And sure, "well, actually Lisp has CLOS" -- but 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 academic sense of the term (and, heck, even that is not that clear cut. "Procedural" programming for example is still imperative in its manipulation of data, but the terms have been used in academia and industry to describe different things. So it's not about a naive application of the definition, but rather about the intention behind the term). >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.
nkzd 4y ago
Younger developer here. What does non-SOA style CRUD app look like?
- password4321 4y ago
  Maybe https://en.wikipedia.org/wiki/Visual_FoxPro https://en.wikipedia.org/wiki/Visual_FoxPro
- shrimpx 4y ago
  A p2p serverless app with storage replicated across peers.
- eurasiantiger 4y ago
  Ethereum / bitcoin / some other crypto
- TuringTest 4y ago
  Anything monolithic, where a single binary executable is run at the start, maybe spawning subprocesses to handle parallel tasks, possibly sharing memory through synching protocols to avoid interlocking. 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.html http://www.composingprograms.com/pages/48-parallel-computing... https://en.wikipedia.org/wiki/Remote_procedure_call https://en.wikipedia.org/wiki/Remote_procedure_call
- devonkim 4y ago
  XML-RPC based apps might count but they’re generally all under SOA in my experience. A real-time desktop application with some networked features to manipulate documents like via websockets may count as CRUD but not follow any SOA kind of architectural or interface conventions.
coldtea 4y ago
>OO, functional, imperative, declarative: these are ways of controlling dispatch. 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.
inopinatus 4y ago
All those things do actually fit in the broad category of “ideas pertaining to programming”. The author is illustrating a general notion. Far from being a problem, the divergent examples support the basic thesis.
chaosite 4y ago
> 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. 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...
mpenick 4y ago
Can you explain more what you mean by controlling dispatch?
thesz 4y ago
I vehemently disagree. 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.
- twblalock 4y ago
  The real difference between monoliths and microservices is decoupling teams to enable them to move independently in their software development lifecycles. 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.
  - thesz 4y ago
    The same is true for monoliths, like Linux kernel. 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/haskell-cafe@haskell.org/msg79739.html https://www.mail-archive.com/haskell-cafe@haskell.org/msg797...
lucideer 4y ago
> OO, functional, imperative, declarative: these are ways of controlling dispatch. 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.

by _skel 4y ago

noduerme 4y ago

I agree this is mixing apples and oranges. To the degree that server architecture has to preserve state in various situations, though, coming from running my own dedicated monoliths and federated systems to service-oriented architecture about a decade ago, I have to grudgingly admit that the service model really is just cleaner and easier to wrangle. I'm thinking right now of a major version DB upgrade I have to pull this week where I'm going to have a go at the new blue/green provisioning provided by RDS. The old way would have required major downtime, rewiring web services, lots of risk of data collision, not to mention time on the phone with a datacenter just to get up and running. Ultimately the old ways always felt duct taped in some regard, like trying to switch the scenery of a stage production in the middle of an act. I hate that I'm so reliant on Amazon now, but it's just wildly more efficient.

auggierose 4y ago
Would you say that this distinction between SOA and micro services is correct, which I found in an O'Reilly report [1]: > 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
- noduerme 4y ago
  To be honest, I've never really thought of the architectures I work on as being divided along those lines. I think it may be a more important distinction for larger teams. In general I think in terms of separation of duties and authority; my preference is for loose coupling and lazy loading, separate data stores and applets for separate purposes, what might be called microservices; but referring to SOA I really just mean the sharding of different parts of the stack to independent services (several RDSs, S3 buckets, EC2 instances that run cron tasks to sync disparate data systems, beanstalks for some app frontends, etc). I guess some applications within that paradigm are more "micro" than others. Some have custom APIs and others are bound more tightly to central software functions. But perhaps I don't really understand what others are talking about when they stress this distinction.

kilgnad 4y ago

There is a bit of categorical mixing going on and the author fails to identify actual hierarchies within the programming styles. But he does see, correctly, that it all has to do with state management. I'll point out what he got mixed up: 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.

coldtea 4y ago
I think your mistake is that it's not about the "abstract"/academic/philosophical or etymological meaning of those terms (functional, imperative, etc). 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 or different dispatch mechanism, etc). And sure, "well, actually Lisp has CLOS" -- but 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 academic sense of the term (and, heck, even that is not that clear cut. "Procedural" programming for example is still imperative in its manipulation of data, but the terms have been used in academia and industry to describe different things. So it's not about a naive application of the definition, but rather about the intention behind the term). >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.

nkzd 4y ago

Younger developer here. What does non-SOA style CRUD app look like?

password4321 4y ago
Maybe https://en.wikipedia.org/wiki/Visual_FoxPro https://en.wikipedia.org/wiki/Visual_FoxPro
shrimpx 4y ago
A p2p serverless app with storage replicated across peers.
eurasiantiger 4y ago
Ethereum / bitcoin / some other crypto
TuringTest 4y ago
Anything monolithic, where a single binary executable is run at the start, maybe spawning subprocesses to handle parallel tasks, possibly sharing memory through synching protocols to avoid interlocking. 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.html http://www.composingprograms.com/pages/48-parallel-computing... https://en.wikipedia.org/wiki/Remote_procedure_call https://en.wikipedia.org/wiki/Remote_procedure_call
devonkim 4y ago
XML-RPC based apps might count but they’re generally all under SOA in my experience. A real-time desktop application with some networked features to manipulate documents like via websockets may count as CRUD but not follow any SOA kind of architectural or interface conventions.

coldtea 4y ago

>OO, functional, imperative, declarative: these are ways of controlling dispatch. 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.

inopinatus 4y ago

All those things do actually fit in the broad category of “ideas pertaining to programming”. The author is illustrating a general notion. Far from being a problem, the divergent examples support the basic thesis.

chaosite 4y ago

> 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. 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...

mpenick 4y ago

Can you explain more what you mean by controlling dispatch?

thesz 4y ago

I vehemently disagree. 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.

twblalock 4y ago
The real difference between monoliths and microservices is decoupling teams to enable them to move independently in their software development lifecycles. 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.
- thesz 4y ago
  The same is true for monoliths, like Linux kernel. 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/haskell-cafe@haskell.org/msg79739.html https://www.mail-archive.com/haskell-cafe@haskell.org/msg797...

lucideer 4y ago

> OO, functional, imperative, declarative: these are ways of controlling dispatch. 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.