Did not expect this video to be this good lol

The differance is so blurred that we should really call it a spectrum of how human friendly a given code is, rather than recognise those as distinct ways of coding. Software engineers always work on some level of abstraction and even your declarative examples could be considered imperative in a larger context. Btw, looping through arrays and adding numbers could still be considered declarative as so much of what's really happening is hidden (saving variable states to registers etc.)

Declarative code is supposed to be more human friendly but I often find it to be more confusing. I find it to be more difficult to remember all the diffrent syntaxes and how to use them than to just think of the underlying mechanism. I know its better to write as much declarative as possible because its supposed to be less mental work but I find it hard to wrap my head around declarative code for some reason. I like to write my own imperative declarative api because then I feel like I can understand and adapt what is happening in the background. The biggest thing I learned in this video is the fact that I now understand why I find a lot of code to become more and more frustrating to work with and understand. I am just not well versed in programming declaratively.

I’ve been developing software for over 25 years, and this is a subject that I’m pretty passionate about. These analogies are good. However, I think a better analogy that more people will immediately understand is that if you think of code as people, some people do actual work, and some people are managers. Both are important in complex systems, but you don’t want your managers getting bogged down in implementation details. You want your workers to focus on solving specific problems and improving those solutions over time. Another way to look at it is that you can control code that you write, and possibly the code written by your team, and maybe even your company. But at some point, you’ll probably end up using code written by another company, which means that you will have no control over how that code is written. You will just have to use the code as-is. If you want other developers to use your code, it should be as simple for them to use as possible. You should design your top level entry points the same way that you would prefer other developers / companies design their entry points: clean, simple and easy to use. If that still doesn’t help, then just pretend that each component in your system is located on a different planet, and communication between them is limited to 1 byte every 10 minutes. That should give you some idea of what an efficient, well designed system looks like. Maybe I should just make my own video…

To play devil's advocate here, I have used both imperative and declarative languages, frameworks, and styles in the past. I believe that both have their benefits and drawbacks - however, in my opinion, the main drawback of the declarative side, which is INEXCUSABLE, is the inability to peek under the hood. By trying to exemplify the essence of programming, it has missed the trees for the forest. Imperative programming has its drawbacks, but these are mostly just annoyances, not anything as grave as this. Here's what I mean: Suppose you want to examine every element of a list and create a new list based on those elements. The map function works perfectly! The for loop is more ugly and takes longer to write. But, either one is just as intuitive and efficient as the other. Now, suppose you want to examine every second element of the list. Such a minor tweak requires a correspondingly minor tweak to the for loop, which retains its intuitiveness. Suddenly, the positions have been flipped - it's possible to express this in a declarative, functional way, but it takes much longer to write and to understand than the for loop. Another example. Suppose that you want to write a recursive algorithm that caches its results (aka dynamic programming). Such algorithms may be written either imperatively or declaratively (I know, I have tried to write these kinds of algorithms in functional languages). But here we encounter another problem. The very idea of declaratively writing an algorithm is absurd! When we write an algorithm, we very specifically want to instruct the computer how to accomplish an objective, not just tell it the objective that it should accomplish. Advocates of declarative and functional programming usually have pithy sayings, like "the essence of programming is composing functions and objects together" or "a program consists of interactions between interfaces", but such sayings miss the entire point of programming. The unique task of the programmer, compared to the mathematician or the physicist, is to create and codify efficient algorithms for highly specific systems. You don't need to be a programmer to write a data processing pipeline or a web UI that displays all rows of a table. Programming expertise comes into play when you're trying to fix edge cases, write fast algorithms, and fine-tune your algorithms to your specific client's needs. The important part of programming is actually the "ugly" part, and an imperative paradigm is needed to intuitively and efficiently codify the "ugly" parts. Sorry if that sounded like a rant. I enjoyed the video. I also believe in a *mostly* declarative / functional approach. However, I do not believe that any paradigm is superior to any other, and if anything, imperative / procedural must be the best due to its ability to easily handle ugly situations. Thank you for attending my TED talk.

I code both ways depending on what makes the most sense, but I'd be hard pressed to explain the different styles. This video helped give me a vocabulary to help others distinguish imperative programming from declarative programming. Many thanks.

ALL have imperative APIs underneith. Declarative Coding is marketing speak for adjusting the configuration of some prewritten software. The syntactic sugar and DX is the only thing that ever really evolves. It could be a domain specific language for a compiler like Svelte or a framework with classes like Rails or a bit of markup like React, it's all just filling out the options on some config that the imperative code in the library uses to do the real work. The error messages tend to get pretty bad when arbitrary options are misconfigured and Stack Overflow is born. Chasing other people's TPS reports is a terrible way to make a living. Declarative will always be a more frustrating way to code when things are erroring or poorly documented, but possibly faster when things are going well, like at the beginning of a project. (Progress) *Sigh*

