Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

Matts
  (email not shown publicly)

I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Thursday April 13, 2006
12:22 PM

drh++

[ #29315 ]

D. Richard Hipp is a personal hero of mine. He needed a small lightweight database and couldn't find one he liked so he wrote his own. Today on the sqlite mailing list he posted this gem:

"Aaron Jones" wrote:
> Hi, sorry to bother you, but I was wondering if you could tell me if you
> designed SQlite using a Structured or Object-Oriented methodology please as
> I am designing an interface to SQLite and my supervisor said if I knew what
> methodology was used for designing SQLite this would be a good justification
> for my choosing a methodology for designing the interface.

I have spent 20 minutes trying to think of a reasonable
answer to your question and have come up with nothing.
The best answer I have is this: Your question is based on
multiple false premises and thus has no answer.

You assume that SQLite was designed using either a
structure or an object-oriented procedure. (Methodology
is a trendy word to use in that context, but when it is
it is misused. "Design method" or "design procedure" is
correct. "Design methodology" means the study of various
design methods - not the design method itself.) This is
false. I do not design use rigidly defined design methods
found in books. Book-defined design methods generally
lead to bloated designs that rarely work.

You assume that the design method used to build a component
has some bearing on the design method used to build a
user interface to that component. This is false. Either
your instructor is wrong or your are misquoting him.

You should design your interface using whatever design
method you are most comfortable with. Or (better) just
design your interface using creativity and good sense
and don't worry so much about rigidly defined design
methods.

And there was an excellent follow up:

> You should design your interface using whatever design method
> you are most comfortable with. Or (better) just design your
> interface using creativity and good sense and don't worry so
> much about rigidly defined design methods.

I had a little chuckle at this. I was reminded of the old PBS painting
shows on TV that I used to watch. The artist would make "happy little
trees" and flit about the canvas. His little dabs and whips of the
paintbrush would transform into a wooded glade, a rushing river, mountains
with the sun dancing off the edges ...

Of course, when I tried to do the same thing, it turned out like brown
blobs. When your hand automatically knows how to turn, and the brushes are
so familiar you know which one you have just by the feel of it, then you can
paint with the freedom seen on the TV shows. Until then, you'll just make
brown blobs.

It's the same with programming and programming languages, really. All the
books you read and courses you take in college are just there to help you
get familiar with the brushes and the canvas. They'll help keep you from
making brown blobs, but you'll never make a masterpiece by the book.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.