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.)
@uidotdev2 жыл бұрын
That's a fair takeaway.
@timothymcguire51262 жыл бұрын
True, but in looping you are still giving instructions even if they are abstractions of what the machine is doing. I think a great way to learn the difference between the two is trying to learn Haskell. Haskell is a purely functional language, which functional programming is a subset of declarative programming. Because of that many programming concepts like loops, simply don’t exist in Haskell. But despite that it’s just as powerful, because instead it uses recursion.
@SufferDYT2 жыл бұрын
@@timothymcguire5126 Smol brain here, how do you process an array like in the described double(arr) function without a loop?
@overloader79002 жыл бұрын
@@SufferDYT for each member of array, do a thing; not neccesserally looping, could be in parallel, if no dependencies
@SufferDYT2 жыл бұрын
@@overloader7900 Foreach sounds like a loop, but I see the distinction lol
@lauradevries92422 жыл бұрын
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.
@damirahman2 жыл бұрын
i don't really fault you for that -- frankly, the double/summation declarative examples are not even more human-readable than the imperative counterparts. if you know pretty basic syntax for *most* common programming languages, then the imperative one is significantly easier to read. the declarative ones require that you know what the map and reduce functions are, that you understand the => operator in js, and what the arguments to those functions even mean (what's the 0 in the reduce call? i have no idea, but i didn't have to ask that question for the imperative code) i left this video thinking "did he just describe a function call?" rather than being impressed by the "simplicity" of the declarative code -- for all intents and purposes, i don't see why a better declarative approach would've been to just call the double() function that was written out imperatively. that's a whole lot more human readable than calling map or reduce with ugly syntax
@demoniack812 жыл бұрын
@@damirahman The 0 is the initial value. Reduce() has an absolutely awful syntax. It's quick and when I write js/ts I do use it for simple things like flattening trees or creating key-value maps from flat arrays, but nobody will ever convince me that it's "cleaner" than writing out the entire thing properly.
@CaptainTechnicalityLP2 жыл бұрын
In fairness to declarative code, javascript is probably one of the worst languages that could have been used to demonstrate it cause javascript is just kinda awful to read in general. SQL is something you could think of as a "pure" declarative language, and I think it's much better designed to make this style of code readable. It uses verbs which are generally intuitive, and occasionally a bit redundant to make it read more easily at a glance. C# has a library called linq which is based on sql syntax, and it does similar things to the javascript functions but is much more readable, at least to me.
@stevenhe34622 жыл бұрын
@@CaptainTechnicalityLP I think you get it. The language really defines if you want to program imperatively or declaratively. Javascript is not designed to be declarative in the first place. These features are added in later.
@falklumo2 жыл бұрын
IMHO, any software should be much more explicitely be separated into a declarative and an imperative part. And the declarative part should NOT be written in a *programming* language at all. Failing to do so leads to confusing code in the way you described.
@AftercastGames2 жыл бұрын
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…
@uidotdev2 жыл бұрын
Thanks for taking the time to write this out!
@AftercastGames2 жыл бұрын
@@uidotdev My pleasure. You just happened to touch on a subject that I’ve been thinking about for a few years now, so I couldn’t help but dump everything in the comments. I really want to start a new series of videos on the subject, but I need to get some quality equipment first. This video is very good quality and very effective. If I could create content of this quality, I would do it today. Maybe I should just send you some transcripts, and let you do all of the work. 😉
@NavySturmGewehr2 жыл бұрын
The problem I have with this, and the use of imperative and declarative in general is that, if you have a manager, you still have to write the manager, you still have to tell the manager how to do its job. Calling the manager later down the line after you've already written it, doesn't change the fact that it had to be written in the first place. So by extension applying our thought process to a completely linear process that needs every instruction to work just doesn't make sense.
@AftercastGames2 жыл бұрын
@@NavySturmGewehr Yes, if it’s a linear process, like a compiler, that simplifies things a bit. But for business development, and game development, the “managers” typically just respond to events. When a character moves, or when an order is placed, the manager should respond with a sequence of calls to workers to perform the appropriate actions. Over time, these sequences tend to change as the requirements change, but the actions themselves are less likely to change. But in either case, you want the manager to be easy to replace, and you want the workers to be easy to replace, just like in real life. 😉
@yt-sh2 ай бұрын
we need your experiences, make your video quickly, it doesn't have to be high end, just try to make it minimal and it might look good already...
@Agent-ic1pe2 жыл бұрын
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.
@yamogebrewold86202 жыл бұрын
Interesting thoughts. Sometimes you need to be able to look under the hood of course. But I don't think that the point is to never do imperative programming. That’s why he said that declarative APIs lay on top of imperative implementations. Code that is only imperative is super difficult to reason with. Code that is only declarative and hides its underlying mechanism is difficult to fully understand. A mix of both is needed.
@Agent-ic1pe2 жыл бұрын
@@yamogebrewold8620 good take, I agree. It's the same thing I feel about encapsulation. It's mostly useful but there are a few places where it limits your ability to get stuff done.
@LukeAps9 ай бұрын
Well said!
@felixjohnson38749 ай бұрын
I'd disagree, Imperative is "better" under any meaningful usage of the word. At the end of the day, everything you ever write becomes assembly that tells the computer *_exactly_* what it ought to be doing. Unless we want to grant the credit of *_all_* abstraction to Declarative code, Imperative styles retain that direct behavioural model while still being simplifiable after the fact. When it comes to writing real programs, Imperative will *_always_* have the edge for that reason. Declarative's only real value is A : when you've decided to work with a language so absurdly far removed from the hardware writing the code yourself isn't even possible. (Python for instance NEEDS to offload heavy computational work onto other languages because its so insanely slow you couldn't write it even if you wanted to. In other words, Declarative abstraction is literally necessary because of the weakpoints in the language) Or B : when you are operating in a very codified problem space and working with pure concepts instead of gritty realities. In other words, you don't ask a haskell dev to write an embedded OS. Declarative & functional languages are excellent at working on very strict concepts but implementation absolutely kills them. For me a great example of the nuance here is Rust which, despite having many abstractions and incorporating functional concepts, is nonetheless very clearly imperative. Thats why I really don't think Declarative can be credited for abstraction, because even abstract languages clearly still behave Imperatively.
@previnder7 ай бұрын
To be honest, your comment is better than most TED talks I've heard.
@ozzyfromspace2 жыл бұрын
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.
@uidotdev2 жыл бұрын
So glad you found it useful.
@DemiImp2 жыл бұрын
It's just different levels of abstraction. All imperative code is ripe to be labeled as declarative at some point. For example, "table for 2 please" is a small step in a large step of "eating dinner". (Get everyone ready, enter the car, get to a restaurant, get a table for two, order food, eat the food, head home)
@Stevexupen5 ай бұрын
keeping open mind, being pragmatic, flexible and believing everything has it's own place and purpose is a valuable mindset to have in programming. heck, in every possible thing you can do even.
@jhawley0312 жыл бұрын
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"
@asdasddas1002 жыл бұрын
Currently learning Haskell and I couldn't agree more. You basically say "Do this, combine it with this then do this after" and then it does it. I love it
@seriouslee41192 жыл бұрын
Been in the biz for over 6 years and now I also finally understand what the two means. Thanks!
@uidotdev2 жыл бұрын
Glad it helped!
@MCC9002 жыл бұрын
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.
@ferociousfeind85382 жыл бұрын
A balance of overhead- when creating an unwieldy beast that must be efficient, the developer must undertake significant MENTAL overhead, "thinking like a computer", to squeeze performance out of the machine. On the other hand, at higher levels, taking on that mental burden is not the best strategy, because you have only so much mental stamina, and the computer can handle doing some inefficient things in the name of the developer having an easier time with development. Gotta meet deadlines, or something.
@ferociousfeind85382 жыл бұрын
@@heeyy3 ~~if you can't tell how it works based on declarative programming, it's probably not good declarative programming. You're supposed to be able to understand it because it's written in a human way...~~
@popularmisconception12 жыл бұрын
Ideally, declarative programming are essentially a bunch of statements about the program, which can be used for running the program, but also to tell other things about the program, such as function invariants, value space constraints, etc. which not only allows to perform the program (which may not always be quite efficient, but always possible), but also analyze the program for various purposes, such as optimization, correctness, etc, which is something done much harder with imperative representations. Even in imperative languages such as java and c++ you almost always add some declarative information to your program, such as limiting visibility, instantiability, inheritance, input/output/value/error space, nullability, multiplicity and more. Declarative programming is basically defining the program purely in terms of its contract. In imperative programming, explicit static-time information is much more limited and deriving it from code is non-trivial. Therefore, a declarative program compiled with a good optimizer might actually be a much better thing than a poorly optimized imperative implementation.
@OmegaF772 жыл бұрын
@@heeyy3 It's probably because of vague/poor naming. For example, if I want a function to suck me off, then I may write def succ(). But succ what? More precisely I would have to name it to def succDicc().
@sc1ss0r1ng2 жыл бұрын
@@OmegaF77 *He is speaking the language of gods*
@aspi82192 жыл бұрын
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.
@uidotdev2 жыл бұрын
Means a lot. Thank you!
@aspi82192 жыл бұрын
@@uidotdev Thank you for your reply! The pleasure is all mine really.
@cthutu2 жыл бұрын
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).
@acuddlycactus2 жыл бұрын
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.
@uidotdev2 жыл бұрын
Right. Whole goal was to portray declarative vs imperative as a scale with different tradeoffs along the way.
@AftercastGames2 жыл бұрын
It’s less about choosing between imperative and declarative programming styles, and more about keeping them separate. You want your declarative code to control what happens and when, and you want your imperative code to actually do the work.
@daniyalahmad18202 жыл бұрын
@@uidotdev but it didn't portray any tradeoffs ... i couldn't guess at least
@invitapriore2 жыл бұрын
I don't know what V8 does under the hood with iterators, but this tradeoff isn't inevitable in the general case. The Rust compiler, for example, can often translate maps/filters/etc. into IR that's at least as performant as a for loop with manual indexing, via inlining and other tricks. I say "at least" because the functional approach is often *faster*, since the compiler has all the information necessary to skip the bounds checks that it might otherwise insert in cases where there's no straightforward way to infer from context that the maximum size of the loop index is less than the size of the collection being accessed. Rust is very committed to zero-cost abstractions like that, but in this case I don't see anything about JavaScript that would prevent it from enjoying the same type of optimization, and that's kind of how I think about declarative approaches in general: they can be less performant, but they don't need to be, since they also give the compiler/runtime the benefit of an abstraction boundary behind which it can do optimizations with information that maybe isn't accessible or representable in the front-end environment.
@vikingthedude2 жыл бұрын
@@AftercastGames "You want your declarative code to control what happens and when, and you want your imperative code to actually do the work." This is a really nice way to put it. I'll keep this in mind
@sapito5152 жыл бұрын
Rarely comment on youtube, but just wanted to say, this is an incredibly good explanation, thank you very much!
@uidotdev2 жыл бұрын
You're very welcome. Thanks for taking the time to let us know ❤️
@huxnwebdev2 жыл бұрын
Welcome Back @Tyler McGinnis & Happy New Year 🖖
@uidotdev2 жыл бұрын
Good to be back!
@FROZENbender2 жыл бұрын
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.
@k3d4rcodes452 жыл бұрын
wow cool
@nugzila4170 Жыл бұрын
Finally, someone who knows what they are talking about. You are a gem dude.
@indycinema2 жыл бұрын
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*
@tedbendixson2 жыл бұрын
"Declarative" programming is like my seven year old nephew learning to code. He wants to just make the game work by typing in whatever pops into his head, and then he gets frustrated and impatient when he realizes computers don't work that way.
@bobthemagicmoose2 жыл бұрын
I get really frustrated with these marketing buzzwords that might have some nuanced philosophical underpinnings but they are so overused by people who misunderstand them that they lose all real meaning. Here's my take on it: "declarative" = optimizing for human legibility, usually identified by having a clear story in the code and direct tie-in to the task at hand; "imperative" = optimizing for the machine (speed or other factors), usually identified by the code being tightly-coupled to its operating context (machine/environment/etc.). Also, positioning them as a dichotomy is what causes so much confusion on the topic. It is a spectrum. One commentator (or maybe the video) gives the example of a restaurant where declarative would be "I want a pizza" while imperative is "take 2 cups of flour, add salt... " however saying "I want pizza is context-constrained because what if the pizza there isn't any good? Even more declarative would be "make me happy" and the chef serves up whatever is the best for you and even more imperative would include "so find a field, put this wheat seed in the ground...." I wish we would throw out the "imperative vs. declarative" paradigm and more talk about human legibility vs context-coupled. All applications should be human-legibile on the higher levels, but as you drill down into these functions it should be a gradual transition towards context-coupling. This also leads into a discussion on lazy vs. eager execution which is a similar balance between human interpretability and machine optimization.
@tedbendixson2 жыл бұрын
@@bobthemagicmoose I might add that in some cases we should also consider simply not making a developer api and opting for a graphical tool like a level editor or paint program. Not everyone needs to be a developer, and if they aren't operating at the lower levels (or lack an understanding of the lower levels), they probably *shouldn't* be a developer. It's totally fine to just give people a spreadsheet and have them enter some values without ever having them touch the code. It may be preferred.
@tedbendixson2 жыл бұрын
@@bobthemagicmoose It does make me think. Are the level editors for the games I create "declarative"? Their user interface is largely concerned with "what" is in the levels, not how the levels are interpreted by the game in order to play properly. Am I doing "declarative programming" by making these levels, placing tiles and starting locations and other entities into my game world? By currently accepted definitions of the term, I'm not entirely convinced I'm not. And that's the problem. It's an ill-defined term which is used too broadly.
@bobthemagicmoose2 жыл бұрын
@@tedbendixson people argue about what "real" programming/developing is all the time... but I would say that "programming" is taking a task and deconstructing it into smaller tasks (aka instructions). If one of the tasks does not exist in the system, you break it down now until all tasks can be performed by the system you are using. The more complicated this process is (remember, the deconstruction needs to gradually get to tasks that map to instructions available to you!), the more it is considered programming. For most games, I think level editors require these skills because you have to deconstruct the experience you are going to create ("I want an easy puzzle that features x mechanic with a tutorial system to guide the player") into objects available in the level creator.
@sephirothjc2 жыл бұрын
Less than 5 minutes it took this guy to explain this properly
@finsflexin2 жыл бұрын
I literally didn’t think I would’ve been able to understand that… The video is so quick yet so informative!
@uidotdev2 жыл бұрын
Glad it was helpful!
@Jekalmat5 ай бұрын
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 !!!
@uidotdev5 ай бұрын
Thank you!
@AhmadJubair2 жыл бұрын
Let's get KZbin famous, Tyler!
@uidotdev2 жыл бұрын
New year, new me!
@adityamali18622 жыл бұрын
I am glad that KZbin's algorithm recommended me this video.
@uidotdev2 жыл бұрын
Glad you enjoyed it!
@JarrettBC2 жыл бұрын
What a great start for you! You're going far.
@uidotdev2 жыл бұрын
Thank you Jarrett!
@madhureshminoshi42722 жыл бұрын
beat explanation ever. Watched the video cuz appeared in suggestion and stayed and subscribed due to quality opf explanation,.
@uidotdev2 жыл бұрын
Welcome!
@prog_demos2 жыл бұрын
Really looking forward to you becoming "KZbin famous"!
@uidotdev2 жыл бұрын
Making my Mom proud. Finally.
@thatsalot35772 жыл бұрын
I can honestly say that this single video changed the way I write code.
@Storkz0re2 жыл бұрын
Top quality video and explanation, like in one with 5000 views
@uidotdev2 жыл бұрын
Thank you Vital!
@uwagideon27232 жыл бұрын
This has to be one of the best programming channels I've ever seen
@uidotdev2 жыл бұрын
Thanks for watching!
@srsajjad74602 жыл бұрын
Came to SUBSCRIBE AND RING THE BELL, woah already done !
@uidotdev2 жыл бұрын
LFG!
@TheGoonkid2 жыл бұрын
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...
@rowan4042 жыл бұрын
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...
@uidotdev2 жыл бұрын
Wow, that's a really interesting observation. My Wife taught severe special ed and a common thing she'd do when helping kids with severe autism stay focused is elaborate the order of things ("First X, then Y") . That totally aligns with your theory.
@rowan4042 жыл бұрын
@@uidotdev Thanks! Also, as someone who went to a special ed school, _"First_ work, _then_ snack." has been forever engrained into my head. Meanwhile, I was more concerned as to why you couldn't eat your snack _while_ doing your work. Also, I wanted to clarify that using functioning labels is looked down upon because it sort of puts kids in a box with no room to improve. A lot of us fluctuate over time. Like, I had "mild" autism for most of my life that became more "severe" in the past few months due to mental illness. I even lost the ability to talk for a few days despite having been fully-verbal since I took speech classes in kindergarten. Additionally, at my school, I had no problems forming friendships with the non-verbal kids. And, amongst each other, some of them even had crushes. (One of my non-verbal friends was infamous for partaking in PDA with his girlfriend, who was also non-verbal, during school events.) Most people don't seem to realize that there are ways to communicate that don't involve speaking.
@ALXG2 жыл бұрын
I want to declare something here. I felt that was imperative to subscribe. That’s how you have got a new subscriber.
@uidotdev2 жыл бұрын
Welcome! ❤️
@macchiato_18812 жыл бұрын
So basically, this boils down to what level of abstraction you are programming in?
@h2dpunjabiz2 жыл бұрын
More i browse through KZbin more I love this world. No one could have done it better. Thanks mate for such great analogy. Cheers !
@kevinfredericks23352 жыл бұрын
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.
@uidotdev2 жыл бұрын
Glad you enjoyed it!
@MaxSvid2 жыл бұрын
Amazing. Just the video I was looking for to show to one of my new juniors
@uidotdev2 жыл бұрын
Glad I could help!
@Skatinima2 жыл бұрын
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
@uidotdev2 жыл бұрын
Glad it was helpful!
@peterpodgorski2 жыл бұрын
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 👍
@deidara_85982 жыл бұрын
So basically declarative programming is pushing the problem of implementing something on someone else... ?
@ZigzauerLT2 жыл бұрын
exactly
@andythedishwasher11172 жыл бұрын
This video clarified the hell out of those two terms in my programming vocabulary. Thank you very much, man.
@uidotdev2 жыл бұрын
Glad you enjoyed it
@bradmazurek2 жыл бұрын
How are map and reduce declarative? I don't get it. This seems more about abstraction.
@saisagarsharma2 жыл бұрын
Somehow i feel u r so underrated. The topics u choose are actually very helpful. Thanks again for the time man.
@uidotdev2 жыл бұрын
That means a lot. Thank you!
@dcascato2 жыл бұрын
Nicely done, interestingly enough I was trying to come up with a good explanation of these terms for my peers
@uidotdev2 жыл бұрын
Glad you found it useful!
@aspi82192 жыл бұрын
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
@labadcloyd2 жыл бұрын
keep making content like this and you'll blow up! this video is giving my fireship vibes but way more chill.
@Versole2 жыл бұрын
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.
@darchcruise2 жыл бұрын
This is probably the best video describing the difference between imperative and declarative programming. Thank you for making this video!
@soniccane11172 жыл бұрын
Great explanation/introduction! Another concept that helps me code more thoughtfully.
@CodingCatDev2 жыл бұрын
okay now the real question is how long did it really take to make this vid, and what software did you use ;)
@uidotdev2 жыл бұрын
4-5 days. I'm a noob so coded the animations with Framer Motion and did everything else in Screenflow.
@Kevin-jc1fx2 жыл бұрын
@@uidotdev Wow. I was thinking that you are absolutely amazing at after effects. I think about opening a channel to teach some software engineering concepts but I am very concerned about edit as I have never really edited a video. I should start with whatever I know. Great video anyways. Thanks.
@tytylive4u2 жыл бұрын
amazing video! thank you! saying “what” vs “how” never really help me with any concrete understanding. Thank you for this down to earth explanation!
@uidotdev2 жыл бұрын
Glad you enjoyed it!
@utuber1782 жыл бұрын
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!
@felixgraphx2 жыл бұрын
(as a programmer for thew last 20+ years) I also thought that when describing 'declarative' programming it had more to do with using a library where all the imperative programming was all done in the past and some new 'declarative' interface makes all that technology available in an easier-to-use declarative interface. So indeed you'Re right that there's declarative stuff in the imperative code too,. it's just so prevalent that most dont even see it: let myarray = [ ]; doesnt require you to code assembly to assign a space of ram and deal with it, its all declarative from that layer on, presented as a higher order programming language. html, css , angular, react or whatever declarative web stuff is just a higher order above the 'imperative' langugages below it, I wonder if this will repeat again in more technology stacks / language layers . etc... ?
@utuber1782 жыл бұрын
@@felixgraphx Exactly my thoughts . Its definitely there in so many places although I feel that front end is the worst offender that I know and embedded space is least affected because you cannot stack when there is no space to put stuff , lol. All of this could be fine but what bothers me with these layers of abstraction is that they don't appear to be sturdy .Its like a tower of houses built on one another with no concern about sustainability just immediate gain and fewer people remember how the older houses even work . This is one of the reasons why software errors and malfunctions are so bloody common. If anyone likes this topic I will highly suggest the talk by jonathan blow. kzbin.info/www/bejne/kIS1eZiOjql_odE
@dealloc2 жыл бұрын
While declarative code is itself an abstraction of imperative code, this doesn't mean that all imperative code is abstracted through declarative code. Imperative code also abstracts over other imperative code. You can think of this as "layers", and thereof we have layers of abstraction; from machine code to high level languages.
@felixgraphx2 жыл бұрын
@@dealloc yes, imperative code is from both declarative and other imperative. no one implied otherwise, (if i did i misspoke) :)
@dealloc2 жыл бұрын
@@felixgraphx It was a reply to the original comment :-) The original comment questioned whether not all programming was "declarative". My comment explains why that is not always the case.
@user-iz7zr6ex3d Жыл бұрын
Bro, you have no idea! This is exactly what I needed to understand these confusing concepts. Thanks Brother!
@Damjes2 жыл бұрын
so "declarative" means simply more abstract
@francescoanastasio2021Ай бұрын
It’s definitely a way to abstract code. Not the only one, that why we need the word.
@marklord76146 ай бұрын
I know my comment comes way later, but this is a great explanation and helped me understand the difference. Thanks.
@gJonii2 жыл бұрын
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.
@DavonAllen922 жыл бұрын
absolutely agree with this. and in production its just as important to be human readable to the other programmers so that if the bus situation occurs your not spending time and money trying to map everything out. Method names should be declarative and inside those methods can be either more declarative methods or the imperative. but no matter what logically it should be understood what the hell is going on by a peer in case of bus. funny enough i was actually hit by a bus on my way to work a while back but i was in a car.
@beeflumps2 жыл бұрын
I think abstract concepts like these are best understood through video with animations / images. Thanks a lot!
@uidotdev2 жыл бұрын
Glad you enjoyed it!
@tharrrrrrr2 жыл бұрын
Liked and subscribed! Let's gooooo! 👊
@uidotdev2 жыл бұрын
❤
@toonclips38982 жыл бұрын
Best explanation I’ve come across so far!
@uidotdev2 жыл бұрын
Thank you!
@afrobear23102 жыл бұрын
Now this is how you earn a subscriber . Bravo !!!
@uidotdev2 жыл бұрын
Welcome!
@avananana2 жыл бұрын
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.
@gabetower6165 Жыл бұрын
Holly hell you explained this in a way that makes perfect sense thank you.
@JoelKesler2 жыл бұрын
Interesting: When running the Imperative vs Declarative examples on a javascript benchmarking suite like jsbench, the Imperative examples run almost twice as fast
@JoelKesler2 жыл бұрын
Imperative - Using for loop 9,361,471 ops/sec Declarative - Using array map and array reduce 5,184,327 ops/sec
@riddixdan55722 жыл бұрын
until you hit an actual bottleneck that is caused by using map instead of for-i, readability of the code takes priority over anything.
@Glightstar2 жыл бұрын
@@riddixdan5572 I'd say that argument is valid for source code, but not for production code if there is just a plain faster method available (at least for most cases). Of course this doesn't mean tho, that you have to give up one side's benefits for the other, as there are tools to optimize code for production environments too.
@Sam-vf5uc2 жыл бұрын
Depends how well the declarative libraries are written. If you're like me and can't optimize for shit then substituting a declarative can speed it up substantially.
@dandre3K2 жыл бұрын
@@JoelKesler Those methods run through conditionals that are unnecessary most of the time. That along with the callback stack frames is why they're alot slower than a basic for/while loop. A simple recursive function is faster too.
@arno.claude2 жыл бұрын
You have a very soothing voice, and the animations are very enjoyable. Keep up the great work!
@uidotdev2 жыл бұрын
Thank you Arno!
@drewbird872 жыл бұрын
Oh man! I didn't even know I wanted this video. But it's amazing. Thank you for clearing that up for me. 😌
@uidotdev2 жыл бұрын
Thank you! Glad you enjoyed it.
@AZIARGROUS2 жыл бұрын
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
@13thk2 жыл бұрын
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
@sameraw43072 жыл бұрын
this is becoming my favorite programming channel, period.
@percivalroberts85642 жыл бұрын
Awesome tutorial I'm taking the self taught approach to programming and I found this video extremely helpful
@uidotdev2 жыл бұрын
So glad to hear.
@MaxPicAxe2 жыл бұрын
Great explanation. Declarative code is just an abstraction to allow users to ask what they want.
@zvebrstremnyj68632 жыл бұрын
Thanks from Ukraine!
@uidotdev2 жыл бұрын
❤
@Rin-qj7zt2 жыл бұрын
i've never heard of these concepts before, but i can certainly say that i understand them after this.
@uidotdev2 жыл бұрын
I imagine you'll start hearing them more now. Glad you enjoyed it!
@CodeSketched2 жыл бұрын
Amazing explanation. Loved how the entire video "flowed" from start to end!
@marklord76142 жыл бұрын
Thanks, I'm in the camp of hearing these terms repeatedly without understanding what they mean. I needed this video. Thanks
@uidotdev2 жыл бұрын
So glad you found it helpful. Thanks for taking the time to let us know.
@danascript2 жыл бұрын
Thanks for this video!
@uidotdev2 жыл бұрын
You're welcome!
@charlene63062 жыл бұрын
Shut up ! Omg this is the best and most concise explanation ever. WoW! I’m so shocked. I now understand stand the difference
@uidotdev2 жыл бұрын
❤
@ryan.connaughton2 жыл бұрын
Dude please make more videos!
@uidotdev2 жыл бұрын
It's my biggest focus this year ❤
@ryan.connaughton2 жыл бұрын
@@uidotdev Woop woop! 👏
@vovandarius3 ай бұрын
My takeaway is that "imperative" and "declarative" are relative concepts like "new" and "old" but instead of the timeline the comparison lies in the level of abstraction. Any declarative code abstracts away some imperative code. However, the imperative code itself (unless you're writing machine code) will be declarative to an extent as it uses abstractions over lower-level concepts and computer commands. Hence, the same code is both declarative and imperative depending on the particular abstraction you're discussing. (e.x. the JSX definition for a Btn component may be treated as imperative code when compared to this component's actual use, but there's no denying that JSX is itself declarative as it abstracts away a lot of under-the-hood code)
@grantpitt30402 жыл бұрын
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.
@uidotdev2 жыл бұрын
Solid suggestion. Thanks!
@browny992 жыл бұрын
Very good video explanation, thank you! The Wikipedia definitions for these concepts is rather weird and this video isn’t. 👍🏼👍🏼
@uidotdev2 жыл бұрын
Glad you liked it!
@SumanRoy.official2 жыл бұрын
Awesome concept, never thought of this, keep it up 👍
@uidotdev2 жыл бұрын
Glad you enjoyed it!
@user-vp5oy4br3s6 ай бұрын
One of the best and most succinct programming related videos that I have ever watched! Major props!
@mskiptr2 жыл бұрын
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
@TheAdmiralBacon2 жыл бұрын
This was a great video, but the bit that immediately made me subscribe was when you identified *why* the common explanations for declarative/imperative only make sense after you already understand them. Convinced me that you know that you're a talented educator.
@FinnBrownc2 жыл бұрын
I actually think the first 3 examples are clearer. Idk if that’s weird
@uidotdev2 жыл бұрын
Actually not weird at all, was just hard to cover that in a video like this. Declarative doesn't always mean "better".
@andrew10072 жыл бұрын
It's for two reasons: 1. You might not be used to reading this type of code, so it's more of an issue of not understanding the declarations and their immediate implications. It's like the difference between your speed of travel when riding a bike for the very first time. It's going to be slow until you get used to it 2. This example is a proof of concept. Declarative code scales *a lot* better in production applications As a side note, here is an example that I think does a better job. Convert an array of objects into a string of comma-separated words. Which one would you prefer here? const toListText = (items) => { let text = '' items.forEach((item, idx) => { if (idx === item.word.length - 1) { text += item.word } else { text += item.word + ', ' } }) return text } const toListText = items=> { return items .map(({ word}) => word) .join(', ') }
@WillVanPelt Жыл бұрын
I wish all programming related videos were like this.
@nosouponhead2 жыл бұрын
How is a "for" loop not declarative with relation to the interpretor's implementation of a "for" loop?
@TheAwesomeDudeGuy2 жыл бұрын
I like this comment a lot. It too feel like declarative statements are just abstractions. You can always take 10 "declarative" pieces of code, put them in a file and argue that it is imperative compared to a new abstraction that encapsulate all of them, no?
@shuaima59892 жыл бұрын
Agreed, maybe the for loop vs js array method is not a very good example? Also as a bad js developer the reduce is harder to read than the for loop 😂
@kolega19992 жыл бұрын
@@TheAwesomeDudeGuy You are right with the first one, the author also made clear that we should have an API around imperative code to make it declarative. But I don't think you got the point of what imperative and declarative is. The fact that you abstract already declarative code, doesn't mean the code you abstracted is not declarative. Why would wrapping multiple components inside another component make the code inside less descriptive of WHAT is happening? You can abstract declarative code without it stopping being declarative.
@gustavoshigueo2 жыл бұрын
@@shuaima5989 this video by Fireship should help you with reduce kzbin.info/www/bejne/qoemipSVl9N8isk
@catocall73232 жыл бұрын
@@shuaima5989 lol I often default to more declarative stuff when I'm too lazy to go research yet again all of the nuances of those "easy" abstractions. Also, sometimes using all those abstractions leads down a dark spiral of twisted callbacks and return values. *Shudder*
@dangnguyen.922 жыл бұрын
i didn't expect this. Such a good video.
@uidotdev2 жыл бұрын
Glad you enjoyed it!
@StockDC22 жыл бұрын
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.
@uidotdev2 жыл бұрын
If I create an imperative abstraction is it more declarative?
@antialias2 жыл бұрын
The "declarative" implementations here still describe how to do the things: the example with doubling the array values still says: make me a new array whose elements are twice the values of the corresponding elements from the input array. I think what you mean by "declarative" here is actually "immutable" code, i.e. do as much as you can without reassigning the value of a variable, element, or property. When reassignment is used, then the order of execution starts to matter, and then doing fun things like parallelizing, proving correctness, and making assumptions about side-effects become a little harder.
@veedrac2 жыл бұрын
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
@uidotdev2 жыл бұрын
Appreciate the comment. Thanks for watching.
@bradmazurek2 жыл бұрын
Well said. Expressiveness and levels of abstraction are key to managing complexity...map and reduce do that...they are not declarative.
@AlFredo-sx2yy2 жыл бұрын
@@uidotdev this comment by @uidotdev basically means "i dont give a fuck, fuck off"
@catocall73232 жыл бұрын
@@bradmazurek Yeah I thought map and reduce were more of a functional programming thing rather than a declarative thing.
@Nathan17B2 жыл бұрын
I was about to take my breakfast and I though: "This videos looks like a nice option" I wasn't wrong about it. Actually fantastic example approach. Keep the content my friend!
@uidotdev2 жыл бұрын
So glad you enjoyed it!
@piranha13372 жыл бұрын
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.
@uidotdev2 жыл бұрын
That means a lot. Thank you Tony!
@UberMun2 жыл бұрын
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.
@khanfauji72 жыл бұрын
Great video - like this format with historical context.
@uidotdev2 жыл бұрын
Thank you!
@jealouscase36342 жыл бұрын
Great video! Your explanation was extremely clear and concise. I immediately got what I came looking for. +1 sub from me :D
@uidotdev2 жыл бұрын
Glad you enjoyed it. Welcome!
@TheKavlam2 жыл бұрын
Simple topic explained excellently! Thank you!
@oscarguinane21842 жыл бұрын
That's explained well. Good job
@uidotdev2 жыл бұрын
Thank you!
@user-dc6xc5lq6j2 жыл бұрын
Thanks, I've watched this video twice and understood! 🙏🙏😆
@uidotdev2 жыл бұрын
Glad it was helpful!
@RohanBagchi2 жыл бұрын
Nice video. Clean and simple. Please keep it coming :)
@MM-bw1lo Жыл бұрын
You had me at Beyonce! Thanks for getting me in Formation