Re: [Q] HOWTO redirect a i/o-port in Unix??

[Matthias Felleisen <matthias@cs.rice.edu>]

Leo, in principle, you're probably correct that unix/linux people are more
willing to experiment with things than windows/mac people. BUT, mzscheme is
also a platform for research. 

Our own goal requires a fully portable Scheme that runs on all
platforms. It is most commonly used under DrScheme -- and believe it or
not, it has its own OS there. Matthew's dominant research interest is to
extend the OS research direction. Others on the team use it as a platform
for Programming Environment work or generative programming (that could be
useful to you in creating your C++ code, which should really be in
Fortran!). My interests cover all of this *and* making dr/mz useful in a
general industrial sense.

Whatever is in demand, fits within the Scheme world, and doesn't contradict
our platform will come from us, if we have the time/money/machines to do
so. 

Whatever is a special-purpose need should probably be built as an
extension. We are willing to help with this, and even accommodate where
possible. For example, I could see a bunch of Unix/Linux users agree on a
plan to add a library of Unix/Linux specific i/o stuff. They could set up
interfaces and split the work. Ideally, the library should go back to our 
contributions site. 

;; --- 

Maintainability: I strongly agree with you on maintaining code as it grows,
except that I have to say raw Scheme has probably similar problems to Perl.
Yes, Scheme is more uniform and more powerful. But it lacks a type and
signature system that can throw off outside maintainers. What we (PLT) have
developed is a discipline that fixes this. (We also have Spidey, and I
would love to see how the concept holds up in a world like yours.)

I train my undergraduate students in precisely that: maintaining a quickly
growing piece of code over a semester. Those who stick to the discipline I 
teach in the first course do great. Those who don't sink. (They can "buy" 
solutions from me, for 10% final grade down.)

I suggest you take a look at HtDP and its typing, documentation, and test
suite teaching. It may prevent you from ever retracting your claims "-). 
You may also wish to poke around in something like the net library, which
has some documentation similar to that advocated in HtDP. 

In a nutshell, we write each function with 

 1. a data analysis/data defs, if necessary
 2. a type signature, purpose statement
 3. a function definition (examples, template, body)
 4. a test suite developed from examples that we made up *before*
    we write the function 

I always keep the test cases for simple programs in block comments at the
end of the file. For larger portions of our code, we have separate test
suites (mzscheme, guis, ...) that apply to the entire program, rather than
just one function. I think this discipline is a key to bug-prevention
programming and maintainability. Make a change, adapt the tests, test the
function. 

You may know all of this, in which case, just take it as my urge to
teach. If not I am hoping it helps. 

-- Matthias