[plt-scheme] Re: Programming for non-programmers

At one time, I have the same feeling with you. People around me doesn't 
know lisp/scheme and I try to do the samething as you. www.paulgraham.com 
have some discussion about this (the bubble paradox). 


Zhu Chongkai
>
>Your comments match what I personally have experienced; that is why I 
>am an advocate.  Everything that I have written in the past year has 
>either been in scheme or in Mz embedded in C programs.  But after 
>seeing a few informal presentations, our Masses-of-Eight remain in 
>their comfortable beds of C++ (in our workplace, no one is forced to 
>use anything in particular).  They are always able to convince 
>themselves that debuggers and guis are as effective for development as, 
>in your words, 'scripts to drive the C++ program'.
>
>I want to present a few killer ideas that will get them to seriously 
>consider scheme.  Procedural programmers (like me), have to experience 
>functional programming to become enlightened.  My motivation came from 
>necessity; I was drowning in C.  But what if programmers don't feel 
>that they are limited?
>
>rac
>
>
>
>
>On Oct 13, 2004, at 11:16 PM, Chris Uzdavinis wrote:
>
>> Richard Cleis <rcleis at mac.com> writes:
>>
>>> What about 'Programming for experienced programmers?'  I work with
>>> eight other programmers (in a science laboratory); none of them have
>>> any experience with any lightweight languages or functional
>>> languages (all have computer-science or computer-engineering
>>> degrees).  I have only been able to convince two people the value of
>>> scheme or python or anything 'out of the box', but all remain
>>> entrenched in C++.
>>
>> We're pretty heavy in C++, but what's appealing about scheme, at least
>> enough to get us (me) initially looking at it, was not all the cool
>> features like continuations.  What I liked was (please no rotten
>> tomatos) the ability to use it as a configuration language, like emacs
>> uses its version of lisp.
>>
>> We like the idea of being able to have config files, command line
>> options, and the "back door" into our programs to tweak them at
>> runtime (what we call "guru mode") all processed by the same exact
>> interpreter.  Traditionally we had a command line parser, config file
>> parser, and "guru mode" parser that essentially all set the same
>> variables.  Now we make hooks so that the C++ variables can be changed
>> by the scripting language, and we can write scripts to drive the C++
>> program.
>>
>> Suddenly a whole world of new dynamic behavior is opened up to your
>> program.  You can inject new behavior by adding a scheme function into
>> your program's environment, for example, and have it take immediate
>> effect.  (Just be sure it doesn't have errors... as this is obviously
>> risky.)
>>
>> Anyway, my point is the foot-in-the-door for us to scripting was to
>> embed the interpreter in our C++ applications, hook it up to most of
>> the important variables, and use it for simple controls.  From there,
>> it's surprising how many opportunities appeared where a script was a
>> better solution.
>>
>> Another benefit was developing and running unit and regression tests.
>> They drive our C++ application and are another area where the dynamic
>> language was invaluable.  Writing tests in C++ is cumbersome and has
>> extremely slow compile/link cycles.
>>
>> Dynamic languages require virtually no compile time which makes them
>> incalculably more valueable for testing compiled applications.
>>
>> Just some ideas.
>>
>> -- 
>> Chris
>>
>
>