[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dual-language systems increase modularity
On Sunday, November 16, 2003, at 10:32 AM, email@example.com wrote:
> Hi, Shriram: Agreed w/ what you have to say about glue vs.
> scripting (i.e. where both caller/callee have intimate knowledge of
> 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
Perhaps you're moving on to a new project but someone needs to maintain
Perhaps you'll come back to this code in a year from now; it's running
Whatever the reason, you will note that the very things that make
languages easy to use also makes them a difficult obstacle when scripts
programs reach a certain size. For example, there are no type
in your sub-s so how do you know what kind of values will show up at
parameter? You make a guess and perhaps it's right, perhaps it's wrong.
want to add a function for processing all valid "moves" in your "game".
since there is algebraic data type that describes this set, you make
guess and pray.
I claim that you probably want to adopt two strategies for getting from
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
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
Perl to know that it wouldn't work otherwise.)
(2) You want tools that help you infer and maintain "invariants" or
relationships" among pieces of code. This is where the entire LL
falls short and just fails to see why we can't grow. We (PLT) has some
with that. We have had two Hindley-Milner soft typers (incl. Andrew's
and two SBA soft typers (incl MrSpidey). These tools are by no means
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
that have grown too complex for our sake. If we (LL) were to invest in
infrastructure, then it is exactly that aspect that we should tackle.