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

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
>