Re: dual-language systems increase modularity

[Matthias Felleisen <address@hidden>]

On Sunday, November 16, 2003, at 10:32 AM, sundar@ascent.com wrote:

> Hi, Shriram: Agreed w/ what you have to say about glue vs. 
> "strong-type"
> scripting (i.e. where both caller/callee have intimate knowledge of 
> types
> on either side).
>
>> Shriram said at the workshop that his big question was, how do you go
>> "from scripts to programs"?
> Could you say more about what you meant here?

Let me supplement this phrase just like I did at the workshop.

Scripting ("extensive" as defined by SK) is easy, it is fun, and you can
bake yourself some full-fledged application in no time. If you're not an
Arpa contractor and throw away your code at the end of a funding cycle,
you will need to hand over some of this "scripting" code to other 
programmers.
Perhaps you're moving on to a new project but someone needs to maintain 
it.
Perhaps you'll come back to this code in a year from now; it's running 
fine now.

Whatever the reason, you will note that the very things that make 
scripting
languages easy to use also makes them a difficult obstacle when scripts 
or
programs reach a certain size.  For example, there are no type 
annotations
in your sub-s so how do you know what kind of values will show up at 
some
parameter? You make a guess and perhaps it's right, perhaps it's wrong. 
You
want to add a function for processing all valid "moves" in your "game". 
Well,
since there is algebraic data type that describes this set, you make 
your best
guess and pray.

I claim that you probably want to adopt two strategies for getting from 
"fun-to-write
scripts" to "maintainable programs." (1) As soon as you realize that 
your script is
about to become the basis for your business, you want to adopt a program
design philosophy. (E.g., I have seen several neat Perl programs over 
the past
couple of years that used the HtDP design recipe. The students knew 
that I'd ask
them to maintain their code over 14 weeks and they had enough 
experience with
Perl to know that it wouldn't work otherwise.)

(2) You want tools that help you infer and maintain "invariants" or 
"structural
relationships" among pieces of code.  This is where the entire LL 
community
falls short and just fails to see why we can't grow. We (PLT) has some 
experience
with that. We have had two Hindley-Milner soft typers (incl. Andrew's 
Soft Scheme)
and two SBA soft typers (incl MrSpidey). These tools are by no means 
perfect and
don't do enough.  But they are examples of what I mean when I say we 
need to be
able to write some thoughts down and have them checked when we modify 
scripts
that have grown too complex for our sake.  If we (LL) were to invest in 
any joint
infrastructure, then it is exactly that aspect that we should tackle.

-- Matthias