Ram Rachum

so I thought it was like using debuggers. Ever since I started programming, I would always do all my work in a debugger. I use a wing ID. And I know most people have never heard of it. Most people who most people use Python for their debugging. So it's basically the same kind of software. It's a good program to install. And it's the same same old kind of debugger that most languages have. And I'm very used to using a debugger. And I use it all the time. And I set breakpoints and I step through the code and I have my debugger automatically stop on exception, then I can travel up and down the stack and, and explore any kind of variables or run any kind of preparatory code, which I find is very useful for figuring out what's happening in your program. So I've done this since forever. For me, this is programming. But the when I started working with other people, especially on the side working being companies, I started, most developers don't use debuggers. And that blew my mind. And that really blew my mind. I mean, I was thinking, I'm going to see professionally purpose. We're very serious. But it turns out the They just, most of them use print statements. If they had a piece of code, and it's not doing what they think it should be doing, and they want to investigate, they add p statements or temporary log statements. And then they see the print output. And then and then they kind of have an idea of what they could do. Like they could add things technique at certain point in the code. And then they would know that that that certain point was reached. And they would add more p statements, different different parts, where they would kind of try to figure out the flow of the program, they will maybe expose a certain variable in a print statement to know what it is. I've done this in the past. We've all done this. But I was a little bit surprised that this method is so common, and the reason is so common, is because when you're working for a company, especially if it's a big corporate thing, the setup is usually very convoluted. I mean, you're working on a project that was inherited to you from someone who inherited it from someone else. It's usually a mess. record that you're writing is not running on your computer, it's running on some kind of other machine that your computer is connected to. And there is probably a complex bill crosses the chaff is your Python code around. And most people don't really know how to connect their debugger be pochamma with ID or any other program. Most people don't know how to get the debugger to work with whatever code will set up their corporate has. So most people just resort to using stateless which was very surprising to me. I'll be using p statements for debugging. I think it's both I have mixed feelings about it. I think it's both very beautiful and very part of course is is how ridiculous it is because you have to insert these print statements manually to code and then see the output and then do it then you usually realize you wanted to put the print statements somewhere else to do a back and forth feeling your project most of the time just to get the information you wanted, which to me such frustrating process. So that Sorry. But the nice part is that it always works. It doesn't matter how can we look at your Saturdays you can always print to standard out or at least write too high. And this is the reason everybody uses print statements at some point or another, because it's so really resilient talks everywhere. So I'm getting to a thought about what he was passing over. So I was thinking maybe, I mean, after many years of seeing people use principles, I was thinking, maybe I could do a compromise. Maybe I could provide a solution that is as resilient as speed statements, and as easy to use him but a little bit more powerful a debugger. So that's what I'm going to describe have someone would use it and what he provides, let's say you wanted to use by surface to devalue code. So obviously you do a pip install a price, no pain impulse buys, no. But then you go to the function which you want to understand what's going on. And you decorate it with the Heisman Trophy, dasu decorator, and what that does. basically done sort of automatic log your function as if you put a print line on each and every line of your function. And this means that when you run your code, you're going to get sort of output text of all the lines of your function, the trend, one by one. And anytime a variable got changed, you're going to get Alliance a variable exchange and its new value is recent that says, sort of instead of going back and forth, and adding p statements, sort of just automatically prints everything you might need when you can take this text output and look at it and sort of figure out lately what's going on. So that's, that's the gist of the solution.