[Prev][Next][Index][Thread]
Design methodology in an OODL environment
I'm still in the very early learning stages with Dylan, but I thought
I'd share some of the issues I've been thinking about. I've chosen a
fairly ambitious learning project. I'm going to write a mostly
text-oriented D&D style adventure game, using a DUIM GUI.
My programming experience over the last few years has been mostly in
Visual Basic. Even though you *can* write OOP with VB (but like most
things in VB, it comes out looking like a hack), I would say that
probably most of my code would be considered procedural. (Though I've
written dlls in VC++, I never really managed to wrap (warp?) my mind
around the C++ OOP model. After spending the last few years thinking
this was a deficiency on my part, it's now beginning to look like a
distinct advantage. I love that programming in Dylan is OOP all the
way, sort of like learning French by being dropped naked in the middle
of Paris :) ). My experience with VB was that if you didn't design
your program VERY well from the start, the project would either
collapse under its own weight or reach unmaintainable status in just a
few hundreds of lines.
In the late eighties I did a lot of game programming in strictly C,
where the same observations seemed to hold true. Consequently, If I'm
working on something serious that I really want to get done, I tend to
overdesign. What I'm wondering now is, where's the balance with
Dylan? What I'm imagining (hoping, in fact) that developing with
Dylan will allow (encourage even) is a kind of jump right in the
middle and code your way out approach, an iterative, spiralling
development cycle, expanding and improving along the way without
running into major roadblocks (beyond simple ignorance, which is easy
to remedy). I've tried this approach in VB (& C) a few times, and the
results weren't pretty. :)
Can Dylan work this way, or am I being naive and asking for trouble?
Follow-Ups: