|P is for Practical|
Reinventing the spaceshipby nothingmuch (Priest)
|on Apr 08, 2003 at 16:12 UTC||Need Help??|
/me takes a pop at meditating...
In my years (3 whole years) of perling I have discovered the fantastic cpan. Naturally.
I have made extensive use of it's resources, and even thought of contributing several times (I eventually backed out because I thought I didn't write mature enough code).
Perl being my only practical (or real) language learnt and actually used, I know that whenever I need something done there's always cpan, and that's all I know. Fabulous modules like the various DBM modules, Storable, Time::Local, and URI to list a few, are what gives Perl the margine between great and fabulous - resourcefulness. These modules have something in common.
Recently I've been working on a project which does a lot of OOP. Everything within is an object, is created by another object, or is responsible for dealing with objects. Some of these objects require persistency, within a database. These objects are actually a unity of an object describing how to find the resource the object represents within the database, and another representing the database itself. Such objects can also be created right into the database, and in the end it all gets translated into SQL. I've finished planning their representational core - what are these objects actually, and how you work with them. Now comes the implementation.
Hopping on to cpan I delved into the many DBIx::, SQL::, and whatnot namespaces and modules. I've read pod after pod after pod. Everything is different, so powerful, so clean. These abstract DBI access so gracefully, and yet there's always something wrong.
Each of these modules has something so alienating about it - it's not me. I'll never remember the non minimalistic API, because it's not minimalistic and it wasn't thought up like I would think it up. I end up wrapping the wrapper in more wrappers. I hack a method, I use base;. In the end the mishmash that comes out is so ooky I'm scared of it. I get to the end of the doc and back up the trail of hypothesis that my mind walked about. I decide not to use the module. After pod.
I contemplate reinventing the wheel.
I'd like to object about the metaphor 'wheel'. A wheel is good to analog a module like Time::Local, or Storable. A wheel is simple. There's one way to use it - an axel. It rolls on the axel, and reaches a point. Perhaps I'm going too far with this, but here's where my problem is. The modules mentioned above, those I decided not to use, are not really wheels. They have so much whiz bang about them, so many different things that they (can|are supposed to) do, that they look, in the metaphorical sense of course, more like a spaceship.
I contemplate reinventing the spaceship. Why is this wrong? Reinventing the wheel is wrong, unless you're looking to learn something from it. But you don't learn much from reinventing a wheel. Reinventing the spaceship, however, is not as wrong. I like programming in straight diagrammatical lines. Everything either contains other things, or is wheel. A program is a simple set of complex elements. Each complex element is a simple set of tools. Each tool is a simple set of wheels. That's how I see it, and that's how I program. Those complex elements are not seamlessly integrated into my program because they force complexity on their bounding set. My solution is to rewrap them, as I mentioned, by something that works better with my way of thinking. In my spaceship I hide the electrical circuits under a nice, big, round button. This helps me create stable code, because everything is delegated downwards, broken down to it's simple parts. The button has one way of working on the outside, and on the inside it connects to the right things.
I have another problem. I like the button to be a button, and to be round. I don't like having to pretend a lever is a button. And usually there isn't a button just the way I like, because the button is not just for me. It's for hundreds others like me, some of which like levers, and some of which like a star trek female voice thing, or whatever.
Perlwise, what i mean is that these modules are either too bloated, or minimalistic in the wrong way for me. And I don't blame them. You can't make something of this sort simple, because it's not a simple thing. There has to be a choice of what to give access to, and where to stop. What the objects, if any, are responsible for handling and what they are. You cannot live up to everyone's expectations in such a complex model, because simplicity here is not minimalism, but simple mindedness.
A hypothetical solution for this is to distribute wheels, and let the people back at home roll their own spaceships. That's a nice solution, but usually seems a bit unfair to the people back at home. Why are they getting half of something when they could be getting something whole?
At the bottom line, big things scare me. Simple things project a laziness, unless they're supposed to be simple. I end up doing the big things on my own, so that I can use them properly, and feel comfortable about it. I save time in the long run, and learn more on the way. To me this concept is like building a toolbox of my own, for use on a project. The tools are mine, and rely only on bits from other people. This is (what I haven't|not what i have) learned from perl and cpan.
Perhaps it's because I'm quite harshly dyslexic, and can't easily understand the documentation completely. But if not, I post this up for discussion, so that others who may have felt the same may comment, and help me in making a wiser decision.
Update: I'd like to apologize for my replies to everything. It seems childish from my point of view, and my reaction is - I am uncomfortable feeling that i've caused confusion regarding what I think. For some reason it seems to me as though I pushed the debate far away from what I intended it to discuss, and thus have a last-word reaction to everything. I'm sorry.
zz zZ Z Z #!perl