But, ultimately, by the way you defined it, isn't "declarative" code simply modular/encapsulated code? You don't worry about the HOW when either A) you wrote a function that encompasses a humanly-readable method elsewhere and use it interchangeably within your different programs or B) someone else did it for you. Maybe you're using preexisting methods (such as Array.map), or write your code entirely in a very high-level language, some sort of visual script for example. People should code imperatively when there exist technical limitations. If you're making the engine for a videogame for example you need to squeeze the most power you can to get a maximum amount of fps. Maybe you're making a web page and you need it to load quickly on older devices, or perhaps it is a browser-based photoshopping app or any other heavy-weight application and you are trying to reduce lag. Maybe you are concerned with security issues and want to prevent hacking attempts that exploit the incorrect usage of preset functions. Declarative is more important when you don't have heavy efficiency requirements, since it speeds up development speed dramatically.

While I love the higher-order Array operations (map, filter, reduce, etc..), it's not always a good idea to use them for every situation. In some scenarios, where the input is large, callbacks can have a negative impact on the speed of the code execution during runtime due to context switching. Sometimes, a "for" loop, however verbose, is definitively faster.

This is probably the best video describing the difference between imperative and declarative programming. Thank you for making this video!

Been in the biz for over 6 years and now I also finally understand what the two means. Thanks!

Welcome Back @Tyler McGinnis & Happy New Year 🖖

What happens often in my project is that I start writing something imperative and as complexity increases I know which part I can extract to a method that provides the same mechanism in a declarative way, but reusable. It's actually been my most groundbreaking discovery with my gamedev projects that complexity only really goes up when I fail to do the above. When too much code is stuck inside an entity and should instead be extracted to a component that runs in the background. It actually does exactly the same thing but forces me to write better structured code so common data is in the entity, not the component. It took me almost 4 years of game prototyping to truly understand this and get a proper workflow in my engine.

Really looking forward to you becoming "KZfaq famous"!

One of the best and most succinct programming related videos that I have ever watched! Major props!

I remember learning haskell and it blew my mind. Its a pure functional programming language and i always had a hard time explaining why its so weird to even other cs students. Its like a regular language except every line is a return statement and it takes 3 lines of code to write quicksort in haskell. Basically almost every line follows a: "FunctionName Parameters = ReturnValue"

Rarely comment on youtube, but just wanted to say, this is an incredibly good explanation, thank you very much!

I literally didn’t think I would’ve been able to understand that… The video is so quick yet so informative!

Thank you so much for this video! I was having so much trouble trying to wrap my head around these two concepts, but you were able to break them both down in less than 5 minutes!! 🤗

Less than 5 minutes it took this guy to explain this properly

keep making content like this and you'll blow up! this video is giving my fireship vibes but way more chill.

okay now the real question is how long did it really take to make this vid, and what software did you use ;)

More i browse through KZfaq more I love this world. No one could have done it better. Thanks mate for such great analogy. Cheers !

Great explanation/introduction! Another concept that helps me code more thoughtfully.

Came to SUBSCRIBE AND RING THE BELL, woah already done !

Isn't all programming declarative to some extent ? I mean when writing the function to double the elements of an array we ask the OS to give us an array . We do not know the exact memory addresses that will be occupied by this array or how the memory allocation (however it is )works ,etc .The programmer is shielded from knowing or dealing with all of that . So how do we decide which layer of abstraction is appropriate ? I guess it depends on the context and its not black & white . As things evolve and the we just keep putting another layer of abstraction over another , over another. Great video though! Totally loved how it flowed and how it got me thinking. Good job!

This video clarified the hell out of those two terms in my programming vocabulary. Thank you very much, man.

this is becoming my favorite programming channel, period.

So basically declarative programming is pushing the problem of implementing something on someone else... ?

What a great start for you! You're going far.

Finally, someone who knows what they are talking about. You are a gem dude.

I have been prompting Chat GPT for half an hour to grasp the meaning of these terms but failed. This video beautifully explained it within 5 mins. Genius !!! Keep up the good work mate. Subscribed !!!

Another way to look at declarative vs imperative is that the former rarely deals with time, whereas the latter is affected by time, i.e. you have to worry about the order. A more concrete example is, reading a file: imperative is a series of function calls such as fopen, fseek (possibly), fread and fclose. The declarative version would be read_data(file, offset, buffer, buffer_size).

Top quality video and explanation, like in one with 5000 views

