FP scratches that itch when you don't really need a formally declared method/function but have a lot of very specific stuff to quickly get done. It's creating several quick "do some stuff with some things" bit of logic, almost like macros, that you can pass around (in languages that support it). Once you grok the concept, it opens up your world to intelligently break complex tasks down into simpler ones with less keystrokes and less code clutter. The problem is it's not nearly as readable and followable as more traditional code. You could arguably say it's an order of magnitude more complex to follow and read along with than non-functional programming. In 20+ years of professional software development as a .NET developer, other than things like Predicates (in Linq .Where) and arguably Projection (Linq .Select), you pretty much never see FP in production code. I've floated the idea by teammates from various companies in the past and nearly all of them have poo-pooed the idea of using FP in prod code, to the point they would probably reject any PR's including it.

I think that this is really going to depend on the language. If you're doing any serious shell scripting, comments are invaluable - sure you *can* sit through and work out what a long piped expression means, but far easier for the author to at least briefly explain it, especially given how arcane shell commands are. If you write a regex, you had better comment on at the very least what the intention of the regex is, and I have had no issue with taking multiple lines of comments to explain a complex regex before. Comments guard against folks who don't write readable code - I'd much rather have unreadable code with comments than without.

My argument for naming things *Interface is that it makes code review a ton easier. Having worked on teams where younger developers are inclined to just type against whatever concrete type they're using at the time rather using an interface, having all interfaces in "Interface" makes it a lot easier when scanning code to say "Hey, maybe you should use an interface here"

3:00 hahah

No no no. Why would you remove intent? Comments get compiled out anyways. Sorry comments are required where I'm concerned.

whole recreation of loops in functional is what recursion is.

This was so good, more videos like this please!

2:04 there’s an advantage to it when trying to hide code on another’s device

I agree with the "don't name things single letters names", with the caveat that for certain functions which are abstract math (abstract in the sense of not being tied to a specific problem domain), like for instance "divides", it can make sense to call the parameters x and y, because the inputs are just abstract values. Though in this case you could also say dividee and divider or something like that, I suppose

i'm sorry, but i believe in snake case supremacy

Sometimes it's better to repeat yourself in the code, rather than overabstracting things and dive into "abstraction hell". Just make your program do something interesting first, and than you may think about restructuring and abstracting code pieces.

Please keep making more videos !

Please keep making more videos !

Just don't nest your code too much. It's a pain in the ass to go through the codes 😂

there is also second rule, function no longer than 20 lines of code

I feel like this is a mostly pretty good perspective, while also I think its kinda strawmanning the FP community a touch. A core thing I think needs to be pointed out is functional programming is never actually about eliminating state, its about controlling it. Even in Haskell when all your state is in monads and theoretically pure or whatever, it is still state. The point is just that by tightly controlling state you get lovely guarantees - I think of it as the guarantee that you will never be hit by gotchas in the vein of 'oh yeah, python default argument elements are mutable'. And in terms of pure FP conflicting with the fact that computers are stateful? Yep, very much. The whole point is trying to write your code in a way that's easier to reason about, and trusting that a compiler can work out how to make that work on real hardware.

The comment can lie, outdated document too.

Elegant code. Is beautiful. The title. Has flaw in its title. Beauty and flaw. Go hand in hand.

We all use static types? Not sure where you found a rock to live under that you'll never have to use javascript or python or any of the many, many, many dynamically typed languages out there. Maybe a better title for this video would have been "rules for programmers who will only ever use C# and who will always have an unlimited budget for giant 4k monitors"

You just made me realize that I was a never nester all that time

Loving the Allman style indentation for the example code but why not Allman-8? The Allman-8 style does indent a lot per level which makes it really really obvious when you're writing bad code with lots of nesting. I guess I'm equally strict to kernel developers when it comes to nesting but I definitely like Allman style braces. I also always indent code with exactly one tabulator which allows other editors to have smaller looking indention if they truly wish. When you indent with spaces, everybody must look equally much or little intended code.

The name of the pattern being used in this video with Dependency Injection is the Facade Pattern. It is one of my favorite patterns to use in programming.

One thing not covered was naming with correct noun/verb tenses/agreement. E.g: MovieRecording vs. RecordedMovie. One implies action whereas the other implies data. This can be meaningful if you are a user of the class. For interfaces, I don't agree. The I allows you to discover available interfaces easily by typing I and it distinguishes them from the inheritance of a possible concrete base. You could remove the I, but you would need to use a very consistent naming scheme to retain this benefit. This is particularly true in c# or other languages than do not support multiple inheritance. That being said, interfaces should be named with the correct adjective style as well: Resolvable vs CanResolve for instance.

