Why spoil a perfect record? Yes, it’s March. No, Cross hasn’t shipped their pen for the Tablet PC.
Archive for February 2004
In a comment on my last post, Alex Peake points out the Dispose() method and the using keyword. This is what I referred to in the post as “implementing IDisposable”, but I realize that I glossed over that too fast.
IDisposable is an interface that defines a single method, Dispose(). If you have “valuable resources that have to be put back on the shelf” the recommendation in .NET is that you define your class as implements IDisposable and release the resources in the Dispose() method.
C# goes a step further and provides a keyword, using, that generates a try…finally block and, in the finally block, calls the Dispose() method of the IDisposable object that the using keyword refers to, for instance:
throw new EvenIfItThrowsAnException();
} //when execution reaches here, myNetworkConnection.Dispose() will be called
This is how you should get rid of valuable resources, not wait around for the finalizer to be triggered by a call from the garbage collector.
But that raises the question: if IDisposable and Dispose() are the .NET-recommended ways to dispose of non-memory resources, what is the purpose of the finalizer? That is, what are the recommended contents of Object.Finalize() other than a “last chance” call to: if(this is IDisposable) this.Dispose() ? And if those are the intended contents, why not just emit that IL instead?
I read Bryan Flamig’s criticism of C# via Loren. Bryan voices a common criticism of C#’s garbage collection (the criticism actually would apply to all languages that don’t go beyond the default memory management model of CLR, but let’s just continue to use C# as the example): in C++, the timing of when an objects is “cleaned up” is under program control (it’s fully deterministic), while in C#, the default behavior is that the timing is non-deterministic (in fact, reclaiming memory is an aspect of “cleaning up” whose precise timing is very explicitly beyond the control of the developer).
Bryan makes the excellent point that “cleaning up an object” certainly means releasing the memory for reuse but can also mean closing a network socket, database connection, file handle, etc. There are many examples of valuable resources such as these that come from a limited pool, and it’s perfectly understandable for a programmer to want to control the timing of when such resources are “put back on the shelf,” as it were.
In C++, releasing resources and releasing memory are thought of as one event. In C# and most other .NET languages, the act of cleaning up is thought of as being two events: the release of valuable resources (finalization) and the release of memory (destruction). By default, the CLR’s garbage collector guarantees that it will call a “finalizer” function prior to releasing an object’s memory. So, if you use the finalizer method to control your valuable resources and do nothing else, “cleaning up” is linked to the non-deterministic garbage collector. That’s the chief criticism of C#’s garbage collection.
But, to be fair, these non-memory resources are not what garbage collection aims to solve. Garbage collection aims to solve managing physical memory. Allocating and deallocating memory has unique problems (in that memory can point to other memory) and characteristics (the ratio of memory allocations and deallocations to, let’s say, the number of file handles opened and closed is approximately a zillion to one). So relying on an algorithm for garbage collection based on physical memory to time the clean-up of your valuable resources is a questionable strategy. But that doesn’t mean that garbage collection (of physical memory) is not a great advantage: the garbage collector is fast, it compacts the heap, and it goes a long way to help the most common types of programming bugs in C and C++. It doesn’t solve memory management, but it helps a lot.
So if you don’t want to rely on the garbage collector to trigger your finalizer to release your valuable resources, what do you do? You implement IDisposable and put the release of valuable resources entirely under programmatic control. Sure, that’s an error-prone burden, just like managing physical memory was. But it’s a start.
Now, can one imagine a CLR that had an algorithm that was optimized for managing non-memory resources? Yeah, but it might have poor performance. Or can one imagine some in-language facility that provides “deterministic finalization”? Yeah — C++/CLI will have such a thing and it’s certainly on the radar of the designers of the C# language.
But memory management via garbage collection? .NET provides a great implementation of a great idea.
My take on the debate of whether typing is needed in a language. Rather than taking sides, I revert to my previous incarnation as a philosopher, and try to see what we are really talking about when we seem to be talking about types. via [Artima Weblogs]
Jim Waldo says that strong typing advocates spend more time thinking about large systems. Yeah, I agree.
ReplayTV…I love download into MS lectures and playing them back at 1.5 speed…All media should be timeshifted. *All* *media*. via [Marquee de Sells: Chris's insight outlet]
I don’t even have a PVR and I agree. One of my many, many side-projects is writing a .NET CF RSS aggregator that displays the articles using RSVP (Rapid Sequential Visual Presentation — flashing the words at you at a rate that significantly exceeds your regular reading rate). So much software to write, so little time…
Peter just messaged me: “Hands down, InfoPath (prerelease version) is microsoft’s coolest ink app, after onenote.” I can’t wait to read his comments on his blog.
OK. That settles it. I’m downloading the prerelease InfoPath even if that means I have to reinstall everything later. Here goes nothing… via [Incremental Blogger]
Hmmm… InfoPath isn’t really targeted towards an independent contractor like myself, but if it’s mad for ink…
As seen at adimiron‘s place:
Step 1: Open your mp3 player. (iTunes here)
Step 2: Put all of your music on random.
Step 3: List the first ten songs it plays, no matter how embarrassing.
via [The .NET Guy]
Stuck In A Moment You Can’t Get Out Of” -U2
“Get Down” – Butthole Surfers
“Sunday Morning Coming Down” – Johnny Cash
“Acetate Prophets” – Jurassic 5
“Smells Like Funk” – Black-eyed Peas
“Baby’s Got Sauce”
“Insomniac” – Echobelly
“A Charlie Brown Christmas”
“New Age Girl” – Deadeye Dick
“The Shame of Life” – Butthole Surfers
That’s too good to be random (Down-Down name match, Jurassic 5- Black-eyed Peas match, 2 Songs from the “Dumb and Dumber” soundtrack, 2 songs from the Butthole Surfers), but that’s why I use Music Match Jukebox. I got to clear that Christmas stuff off my machine, though!
The January ’04 CACM’s lead letter is a smackdown of Hans Moravec and the concept that more MIPS is the path to AI. (When really it’s spam that will lead to AI.) Anyway, the author tersely makes the excellent points that people such as Moravec are again making the argument that “Someday computers will wake up,” with “the same intellectually faulty arguments and foundational quicksand AI has always suffered….Just because you put a picture of a chim and a human on the same graph with a Dell Computer doesn’t mean the chimp, or human, capabilities will be meaningfully measured in MIPS…[Moravec leaves] entirely undefined, unspecified, and unaddressed [such questions as]: What is behavior?; What is a mind?; What is consciousness?; What is reasoning?” to which Moravec’s lame reply is to pretend that the letter writer is caught up in “Western philosophy, let alone religion.”
There’s been virtually no progress in AI theory in the past decade. Everyone in AI seems to be crossing their fingers and hoping that some unexpected emergent phenomena will kick in when enough something (data, MIPS, facts, environmental input…) crosses some line. Maybe. I think it’s less likely than my joke that spam will lead to the co-evolution of machine intelligence.