Bro, you have no idea! This is exactly what I needed to understand these confusing concepts. Thanks Brother!

I feel like this is very comparable to the tell dont ask principle. You tell other classes what to do instead of getting information from in order to do it yourself. Great video

Let's get KZfaq famous, Tyler!

Nicely done, interestingly enough I was trying to come up with a good explanation of these terms for my peers

I am glad that KZfaq's algorithm recommended me this video.

Awesome! Made total sense. Only mod I would make to the video is longer pauses between sentences, it would allow me more time to ingest the concept of that makes sense

I know this wasn't this video's intention, but I learned something about my own way of thinking. I'm autistic and I'm now realizing that the reasons why a) I'm having such a difficult time in this society and b) I'm a natural at programming is because I have a more imperative way of thinking whereas most people have a more declarative way of thinking. (Also, the latter is probably because programming was created primarily by autistic people to begin with.) No wonder people often compare us autistics to robots...

How are map and reduce declarative? I don't get it. This seems more about abstraction.

I wanted to say that I forgot to subscribe and I legitimately remembered later in the day and went back to make sure I'd get more of your videos.

Holly hell you explained this in a way that makes perfect sense thank you.

By the idea that imperative code is the "how" and declarative code is the "what", wouldn't it be reasonable to say that *all* code is declarative because in the end it all boils down to the computer executing the tasks, and we just tell it what task to execute? Of course using JS Map over a For loop is a good example of the difference in terms of actual application and usage. But from a more philosophical perspective, I really can't see any difference between "imperative" and "declarative" code except them being fancy words for comparing things like frameworks, libraries, or programming languages.

To me it feels like at the point you decided to create function "double", you're already being declarative. Actual implementation of that function seems almost irrelevant, and I certainly would prefer the first one to the "improved" one because by the point you wanted to look at how exactly is doubling an array elements thing happening, I'm thinking the first one is more self-explanatory. Which is fairly important, because being self-explanatory, easy to read and grasp is helpful for debugging, and the declarative step had happened already when you created and named a function to do this thing.

This has to be one of the best programming channels I've ever seen

I want to declare something here. I felt that was imperative to subscribe. That’s how you have got a new subscriber.

Interesting: When running the Imperative vs Declarative examples on a javascript benchmarking suite like jsbench, the Imperative examples run almost twice as fast

IN! I love your work

This video help you clearly understand the difference between imperative(How) and declarative(What) programming with the analogy(restaurant), and an example of the code with a clear and simple explanation making even the non-tech person understand what is it all about. I do like the imperative approach just because it helps me understand exactly what is the code doing overall and may help with understanding time and space complexity line by line. However, I like declarative programming better because it helps with developing programs quickly, and easily pumping out your ideas into reality really quickly. And if you want really want to know behind the scene about a particular declarative approach you can always find some sort of documentation or community help that explains what it is doing under the hood. I also notice that there are lots of communities supporting declarative approaches to things and it seems like that might be the future. Edit: Some typos.

beat explanation ever. Watched the video cuz appeared in suggestion and stayed and subscribed due to quality opf explanation,.

Great video. If anybody is still asking 'why does this matter?' it may help to consider how much need there is for programming in the world. To keep the world running, we have to use declarative code or nothing would get done in time.

Awesome concept, never thought of this, keep it up 👍

Dito last comment, even the meaning of imperative and declarative have now been rewired in my brain and now it feels like my head has been blown off, you have earned yourself a subscription, kudos to you sir...

I can honestly say that this single video changed the way I write code.

Amazing explanation. Loved how the entire video "flowed" from start to end!

Good explanation. I alwasy thought about declarative was using the map or filter functions in js, but could never give a precise definition for it. And it's true: declarative is praised as being better but sometimes imperative is just better, and sometimes the only way. Just yesterday i was coding collision detection in js and the imperative way was just much better than the declarative

Somehow i feel u r so underrated. The topics u choose are actually very helpful. Thanks again for the time man.

Excellent! Great explanation followed up by crystal clear examples!

writing my own language has thought me a lot about imperative Vs declarative programming. So in std:liste I have method injections for the primitive list. these methods include simple for loops as well because, well my fault that I didn't implement for loops natively. So it's a method instead. And the implementation of for uses this weird syntax because of this. (lamb * 2 end)[Some list with elements]:for The method implemented being: metod for >> liste -> self -> func 0 -> i :. i < self:len iken # while i < self:len (self:[i])func son # end son # end But this is just the basics and the std will grow in the future to support more declarative code rather than the extremely imperative code it has right now

Simple topic explained excellently! Thank you!

I call it the "uncertainty principle of programming" - the more domain, human level readability you have the less you know about what happens on the CPU. But that's rather hermetical 😁 Great video, will definitely send it around 👍

