[REBOL] Re: Hitting the learning curve
From: greggirwin:mindspring at: 5-Nov-2003 23:49
Hi Ged,
GB> I've stopped saying 'Wow,' and I'm starting to ask 'How.'
What a great question!
GB> The problem is that, given a blank piece of screen,
GB> where do I begin when devising my own code to solve my
GB> own problems. What is the starting point.
GB> Different languages have their own starting points.
Yes, and most *give* you a starting point. They also give you a
definite "way" to think about solving your problem. Some have you
think about code or the UI, others about structure or "the model"
(UML et al).
GB> What is the starting point with Rebol? Given a
GB> problem and an empty .r file how do I start growing my
GB> problem? With a form to enter the data? With a set
GB> of objects? With a set of functions? By defining a
GB> dialect?
GB> There seem to be so many approaches, but no single
GB> method affords itself?
That's true! It's one of the things I really like about REBOL, but I
can see where you're coming from.
When I started with REBOL, I was attracted to the GUI side of
things--having specialized in VB for 11 years--and it took me a while
to let go of that, probably still haven't completely. :)
The reason I think this problem is a good one to have, is because
with other tools you might map your problem to their domain without
thinking about whether that's the best thing to do. With REBOL, I
think there is less bias for any particular method, so you look at
your problem and run through the various options in your
head about how you might solve it. If your problem involves a user
entering data, a GUI might be the right thing. If it involves
listening for TCP connections or automatically processing files,
probably not. I'd hazard a guess that we all create a system of
patterns we start to recognize over time, and we may even have
skeleton projects for them; on disk or in our heads.
As a general rule, when I start a new project, I create a directory
for it and create a notes.txt file. That's where I collect my thoughts
and ideas. It's also where I jot down pseudo-code or structures as I
think through the problem I'm solving. Writing down the steps you need
to take to solve the problem is a really good place to start. What
happens, with REBOL more than many other languages for me, is that
your solution will end up looking like how you naturally expressed it
in pseudo-code. With REBOL, one of the really important things is the
set of words you end up defining and how they work together.
If I'm writing a module or set of functions that are to be used as a
small library, I start with an object to put them in their own
namespace. That's an easy pattern to spot.
If I'm writing things that are going to use Windows API calls, I
usually start by getting all the routine! bits working, using test
calls, and then decide if I should just use wrapper functions or build
a dialect around them in some cases.
For small data entry apps, I have a boilerplate system and some other
toys to get simple things up for testing. If I have multiple views, or
other stuff going on in the UI, I'll usually sketch out a quick FSM
using my FSM dialect to help me visualize things a bit.
Sometimes I start with data. I'll manually create the data, or write
a data generator to do it, then I can play with how it's going to
work, see if I can read and write the data in formatted how I want, if
it's easy and extensible, etc.
Folks who do a lot of CGI probably have a definite starting point for
how they do it, and even skeleton scripts to get things rolling.
HTH!
-- Gregg
