 So, welcome to Smog Dev Workshop. In Smog Dev Workshop, we talk about technical issues, practical approach to software development, like having coffee with Smog, where I talk about more softer things, everything that's around the programming itself, having coffee with Smog. Technical stuff, more hardcore here, Smog Dev workshops. So, without further ado, let's begin. I'm sure you know there are dozens, hundreds even, of programming languages. Some programming languages are object oriented, other are more procedural, others are mathematical, things like SQL, esoteric languages, golfing languages even. How do you categorize all of those massive amounts of programming languages? How do you group and divide them? Like, these languages are similar, these are not similar, like, what do you do to, you know, kind of describe the language in terms that are commonly agreed on and easily understood? You come up with paradigms. So, these things that describe programming languages, these things that help us to understand what kind of features those programming language has, what kind of behaviors are allowed, what are discouraged and what are impossible. There are lots and lots and lots of programming paradigms. Let me read some of this to you. Action paradigm, concurrent computing, data-driven, dynamic, scripting, generic, intentional, metaprogramming, quantum paradigms, symbolic, so on and so forth. A lot, a lot, a lot, a lot of programming paradigms. So, where do you put the majority of most used programming languages? Where do you put C++, Java, C, PHP, JavaScript, Ruby? Where do you put SQL, XPath, OCaml, Erlang? Where does assembly belong? Fortran, Basic, all of those older ones? Where do you put them? How do you categorize them? Most of these languages have features of multiple design paradigms. You need to know that, that, for example, in Java, you could think, oh, this is object-oriented language, but it has some declarative functionality. You can write in a declarative style in Java. Parts, at least some parts of your programs could be written in this paradigm. But before we get into those paradigms, how did they came to be? What started this movement of grouping languages and paradigms coming up with higher-level principles that govern how language should behave, what should it do, and how? People used to write a lot of so-called spaghetti code. And spaghetti code is something that could only be described like the dish. Take this one end of spaghetti and you follow it into this mass of pasta and you dive in and you try to build this mental model of this thing and you try to follow these go-to statements, jumps and like, no, who does that? Like, ah, how are you even going to do that? Well, well, I'm sure that you heard about this guy called the extra. So during his investigations, the extra discovered that certain uses of go-to prevent modules from being divided into smaller and smaller chunks and simplifying them, right? So that kind of went against divide and conquer principle. At the end of the 60s, he writes this letter to this computer magazine saying, oh, go-to statements should be considered harmful. And that basically starts a huge, huge, huge storm. And you know, people start writing letters to him. And these are not very polite letters, so to speak. Eventually, we can say that the extra kind of one, you know, many languages don't even have the go-to statement and others that do kind of discourage use of it. Take C++, it's there. But, you know, right. So the extra figured that, hey, there should be a way to avoid those go-to statements and all of that nonsense, right? So he invented this, you know, structural programming. And you could argue that this was the first paradigm. Contrary structures. If then else, do while and, you know, this kind of things that allowed modules to be recursively divided into smaller and smaller pieces. And that kind of stood in contrast to, you know, non-structural programming paradigm, which allowed the use of go-to and, you know, going from one place of the code to completely unrelated. And languages like basic early versions of COBOL or FORTRAN allowed this. And of course, assembly, which, yeah, you won't get away from that in assembly. Most of the modern languages are structural. There is this other division of programming languages that basically consists of two paradigms that are in contrast of each other. So we have imperative and declarative paradigm. You know, simplifying. Imperative programming languages tell how to do stuff, how to achieve the result that you're after. Step by step, do this, assign this value to this variable, then take this map and this hash and then do this operation. So step by step, piece by piece. This is how imperative programming design, no design. Why am I saying this? On the contrast, we have this declarative approach, which basically says, I want this result. And how do you do it? I don't care. It seems a little hard to grasp, like, at first. But then you think what kind of languages are declarative. And I say things like SQL, XPath, Ragex. And then you know. That's true in SQL. You don't think how this database will go over every single row and, you know, get me my result. Like, does it store it in a map? Does it store it in a list? Does it use something else, maybe a graph or a hash map? Something arise? Who knows? Who cares? I don't care. I just want my result and that's it. I want this column, this column, this column, joined with this other table. And based on that index, blah, blah, blah, blah. I get my result and that's it. Same thing, regular expression. I don't care how you will find out all of the matches to my pattern. You figure it out. You're the library. You're the language and this is declarative style. XPath, the same thing. Just give me those nodes in this DOM3 and I don't care. Simple? Simple. So that's declarative. Imperative. That's a whole different kind of story. You have to describe it step by step. C, C++, Java, C-sharp, Pascal, PHP, Ruby, Python, all of those. You have to get in there and say, I want this variable to store this thing and this piece of memory and this structure and then perform this concrete algorithm to achieve the result that I want. And that's the main difference. So just to be absolutely clear, some of those languages have mechanisms from both. There are some database SQL languages that allow variables, stored procedures, and they kind of pull from imperative paradigm. We have this huge, huge family of object-oriented programming and object-oriented programming is of course C++, C-sharp, Java, PHP, JavaScript, sort of. We have a lot of languages that either are fully object-oriented or have elements of object-oriented programming. There are of course four important principles of object-oriented programming and this is abstraction, polymorphism, inheritance, and encapsulation. And you know, the key thing that object-oriented programming is about is of course polymorphism which allows you to use dependency injection and inversion of control and all of that. So very deep topic. This deserves like a whole separate video. I'll get back to that at some point. So object-oriented programming also lives on this imperative side of our universe. Now on the other part of our universe, there is this declarative galaxy and in there, there is this planet called functional paradigm and this planet is very, very rich. It's so rich and the RAM and computing power that they decided we are not deleting anything. Nothing gets modified. We only copy and create and that's it. There is no mutation of existing state. In principle, there are no side effects. So if you have a function that takes an argument and you give it the same argument, it will always, always give you the exact same output. There is no way of changing this output. So what does that mean and what are the implications of not having mutable states? Well, languages that don't allow mutability are very strong in avoiding concurrency issues like data-racing, like there are no deadlocks. There are no problems related to multiple threads touching the same data because the data never changes. Hmm, ain't that pretty? And you know, the most known languages that follow this paradigm are Lisp, Closure, OCaml and Erlang and I think Wolfram and languages related closely to telecommunication which is heavily concurrent. Of course, you know, there are like smaller groups of paradigms or smaller paradigms that touch on some certain small aspect of software development. But these are the main ones. These are the most important paradigms. If you understand those, if you can intuitively feel what this paradigm means, what it does, most likely you get the topic, you know, conquered well enough. So let's sum it up. We have the structural and non-structural programming. Non-structural means use go-to. Structural means use control structures. We have imperative and declarative programming. Imperative means that you have to say how to achieve your result. Declarative means that you will actually say what do you want to achieve? What kind of result do you want? So in the imperative galaxy, we have object-oriented programming and in the declarative galaxy, we have functional programming among others because of course this list is not, you know, exclusive. There are many, many, many, many, many more programming paradigms. These are only the main ones, the most common ones, the ones that are used in the most known and most used languages. So if you want to know more, I recommend getting a good book. Of course, I always recommend books. Guys, I cannot stress enough. If you want to learn something throughout, understand it in depth, get a book. So, you know, this book is kind of good. It's called Clean Architecture by Robert C. Martin, also known as Uncle Bob. So, you know, I recommend using this one as an introduction to architecture to, well, a lot of design principles, a lot of architectural principles and programming paradigms as well. He describes, you know, in detail how these came to be and what are the major differences. So this guy needs no introduction. He's a legend. He literally wrote a book on clean code, right? Right, right, right, yes. So before I leave you, I just wanted to know that go-to statement is considered harmful. Subscribe, leave a comment and I'll see you in the next one. Cheers.