Oh man! I didn't even know I wanted this video. But it's amazing. Thank you for clearing that up for me. 😌

Thanks for this video!

You have a very soothing voice, and the animations are very enjoyable. Keep up the great work!

I didn't expect this video do the this good. The animations and the concise and clear explanation reminds me a lot of 3Blue1Brown's style

Awesome tutorial I'm taking the self taught approach to programming and I found this video extremely helpful

Great video! Very succinct! I liked the part about building declarative APIs out of imperative code. It would've been helpful to see some guidelines on how we can do this well. I also have the question about how to be productive in primarily declarative languages like Lisp or Haskell. Whenever I try to pick up those languages, I feel stuck. I guess I need to practice partial function application and composition more.

Best explanation I’ve come across so far!

I think abstract concepts like these are best understood through video with animations / images. Thanks a lot!

Thanks from Ukraine!

Liked and subscribed! Let's gooooo! 👊

I know my comment comes way later, but this is a great explanation and helped me understand the difference. Thanks.

amazing video! thank you! saying “what” vs “how” never really help me with any concrete understanding. Thank you for this down to earth explanation!

Great video! Your explanation was extremely clear and concise. I immediately got what I came looking for. +1 sub from me :D

A really good overview! Declarative languages don't have to be domain-specific like SQL though There are general-purpose declarative languages that can express the 'what' without wrapping everything in subroutines and other imperative cruft. I don't know that much about logical languages, but at least in many functional ones it's the other way around - when you want to describe the low-level 'how' you build it out of functions and data structures while usually staying in the pure, declarative-thinking land

I work a lot in game engines like Unreal Engine and I guess I work with both concepts here . Often In Unreal I write my own abstractions in C++ (imperative programming) that i can then use at multiple places in a declarative way with the Blueprint visual scripting system by exposing these c++ functions as nodes with descriptive names like "Elevator control", "Door opener" or "Set disco light sequence and colors" (declarative) and have all the complex how to do it logic in the c++ code that I write once but can apply multiple times by getting an external reference to what object i want to control as an input argument to the function. (multiple elevators, doors and lights can then be controlled with a common function that simply states WHAT it does, what type of object it works on and what data it needs).

Congrats, great explanation. Btw. Love your newsletter. And that must mean something. I'm using the internet for over 20 years, and I never liked newsletters at all (yuck spam). This is the first one I actually read regularly for a year now. Keep up the good job.

Dude please make more videos!

A precise explanation of this contemporary definition. It took me a while to understand when i researched the topic for my classes. The how would've been assembly and java would've been what if we were to backdate these buzzwords. In an ever going quest to intertwine human and machine who knows what the "programming languages" of the future will be, just human speech? Perhaps even predictions based on thoughts uttered out loud? Couldn't Alexa be seen as a way to declaratively program in our present? Lacking the precision of imperative means, but still resolving some human applications?

Amazing. Just the video I was looking for to show to one of my new juniors

So basically, this boils down to what level of abstraction you are programming in?

I actually think the first 3 examples are clearer. Idk if that’s weird

I didnt even know this concept existed but now I understand lol

Perfect explanation. Thanks!

How is a "for" loop not declarative with relation to the interpretor's implementation of a "for" loop?

Declarative is just programming to an abstraction - there's stuff happening behind the scenes that you don't need to worry about. It's insane that people in the industry feel the need to over-complicate everything and attach them to some buzzword.

SQL is unironically my favorite language. It is such an incredibly intuitive way to work with structured data. Although most implementations do not easily allow for code re-use or composition of functions (although i extensively use views, ctes and custom functions)

i've never heard of these concepts before, but i can certainly say that i understand them after this.

so "declarative" means simply more abstract

Amazing explanation!!! Thank you so much for it, you have a sub from me =]

You had me at Beyonce! Thanks for getting me in Formation

This is golden! Really good job! Thank you.

That's explained well. Good job

The code examples you give are not great because it conflates the explicit-abstraction axis with the imperative-declarative one. For example, in C++ you can do std::ranges::transform(arr, arr.begin(), [](u64 item) -> u64 { return item * 2; }); and this is imperative, not declarative, because it denotes an action to take, rather than describing the output directly. In contrast, the (terrible) functional Javascript code function double(arr, i=0) { if (arr.length

It pops up when I really needs it. Good video 💚

Now this is how you earn a subscriber . Bravo !!!

Nice video. Clean and simple. Please keep it coming :)

So called "human friendly" declarative code often becomes confusing and overcomplicated in large code structures. And, I often find that declarative codebases are slower than their imperative counterpart.