"Here, is 4 deep" - almost immediately screen wipes it away

//Ok

Didn't know my condition had a name 😮.. Proudly a Never Nester!

I use comments as labels. Usually one word and a lot of '/'. So when I scroll down my code I know pretty quick where I am.

I confes.

What tool is used for code animation slides?

Perhaps its the C# developer in me, but I disagree with the premise that you should not put types in your type names. Swapping out a concrete type with an interface for a function parameter does meaningully change the behavior of your function in many cases. For example, in unit tests, the dependencies of the class you're testing should be interfaces so that you can mock them to isolate behavior. By using concrete types, you make it impossible to unit test in isolation. Prefixing interfaces with an "I" therefore communicates to the consumer that "this dependency is safe to mock". Most mocking libraries (at least in C#) do not tell you whether a type is mockable at compile time.

Really good explanation between inheritance vs composition❤.

I initially tought u meant non tabulater 😨

I agree with most off this, but in the gcc implementation of the standard cpp library you do get things named base: . . . 00088 enum _Rb_tree_color { _S_red = false, _S_black = true }; 00089 00090 struct _Rb_tree_node_base 00091 { 00092 typedef _Rb_tree_node_base* _Base_ptr; 00093 typedef const _Rb_tree_node_base* _Const_Base_ptr; 00094 00095 _Rb_tree_color _M_color; 00096 _Base_ptr _M_parent; 00097 _Base_ptr _M_left; 00098 _Base_ptr _M_right; . . .

sorry boss, this requires me to understand my code

I write SQL, which is quite a bit different than the kind of code we're talking about here, but I share this sentiment. Whenever I read a query that has subqueries within subqueries within subqueries within subqueries I have a panic attack. That junk is going into a CTE or Temp table and unless there's a significant drop in performance, it's staying there.

Well explained, seems like we've gone full circle. Can't wait till AI can code for us and we can just give it direction.

5:57 if that's a Node (i.e JavaScript/TypeScript, you shouldn't have used a Utils class either, let alone a Utils file. If a function doesn't use any data from the attached class, then it should just be a function, not a class method. I see this sometimes from C# or Java developers doing JavaScript, thinking that everything must be a class.

What if you want to iterate over a 4D array?

Gawdammit.. I came here to say it's just nesting with extra steps.. but I am leaving a changed developer. Thanks a lot jerk!! Lol

Cool video *names things x y & z anyway*

Absolutely stunning and I was quite amazed by the clarity of this video. As a total beginner to functional programming (with years of experience in OOP and recursion), I find it crispy clear with the visuals that you created. Thanks again for this work.

"dramatically increased the number of conditions your brain must simultaneously hold". This is why we need to rewrite code every 5-7 years. Having had the opportunity to do so several time now, I can't being to explain the sense of relief it brings to refactor not just a function, but an entire code base. This is why I've been at my current job the longest ever. "dramatically [decreases] the number of conditions your brain must simultaneously hold".

I’m an anarchist and you won me over when you said “there shall not be a state”

Really got me thinking with the line: "they're hard to get right, but they're also easy to get wrong"

I finally get it! Explaining recursion using for loop is amazing. Thanks man 👍

I just hear "waaa waaa coding too complicated I dont wanna take in consideration low level stuff my brain goes rbrbrbrbrbr" hahahahaa skill issues all over the channel

just switch to switch statements

This drives me crazy when I see it. I would have like to see some discussion also of the pros and cons of"functions should only do 1 thing". I feel like that goes hand in hand with this knee-jerk repetition is always bad idea because they both come from that "Clean Code" book. I hate sifting through rats-nests of 1000 functions calling each other that are all 2 lines of code. It is usually much simpler to have 1 longer function that at least handles the overall control flow so functions aren't just arbitrarily calling each other in a way that is impossible to follow in the code. There are benefits to having the same scope when you are calling many different functions, it makes return values less important and you can be sure that you always have certain data available in memory rather than passing it through. A lot of OOP concepts create really horrible anti-patterns if followed blindly.

Thank you, this connected several dots!

honestly, I nest my code because I want it to look more square rather than too vertically or horizontally elongated