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

> What is the best way for someone to learn to master the GUI aspects of 
> PLT-Scheme?
> 
> Obviously example code is helpful, and the 'cookbook' stuff is great.  
> But there seems to be a big gap between the excellent technical 
> documentation and the kind of incremental tutorial that engenders 
> understanding and mastery.
> 

The simplest answer (which I saw given) is to "just do it." At the 
worst, you can end up with something that looks like Java-in-Scheme. You 
have classes for everything in the GUI, and... well, that's nothing new.

However, PLT Scheme also provides you with a few other paradigms; you 
have the functional, concurrent, and lazy (if you poke a bit), as well 
as the functional reactive stuff in FrTime. Being specific about just 
one of those, you can look at papers like

EX11 – A GUI in a Concurrent Functional Language
http://www.erlang.se/workshop/2004/ex11.pdf (Slides)
http://portal.acm.org/citation.cfm?id=1022472 (ACM DL Citation)

and, by-and-large, probably map that into Scheme. You might need to use 
the ConcurrentML channel library to get asynchronous communications, and 
even then you'll have to make sure that the channel model in the library 
maps correctly to Erlang channels, but my point is that the PLT Scheme 
implementation is rich enough that you can explore things like 
concurrent GUI design if you want to. (This was something I poked at 
briefly, but I discovered that rewriting a small application from the 
sequential to concurrent style in under an hour is a surefire way to 
discover things like, oh, "deadlock." :)

It's almost a "problem", in a way: the PLT Scheme distribution gives you 
some powerful tools for architecting software (macros, units/mixins, 
first-class continuations, a well-behaved module system), and you have 
to figure out how to best make use of it. And, even if you don't make 
use of any of these features, you still have a clean, expressive 
language to work with. Either way, you get brought back to the point 
that Neil and Mathias made, which is that you have a systems 
architecture problem, regardless of what tools you decide to use to 
tackle it.


Good luck,
Matt