March 09, 2004
The joy of real work
One of the nice, if unexpected, side-benefits of having a Real Job (ObPlug: Yarde Metals, a quite nice place to work) that's using Parrot is that I'm writing real application code to use Parrot. That means I'm dealing with it on all levels, from the guts of the interpreter through data to compiling to it and hand-writing runtime library code for the thing, with an existing target application to test with. (The day job is to write a compiler for a language called DecisionPlus, which the Day Job's whole application suite is written in, that targets something besides the limited back-end that is currently used. Parrot fits the bill really nicely, which is cool)
You may think that this isn't that big a deal, and that there's really no advantage or difference in perspective between designing a back-end system with a compiler in mind and designing a back-end system with the whole chain to the end application in mind, but that turns out not to be the case. In part it's a matter of needs (end application code has different needs than general library code) and in part a matter of emphasis (I'm working on code that might otherwise not get looked at so much, or so soon)
Objects are a big example there. It's probably no secret, if you've read back a ways, that I don't like objects. Yes, I know, they're rainbow-colored, fruit flavored, come in a variety of pleasing sounds with a nice mild vanilla scent, but... Bleah. Can't stand the things. It's a deep, unreasoning despisal, completely lacking any rational basis, I'm sure it speaks poorly of me as a programer, and reflects badly on my underlying character. I can live with that. Objects suck.
Still... I need them. Not for the pie-thon--my dislike of objects outweighs the threat of pie. Work, though... for work, through a quirk of where things stand in Parrot, objects will make my life significantly easier. SIgnificantly meaning possibly several months overall, and a few thousand lines of C and/or PIR code, though a lot of that time savings comes down the road. And so... we have objects. And it's all Yarde's fault, dammit.
Yay us, I guess. Think of Parrot every time you walk on tread plate. :)
Posted by Dan at March 9, 2004 05:07 PM
| TrackBack (0)
This is *not* an attempt at proselytizing.
I used to share your hatred of Objects, honestly. And for what I've seen 90% of what OO people preach is still for crap (then again, 90% of everything is crap). Inheritance is bunk, polymorphism makes my eyes glaze over, code re-use by subclassing is a myth (*nobody* in reality does this systematically). And to follow the minutiae of most OO discussions is watching programmers discuss angels dancing on the heads of pins.
My conversion happened about 6 years ago when someone pointed out that I didn't have to worry about all of this crap: treat objects like C-structs with built-in function pointers. Objects then became uncomplicated, useful things.
Since then I've written hundreds of classes, most doing useful things for employers and co-workers. The more esoteric features of OO methodology I use only when I'm trying to re-use someone else's code and *they* used the features.
These days when I read Angel & Pin discussions in places like P5P or P6L I just make sure, is it efficient (on the programmer) to make a class with the most basic accoutrements? If so, then I don't really care about the rest.
Inheritance and subclassing are indeed the suck, but polymorphism is fantastically important. Hopefully A12 will redeem it.
Oddly enough, inheritance and subclassing are what's making this all worth the hassle. Granted, I'm doing all sorts of evil, peeking back into parent class attributes to avoid redispatching methods, but still...
Polymorphism is indeed where it's at. OO is all about replacing long switch statements with a method call on an object; the explicit conditional in the switch statement becomes implicit method dispatch on the object's class.
That's all there is to it.
If you have to switch on the same condition twice, you won: you can add another case to both locations by introducing another class.
OO is a refactoring technique at heart.
The whole concept is pretty simple once you realize this fact and its implications.
Ouch, isn't it bad news for Parrot when its chief architect repeatedly express (out loud!) his hatred for objects? Considering that most of the important languages Parrot needs to support (Perl, Python, Ruby, even PHP) is to different extents "object-oriented"?
Oh, I dunno--it's not necessarily a bad thing. If nothing else, you don't have to worry about me getting caught up in the hype that surrounds objects. (On the other hand, if I do... that's probably a really bad sign)
Regardless of my personal feelings for objects, we have to have them. So we will. And, also regardless of how I feel about them, I'm going to do them right. (If I have to go through all this, I'l be damned if I'm going to end up with a lousy result)
Approaching things with a jaundiced eye, black cynicism in your heart, and a mandated mission may get you better results than trying something with that warm fuzzy feeling... ;-)