|prev : next : index||SPEW|
Ok, here's the new plan. I don't have the time or energy to update daily now that I'm working, and being consumed with guilt over not updating isn't useful if it doesn't motivate me to update.
So from now on I'm going to try to update once a week. Hopefully the guilt will keep me on track.
I still feel like I don't have anything to say, anyway. I'm currently decompressing after spending the last, umm, geez, let me check my grocery receipt... five hours blasting through Orson Scott Card's new Ender book, Ender's Shadow. Short review without much careful thought: I was worried in advance of reading about how he would undercut Ender's uniqueness by making the folks around him seem more like prodigies themselves. My fears panned out--Ender seems less unique--but I'm not sure whether that was bad, after all. The story was fun, an interesting take--and I felt more like this was a story worth telling than Children of the Mind.
Work is... work. I can't really talk about it in much detail, of course. We're playing with more formal notions of process, so I've been doing bunches of reading about some of these things.
We're not going to be doing refactoring in its most refined form (automatic refactoring with a browser), but reading the book on it really turned me on to the idea. I've always loved the design of Smalltalk--my MUD system, Sludge, was built largely on my knowledge of the Smalltalk object design, although it steps far away from Smalltalk's principles.
Refactoring, a process for taking working code and making it cleaner internally without changing its behavior in any visible way, is something I've always done informally. The notion favored by this book (Martin something, dammit, don't have it handy, in concert with many other people) is a much more formalized process, and I think that's a good thing, given that it takes working code and outputs working code to do the same thing, sure, make it formal.
On the other hand, the same cluster of people's efforts in "Design Patterns" has always left me cold. Now, to be fair, I simply haven't read the stuff, and maybe if I read it, I'd change my mind, but refactoring was interesting enough to motivate me to read it, and design patterns isn't. My concern is that patterns formalize things that shouldn't be formalized. It moves the realm of the creative interaction between data structure and algorithm into formalism. It does something I've always done and formalizes it, just like refactoring, but I don't think it's a good idea. Recognizing the commonality between these three similar cases is nice, but it may blind you to the differences, and the opportunity for differences.
This is similar to how I've never accepted the object-oriented paradigm shift. I think objects are great for the simulationy things that Smalltalk is known for. And I think abstract data types, the original pre-OO paradigm, are brilliant. Object-orientation is just a slight advancement over ADT in many ways. Explicit interfaces, like COM, are also brilliant and powerful in many ways. But in my non-OO paradigm, not everything needs to be or wants to be an object. I think I could learn to make the shift, to start wanting to treat everything as an object, but I don't feel it's the right paradigm. Code and data do not always drop into nice neat packages, anymore than all code fits a pattern. The data can always be clustered, and the code forced to be associated with some piece of data, but that doesn't mean doing so is "right" (whatever that would mean), or useful. Certainly, if somebody you're working with has made the paradigm shift of treating everything as an object, they'd rather it all be packaged up into objects, and it's hard to explain why it shouldn't be. Under their paradigm, everything is simpler, because everything is an object, so you only need one thing. But this is obviously fallacious, since diversity--applying the right tool to the right job--is obviously important as well. Unfortunately, this devolves to the C++ vs. C argument--one is a superset of the other, so of course it's "better", which of course misses out on the fact that one has a higher cognitive workload than the other, and may be "more expensive" to use, in some sense. This is really hard to debate with somebody who's made the paradigm shift, because what's apparently harder once they've made the shift is working with the code that's not OO. But it's impossible for them to see the overhead of forcing everything into the OO paradigm.
Rant rant rant.