5:48 representation*

Then cover the anyhow crate

Oh, cool ! I tried something like that with the run-shell-command ( it didn't work well lol) But with this insert-output one, we can even make build system ! Ty for showing this.

Opens a new dimension of integration with a simple example. Thanks a ton for sharing !

Stashing in Lazygit is not working in your approach

Recursion moment

Awesome idea! subscribed!

lazygit works fine, but gitui doesn't. For information -I have only tested this on NixOS with the Kitty terminal Too bad! I'm going to keep a tab dedicated to gitui alongside my helix. My workflow is usually one tab for helix, one for git and one for building my projects.

I have no way of exiting the commit message window. Esc and Ctr+c just insert some strange characters. How do you exit a commit message when committing from lazygit inside helix?

Thanks!

I like to think out loud when I'm coding and I say stuff like "letsss goo to the terminaalll" and I just alt+tab a few times between the tabs until i find the terminal window, i would love it that if it just switched to the terminal window, this tool looks flexible and would be pretty nice to have in my workflow

Emaculate

great content

WHAAAT, and I was doing TMUX popups like a caveman.

That's a cool tip. I like it

great video! surprised that this quality of video doesn't have more views

Thank you. This is a very nice tip, usually I combine this with zellij or tmux, so I create a new pane, now I just need to use the shortcut defined in helix config. Nice. I'll play around to see if I can use this for `yazi` as well. Helix currently didn't have file manager. Sometimes I want to show the file structure when I try to teach someone.

Sadly it doesn't work with gitui, helix simply freezes :/ I won"t switch to lazygit for that but its a nice trick you found here !

This crate sounds amazing! To me it fits with rust's approach of using less boiler plate, when the default implementations will suffice most of the time. Thank you for introducing it to me!

Man the animations are smooth like butter , and great explanation ❤

Very good video and good explanation

I use this command bc I like seeing a bit of space around the edges. It only works in tmux but for me I'm always in tmux. C-g = ":sh tmux popup -d \"#{pane_current_path}\" -xC -yC -w80% -h80% -E lazygit"

Great video!

I told you so 🐒

I need to find an excuse to code Rust sometime, there's so much weird and interesting stuff in this language. Maybe sometime I'll want to hack on a Rust codebase, that's usually how this stuff happens for me.

Clean code is great as long as you are planning for the total time spent writing the code to be significatily longer than the time spent running the code. But in most industry applications this is not the case.

+ 1 for showing assembly

need a mic my dude.

"99.9% of the software we write nowadays has no need of nanosecond performance. I’ve built a real time, GUI based, animated space war game using Clojure. I could keep the frame rates up in the high 20s even with hundreds of objects on the screen. Clojure is not slow." --Uncle Bob🤡🤡🤡

I think, write code that is easy to understand as a human and accommodates current requirements (extensibility, maybe). Then profile and optimize only the key things that impact runtime where it’s critical. So it’s is important to know these tricks, but there is also a reason we are not all writing in C (or even assembly).

You are missing the point. One uses abstraction layers for complex systems, or to allow future functionalities to be added with no change to the code (e.g. adding a subclass versus adding a new value to an enumerator). If you work with embedded systems you will often use a language that offers little in the way of abstractions, and you will often favor performance and reliability - but you will comment the code explaining why the operation is performed in such a way. And that way is often tied to the specific processor architecture (and also to the rest of the hardware around it), so if anything changes you may have to change the code. One can even use FPGAs to "program hardware" to perform a single task but do so in a very efficient manner. When performance is key you can go to the extreme of having hardware specifically designed to perform a task (e.g. see how graphic cards came into existence). On the other side now-a-days you can write programs and compile the same code to run in different hardware, and even on top of different operating systems, with maybe only the need to be recompiled. That flexibility will have it's cost as there has to be some layer doing the required conversion to OS and HW specific calls somewhere. Programming is always a choice between processor and memory usage, between readability and performance... So write code that works, make notes of the rationale used, test to see if the performance is enough or if the compromise between the mentioned parameters needs to change to accommodate the requirements.

As someone who writes a lot of avx code in asm, it has become clear to me that the foundations of programming, the data structures and code-flow constructs*, that were good bases for abstractions when they were designed back in the 1970's and 1980's due to the functionality of the processing hardware of the time, are not good or fitting to modern processing hardware. I can, however, imagine (though only vaguely at this point) what more suitable abstractions for modern hardware might look like**. The basis of C and thereby C++, and nearly everything that has followed, was what the asm programmers found themselves doing over and over and over again back when C was created. The things I end up doing over and over are not the same things they were doing, because the hardware has changed. Creating highly performant and readable high-level code should be possible, but new base language constructs and the ways of thinking that go with them are needed to fit with the highly-pipelined***, simd-capable hardware we now have. What we have are trucks capable of carrying many tons of cargo each in an efficient way down a long straight highway, but we are asking them to navigate tiny streets with may tight turns to deliver just a single 1kg package most of the time. * eg. polymorphism through function-pointer tables attached to multi-data-type structures represented by a single pointer to an assorted collection of data items in memory ** a variety of bulk data types with associated higher-order functions that take lamdas that the compiler can inline and properly optimize for the data types involved *** one of the biggest issues for a modern CPU is knowing far enough in advance what code it will be running. When it gets its predictions wrong, it incurs a heavy penalty equivalent to >100 instructions being executed, and it's only getting worse as the execution cores get wider and the decode-pipeline stages before them get smaller. Code which doesn't have to decide which way it goes when it gets there based on something it will only know when it's got there allows execution to flow at the full speed the core is capable of.

There is one point that I haven't seen discussed much in the comments, it is the environmental impact of "clean code". Higher performance means higher carbon footprint usually, because we associate that to higher energy consumption from newer, more power-hungry hardware. Here however, higher performance is achieved through leaner, more efficient code, but it isn't prioritized over maintainability and that leads to higher energy consumption. If there is one argument in favor of "unclean" code, it will be its greenness.

I'm accumming

People need to understand that 99% of all CPU time is spent in just 1% of all code. So even if clean code would mean that you end up with super slow code, that is no excuse for not writing 99% of the code that way. You can still write dirty code for the 1% where performance really matters. There is a reason why number crunching code is written in C or a similar low-level language, or maybe even as a shader that runs on your GPU. However, the majority of code out there is no number crunching code but business logic. Also, it's kind of ridiculous to argue about how dynamic dispatch is slower than static dispatch in Rust, when the majority of new code written today is written in JavaScript (or hopefully TypeScript), which uses multi-indirections for pretty much everything you do in that language, and there's not even a way to avoid it. The slowest Rust code you can write is still 10 times faster than the fastest JavaScript code you can write, and yet you see web apps and Node.js apps everywhere. Why is that? Because JS is super high-level, super flexible, and super dynamic, and speed is just one property of a language model. The last time you bought a car, did you buy the fastest car on the market? No? Why not? Did you even consider speed as an important feature? I'm pretty sure you had a lot of reasons why you chose that car over all the other cars you could have bought, and I'm pretty sure speed was completely irrelevant to that decision. If your code is full of bugs, or hard to maintain, or impossible to extend, who cares how fast it is? Fast at what? Fast at crashing or corrupting data? Certainly not fast at implementing a new feature if it means having to rewrite most of it because of a lack of abstraction.

This clean code stuff clearly not meant for C but a higher level languages.

I didn't know 3Blue1Brown also made coding related content.

This usage of Shape is a bad example for this sort of showcase because outside of your artificially crafted example you're not going to find anyone using shape abstraction like this. Shape abstraction is meant to be open to extension. See: Java's java.awt.Shape. You'd have to keep using Box<dyn Shape> to replicate this and it would need more than just one method for calculating a number. Also, your benchmark is meaningless because testing dataset is not randomized. By creating all shape types in a static way (0, 1, 2, 3, 0, 1, 2, 3, 0, 1, ...) you taint the test by teaching CPU's branch predictor which branch is going to be used, this will result in major discrepancy between results from your benchmark and production. A proper benchmark should randomize shape generation to avoid this very issue.

I think it's important to keep in mind what the focus is. The point of "clean code" is readability, maintainability and extendibility, not performance. On the other hand, this super-optimized code is very fast, but on a large scale very hard to maintain, read and especially to extend, as you'd have to edit dozens or hundreds of switch-case statements all over your codebase once you want to introduce a new type. The best solution, in my opinion, is a clean code API/clean code for publicly accessible types, so they are easy to use and extend, while having highly optimized code in the internal details of your library, aka the code locations where the important work is done.

funny thing is, even at 11x faster this is still hilariously slow. a modern CPU (11th gen with avx512) can actually do the task in 291ns if you set it up right, and even older cpu's would manage 582ns as long as they have avx2 for a vpermps instruction to vectorize the multiplier lookup. (I assume here that "iteration" means a cycle of 10240 shapes, and all benchmarks are for a single thread) I understand that people want to support use of older PC's but anything older than AVX2-baseline CPU's literally can't keep up any more. I have an old eeepc with an intel atom CPU that only does SSE4, and it cannot play a youtube video at 360p in the browser (although it will still play a 720p mp4 with vlc), it struggles to even load the page. The only thing it's useful for is writing in a text editor. Even my newer(2013) sandy-bridge i7 laptop was unable to play youtube vids unless I full-screened the video (probably the overhead of the new telemetry and animated suggestions sidebar they rolled out in 2022) before it died last year, and even then it was getting seriously sweaty doing it. I wonder if there was less "clean code" who's authors had assumed that everyone was running the same super-fast latest-gen workstations that they are and so "the performance hit doesn't matter", whether those older machines would still be useful... I also noticed someone commenting "why doesn't the compiler do that 4-accumulator automatically?", the reason is that compilers cannot do anything that could change the outcome of the program, and mathematical rearrangements, although logically and mathematically sound can potentially produce different results due to the different appearances of rounding errors and overflows. It should be possible to enable those kinds of optimizations with a compiler switch. But the optimizations I conjectured with above are not ones that any compiler could do for itself ever, since it involves rearranging the data and logic for data flow. But still, 185x faster is a lot to leave on the table for readability.

Of course the code looks horrible, it's written in rust

click bait

0:43 What is this font?

You calling registers "resistors" really bothers me.

I've known about radare2 for YEARS and this video was the one hurdle to actually getting to grips with it and understanding how to use it lmao

I have lots to say, in many domains of computation performance is nice to have unless it is abysmally slow. Main focus is developer cost and flexibility, you are a resource/hazard that comes from being a human, clean code tries to improve your benefits and reduce your hazards to mostly other humans. Clean code don't care about software it cares about developer. It is a hard job, requires close collaboration with others unlike single factory workers and low in demand a.k.a. you cost more than companies would like, improving developer experience is more important than having optimized software(in major). I say these as someone who loves! optimized software. Only a few things gives me more joy than seeing lower times, using less power and higher frame rates as I am a game developer where performance is a critical business metric(more devices at 60fps more profits). As a programmer you should profile and find biggest potential improvement area's(generally long plateau or dense combs, long singular operations and many minor operations respectively). With good profiling you can get around %80 of the improvement in 1/10 of a time, this is generally enough to hit your target both in performance and in work hours. This is not the end, sometimes you need to go deeper and write your own simd including algorithms and multi threading which can give you more performance than the compiler would, you can even divide by zero in the land of assembly and no one will fuss about it (if usage is correct). The main cost comes as; harder learning curve, ultra rigid code, harder for some one else to edit the code. Companies tend to not go in this direction as much as they can. As I write these down I realize my journey on programming is more travelled than yours, and feel older. It is good that you question things. With time your view on things will get better, biggest of them all is Trade-offs. Live longer see more of the picture, also add a little bit. Thank you for giving effort and making this video, its more valuable than context and conclusion. Wish you a fulfilling journey.

Clean code is optimization for the human operator and, by extension, human-operated constructs.

In my experience, code that's easily readable to humans is not easily readable for computers when they try to run it. Some of the most efficient code looks horrible and I sometimes need find text just to work on it. lmao

I'm no programmer but I'm of the opinion, that code only needs to be fully understood by the author. All the other copy paste cowboys should put a little effort in, understanding what they copy pasted. I'm a 3d constructor, my parametric 3d models rely heavily on self made variable "frameworks" and string together a lot of trigonometric knowledge. My coworkers are a little jealous of my models and optimized workspeed. I gave them my models, then they questioned me how all that works and if I could give them an instruction. Honestly, when given fully variable assemblies, one would assume to invest some time to understand what one is dealing with and how it works. Not pestering the author to spoon feed the ignorant ones. My conclusio, I'm not sharing models anymore, they can copy them out of the project folder anyway. Can't prohibit that, but will not make my assembly structures and parameter framework easier, instead optimize more, less verbose, less understandable variables, more squished together formulas in one parameter. If they want to understand what is going on, they will have to work for that. 😑

tbh. The clean code like this just seems like "clean" by hiding the mess under your bed. Throwing everything and the kitchen sink into the same array at random is anything but clean, that's a junk pile. Factorio players understand it intuitively - that's a sushi belt. Using polymorphism in this way is building a whole base with sushi belts. My opinion is that code follows data. If you have a clean, organized, sensible memory layout, then the code to work with that data will naturally pop out nice and simple and clean. Rather than three types of things, I look at that and see three _arrays._ There's a box array there, a circle array, and a triangle array. They're all big and homogeneous and the code to compute the areas for all of them is dead simple, you have a square area function, it's a nice, pure function with no internal state, you give it a square and it returns an area, then you just do square_array.map(square_area) And if you consider the array as your basic atom and not the individual object/value/shape, then you can go right back to all those clean code abstractions _without_ killing performance. You're not polymorphic on the type of shape, you're polymorphic on the type of array. The layers of indirection are amortized, you only go through it once instead of 100,000 times so the hit really is negligible. And the computer is very happy, you have big homogeneous arrays that can take advantage of all those nice things CPUs love, like cache hits and SIMD and structure of arrays instead of array of structures. It also tends to nudge you away from allocating a lot, you kinda just make the one big array allocation at the start instead of billions of teeny tiny 8 byte objects as you go. Figure out the right memory layout from the start, you become a happy programmer with a happy computer.