too complicated is not the issue

[thi <ttn@mingle.glug.org>]

Clayton Weaver writes:

 > The difficulty is not functional programming, it is lack of visual
 > cues for variable binding scope and control flow.

cues in the code?  like indentation?
or cues in the execution?  like memory-usage or stack visualization?
or cues in the design phase?  like so-called wizards?

 > How scheme compares to other existing languages is not the issue.
 > The differences between functional, imperative, and object-oriented
 > programming where they exist are not the primary obstacle to
 > deployment of scheme.
 >
 > Let's use a different analogy and see if the point becomes clear:
 > 
 > It's ten years ago, and you're flying around in this Huey (huge
 > helicopter), getting big jobs done (using common lisp). You decide
 > that having something that worked more or less the same way
 > but was much smaller and more nimble would certainly be handy
 > for some of the work that you need to do.
 > 
 > So you design this small, fast, nimble helicopter, and you call it
 > scheme. How likely is it that this new helicopter is going to become
 > a useful daily commuter vehicle?
 > 
 > "Well, we weren't design a 4-seater subcompact." Exactly.

why commute?  computer usage is migrating towards everything being a
server (X, hurd, gush, gamora, etc).  one just needs a net to throw into
the bit stream.  something like: "hey AI, simulate yourself doing..."

thi