# What does 0D mean?  0D means zero dependencies. What I'm talking about is not app level dependencies, but programming dependencies that are kind of hidden under the hood. # How are dependencies related to concurrency? It's mostly got to do with scalability. Anything that's tightly coupled isn't very scalable. If you do scale it, you scale it in big chunks. Optimized code has to be scaled upwards in big pieces. When we put concurrency under a microscope, we see two aspects of concurrency emerge. One aspect is 0D - decoupling. Decoupling is the nucleus of concurrency. And the other aspect is simultaneity. Which means we can arrange things to be parallel, simultaneous, sequential. Whatever we want. # How do current text languages tend to force us to insert unwanted dependencies? I count at least three different things. The first is the normal function call. Most often you hardwire the name of the function into the caller. That's a dependency. The caller needs to know that a function with a given name exists. The second type of thing that happens is that a function call results in blocking. The caller blocks until the callee returns a value. This kind of blocking interferes with the operating system's idea that it controls blocking. The third kind of unwanted dependency is "return from a function". Most languages define functions that return values to the callers. This is a hardwired routing decision and conflicts with the type of thing we want to do with IoT and internet and et cetera, where we have clients and servers. A single server might have multiple clients requesting information and that server sends information back to each of the clients. So it has multiple outputs. # How does concurrency give us referential transparency? Referential transparency is known in hardware as a chip being pin compatible with another chip. The main aspect of referential transparency is the ability to replace one component with another component. There's a prerequisite for referential transparency. We have to snip all dependencies. Functional programming: when they talk about referential transparency, they actually do snip all of the dependencies and they pass them in as parameters. # How can we compare concurrency and functional programming? There's nothing new here. It is possible to express and use concurrency in many different programming languages. The trick is to find a convenient notation that makes concurrency look easy and makes concurrency easy to manipulate and easy to think about. If we look at FBP, it uses boxes to represent concurrent components and it uses arrows and lines to represent data flowing between components. StateCharts is another visual notation. StateCharts uses sets of ellipses to represent state machines. And StateCharts uses diagram nesting to represent layering and is the way that StateCharts reduces the state explosion problem. Functional programming uses Lambda for nesting and for the reduction of state explosion. On the other hand, functional programming causes more state explosion by insisting on explicit types. That I think leads to bloatware. The C language brought in the idea of using ASCII braces for nesting and for blocks associated with functions. C uses functions themselves to reduce the state explosion problem. Many other languages use functions to reduce the state explosion problem. # Resources Other things that you might want to look at when considering concurrency is the talk by Rob Pike "Concurrency Is Not Parallelism". There's a book called "Event Based Programming, Taking Events to the Limit". It uses C-sharp but chapter one in that book contains a good, long discussion of coupling and the evils of coupling. And then there's a YouTube that I tried to make about parallelism and 0D and scheduling and that sort of stuff. "Concurrency is not Parallelism": https://www.youtube.com/watch?v=oV9rvDllKEg "Event-Based Programming": https://www.amazon.ca/Event-Based-Programming-Taking-Events-Limit/dp/1590596439 "Parallelism": https://youtu.be/JD8QpV-t5eM Kinopio notes: https://kinopio.club/0d-q-a-SivbkkUtzbnxU6tUnqb7x