241–250 of 254 posts
I think paradigms rather than philosophies is a better term.
I guess the author used "philosophies" because they are mixing pears and apples, so the most specific word that can be stretched enough to encompass those concepts is "philosophy".
Earlier quoted context omitted.
To interpret the quote charitably, I think it's more that age can come with an appreciation with the fragility of society, the recognition that it's a miracle it works at all, and a humility about how much and how rapidly a system can be changed without being destroyed.
> humility about how much and how rapidly a system can be changed without being destroyed I guess everyone familiar with US history should find the quote to be utter bullshit, then. The American Revolution, Civil War, Emancipation Proclamation, 19th Amendment, Great Depression, WWII, and Civil Rights Act were all major upheavals in society that brought on rapid change. A lot of people died prematurely, but a lot of l…
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…
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 hard…
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.
Earlier quoted context omitted.
> FP is about evaluating expressions and it doesn't have state all over the place. FP is all about side effects. Every time you declare something you're effecting a compile time side effect. And then there's monads, which are literally reinventing state with a worse API. I find it odd that no mainstream functional language has an explicit call stack monad and an explicit symbol table monad. Maybe because even the "pu…
> FP is all about side effects. Every programming language is about side effects. Computations that don't lead to side effects are useless. That being said fp splits a core functional part (pure, no side effects of any kind) and the interpreter part where the instructions are run. The way one should visualize pure functional programming is that functional programs don't _do_ anything. They are equivalent to producing…
> Computations that don't lead to side effects are useless.
Right.
> The way one should visualize pure functional programming is that functional programs don't _do_ anything. They are equivalent to producing a description of the operation. The actual execution happens when those descriptions (generally encoded in effects or data types such as IO/Task) are interpreted by an external runtime.
This is the right way to understand imperative programming too. The program really doesn't do anything, it just describes a set of possible processes. Then the runtime converts the program into one of those processes (or maybe more than one). Each of those processes is a path through a program state space graph, but supposing your process is to have visual effects at various nodes in that graph the runtime will do externally visible things. It's really not any different.
In the end FP is basically just a way to force programming in a SSA style, plus whatever silliness the designers go for to deal with the reality that mathematical functions can't really capture input and output in any sort of useful way. Interestingly, it appears to me that in pure math the vernacular text around the equations fulfills that role.
Earlier quoted context omitted.
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…
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 abstr…
Earlier quoted context omitted.
No, but this is why we have things like linear types or encapsulating side effects in a state monad to describe these kinds of strict sequencings. I personally think pure functional programming is still very unergonomic but referential transparency in the face of side effects is not an unsolved problem. Besides, it's good practice to limit how widespread side effects are in any program, anyway.
Referential transparency is something you can reason about. While technically monads are "reasonable" you are not going to reduce them by substitution. Yes, you can if you have a good imagination, but how does it help? While combining effects is thread safe etc., executing resulting function not necessary is. So we just kicked the can down the road adding another layer on top of existing compiler. Monads is a nice wa…
Each Haskell monad might have a different implementation of the >>= (bind) operator, which is referentially transparent and which you can easily substitute. The IO monad would be an exception: I believe that one is not referentially transparent and thus cannot be substituted, because it's not implemented in Haskell. You can however imagine that it is a sort of state monad for the external world, but that's a fiction in practice.
(Note: Haskell monads are not "real monads" from category theory, and nor are monads in any other programming language AFAIK... So it's helpful to be very specific about what we're talking about when we use the word "monad" without context. You can implement a monad-like thing using classes in Python or many other languages, but those aren't referentially transparent and aren't typically the monads people are talking about in the context of pure functional programming.)
Earlier quoted context omitted.
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 hard…
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 sho…
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/msg797...