Tcepsa's Thoughts

Due the week after this coming Monday (i.e. ~10 days from now) a line-following Lego robot and an Arduino that will blink an LED in the Morse-code equivalent of whatever strings are sent to it.

It's gonna be a busy weekend!

(Posted to the local Java Users Group mailing list. Reposted here for your edification, or at least hopefully enjoyment ^_^)

There are lots of reasons why polymorphism (one object being treated as a different kind of object) is a valuable thing to have in a programming language.

( Centered around a certain clandestine theme... )

This didn't actually happen to me at the time, but it would have been incredibly apropos of my mental soundtrack to be playing Weird Al's "Everything You Know Is Wrong" while I was trying to figure out why my Elevator Simulation Project (the last one for my C++ class) wasn't working:

Everything you know is wrong
Black is white
Up is down
And short is long
And everything you thought was just so important
Doesn't matter

Everything you know is wrong
Just forget the words and sing along
All you need to understand is
Everything you know is wrong!

I'm really not supposed to stay up this late on a school night... except dammit, I needed to get the assignment done!

Frakking memoization. The worst part was that my implementation of it was such that the "optimization" actually caused a significantly higher processing time. Stupid graphs and their stupid paths anyway...

But I'm a better programmer for it. Proof that I'm learning in this class: by the time that I wrote the double-nested for loops to ensure that I wasn't letting false positives through, I was starting to suspect that I'd be looking at at least O(n^2) for it. Given that those are happening _inside_ another double-nested set of for loops, that should push the whole time up to, oh, about O(n^4) if I remember right.

SO VERY MUCH LESS THAN IDEAL. Fortunately the memoization part was for extra credit anyway, and I should still be able to score that with a slightly fancier version of the paragraph I just wrote. "I may be taking the Edison approach, but I'm learning! Also, optimization isn't always!"

PS Why am I doing so much algorithm work in a data structures class? ~wry grin~

PPS (Yes I realize that the only good way to appreciate these things is to use them to facilitate the construction of spiffy fast algorithms. And I do. ^_^)

Actually, at this point it has been somewhere between one year and two since I encountered the programming concept of "closures". When I first encountered closures it was in the context of Javascript, and someone had told me that I should be careful with the toolkit that I was using at the time (Dojo 0.42) because it apparently used them and they have a propensity for causing memory leaks. I did a little bit of exploring but was unable to come up with a satisfactory explanation of what they were or why they would have this effect. The result was that I had a sort of nebulous impression that a closure was something that happened--not something that was--when a newly created object ended up with a reference to one or more of the local variables back in the method that called it.

That was pretty much my understanding--and I knew it couldn't be right but at the same time I was keeping an eye on my memory usage and it didn't seem to be getting gobbled up too quickly, nor did it seem that it was never being released. So at the same time it wasn't really a pressing enough issue for me to pursue it terribly deeply. Then, last Autumn, I went to the No Fluff Just Stuff consortium and learned of a language called Groovy. One of the things that makes it so powerful is that it has fairly extensive support for these closure thingies. I got a slightly refined understanding of closures (at least Groovy closures) during the conference and figured that maybe they had decided to use the word (which I still thought was more of a verb) to refer to these somewhat magical functions that could be passed around like variables and have properties like objects and retained references to the local variables that were in scope when they were created.

And now today, about four months later, I was reading the appendix to this article and came across a parenthetical statement that finally tied everything together: "In OO languages, you can, to a limited extent, simulate a closure (a function that refers to variables defined in enclosing scopes) [...]"

It's like there's this lightbulb in my brain that I screwed in back when I first heard the term, and it's been sort of glowing dimly off a trickle current this whole time, and when I read that finally it flared into brilliance! It's called a closure because, for all practical purposes, it's enclosed!! And therefore it can see all of their variables! And furthermore it can screw up garbage collection because it has a reference back to the enclosing object and garbage collection only happens on objects that aren't being referenced by anything that is, or is being referred to by, something on the stack! It doesn't actually screw up garbage collection--GC continues to do its job just the way it is supposed to--but it can trip you up, and that's what they were talking about when I first heard the term.

EUREKA!!! ^_^

(while my understanding may still be less than complete, it is a quantum leap better than it had been before reading that sentence ~grin~)