[plt-scheme] Help writing non-trivial applications.

From: Neil W. Van Dyke (neil at neilvandyke.org)
Date: Tue May 3 20:28:52 EDT 2005

David Richards <dirichards at cox.net> wrote at 2005-05-03T19:50:52-0400:
> Is PLT-Scheme source code to a complex application(s) available, such 
> as a usable web browser, word processor, etc?

I'd say the implementation complexity of DrScheme fits into that
category, and the source is available.  In implementing DrScheme,
they've had to design architectural elements like MrEd's eventspaces and
make them work.  There's at least one early paper, which you can find on
readscheme.org.

If you want to develop your own software of the size and complexity of
DrScheme and greater, I think you will bumping into my old pet area of
systems architecture, which is not specific to Scheme at all.  Some
opinion-heavy suggestions in case you want to learn architecture in
general...

Beyond looking at sample applications, briefly acquainting yourself with
the popular design patterns, and sifting through the writings of
methodologists... architecture of large and complex applications is
something hard that very few people know how to do well.  A large part
of it can be learned only by doing, and doing is very expensive when
we're talking about large and complex applications.

I'd suggest a series of numerous design and construction exercises that
are OK to abandon as you get a better feel for workable design and
methodology, with a side benefit of honing your "tactical" skills.  Once
you get better at this, you can build on that by *not* abandoning a
project, which will teach you a lot more.  As much as possible, do this
by yourself rather than in teams.  Teams introduce a raft of things of
things to learn on top of what you can learn about architecture
yourself.

Some of the methodologists have done some good work, but be aware of a
couple things: (1) they don't necessarily have the same cognitive
strengths and weaknesses that you do (UML made some grievous errors that
any strong-visual person would've caught in an instant); (2) they aren't
necessarily interested or experienced in the same kinds of design
problems and development processes that you are.



Posted on the users mailing list.