A Good Day At Work {computer geekery}
Jan. 3rd, 2007 03:00 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
tcepsaToday has been a very good day at work so far; I've rewritten a portion of code that used a bunch of cumbersome "if" checks to take advantage of the fact that JavaScript supports try/catch blocks. Now I just do what I want to do, and if it doesn't work then I fix it and move on. The fun part is that they're nested three levels deep, but in pretty much all cases I can actually recover from whatever broke it, fix the thing that caused it to break, and move on. No more shall I be at the mercy of (this particular aspect of this particular set of) data architecture!
As it turns out, that was just an appetizer :) I've always been fascinated by low-level programming, stuff like assembly language where you can go in and manipulate the CPU registers and such, or operating system code that you can look at and see how the CPU switches between processes. Having the ability to wield that amount of control is very attractive to me. On the other hand, it takes forever to do almost anything at that level, and it is ridiculously easy to make a mistake that will bring the entire system crashing down on you. So through a combination of impatience, lack of time, conviction that someone else had already done it better, and sheer terror that I would irrevocably corrupt my hard drive, melt my CPU, and/or somehow cause my computer to explode, I never really did too much in the way of low level programming. There was one exception, that being my embedded systems class back in college (to this day quite possibly my most favorite class ever). Still, I learned about the concepts, more or less, and one of the things that I picked up on was recursion.
Most of the time recursion is done by calling a function that then calls itself as part of its execution, until some condition is met (if you want to know more details about why someone might find this useful, let me know; it's not really within the scope of this entry ;) However, in this particular case I decided that I didn't want to do it that way. Maybe it was because I felt that I already had too many functions. More likely I just wanted to see if I could come up with something that would accomplish the same goal without having to rely on a function that calls itself.
I did. For the first time (probably since that embedded programming class, though possibly ever) I used a stack of my own creation. It worked pretty much exactly how I would think of a computer calling functions, or switching processes. It stored all of the relevant state data in an object (frame) and pushed that frame onto the stack. It then moved down a level in the tree that I was processing by loading the state variables with the information pertaining to that level. When it was done with that level, it popped the frame off of the stack and loaded its state variables, thereby moving to the next level up. It was tricky to make sure that the counters incremented in the right places to make sure I didn't miss anything, but it's working like a charm.
Sure, I probably could have done it more easily with the usual recursive function strategy, but I think I got a deeper understanding both of how recursion works and how computers work by doing it this way ^_^
As it turns out, that was just an appetizer :) I've always been fascinated by low-level programming, stuff like assembly language where you can go in and manipulate the CPU registers and such, or operating system code that you can look at and see how the CPU switches between processes. Having the ability to wield that amount of control is very attractive to me. On the other hand, it takes forever to do almost anything at that level, and it is ridiculously easy to make a mistake that will bring the entire system crashing down on you. So through a combination of impatience, lack of time, conviction that someone else had already done it better, and sheer terror that I would irrevocably corrupt my hard drive, melt my CPU, and/or somehow cause my computer to explode, I never really did too much in the way of low level programming. There was one exception, that being my embedded systems class back in college (to this day quite possibly my most favorite class ever). Still, I learned about the concepts, more or less, and one of the things that I picked up on was recursion.
Most of the time recursion is done by calling a function that then calls itself as part of its execution, until some condition is met (if you want to know more details about why someone might find this useful, let me know; it's not really within the scope of this entry ;) However, in this particular case I decided that I didn't want to do it that way. Maybe it was because I felt that I already had too many functions. More likely I just wanted to see if I could come up with something that would accomplish the same goal without having to rely on a function that calls itself.
I did. For the first time (probably since that embedded programming class, though possibly ever) I used a stack of my own creation. It worked pretty much exactly how I would think of a computer calling functions, or switching processes. It stored all of the relevant state data in an object (frame) and pushed that frame onto the stack. It then moved down a level in the tree that I was processing by loading the state variables with the information pertaining to that level. When it was done with that level, it popped the frame off of the stack and loaded its state variables, thereby moving to the next level up. It was tricky to make sure that the counters incremented in the right places to make sure I didn't miss anything, but it's working like a charm.
Sure, I probably could have done it more easily with the usual recursive function strategy, but I think I got a deeper understanding both of how recursion works and how computers work by doing it this way ^_^
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-01-04 08:07 pm (UTC)no subject
Date: 2007-01-04 09:33 pm (UTC)no subject
Date: 2007-01-04 10:50 pm (UTC)OMGSQUEEEEEE!!!
Date: 2007-01-04 11:26 pm (UTC)Re: OMGSQUEEEEEE!!!
Date: 2007-01-04 11:56 pm (UTC)