scsh-users
[Top] [All Lists]

Re: Ousterhout article on scripting applies to scheme

To: scsh@martigny.ai.mit.edu
Subject: Re: Ousterhout article on scripting applies to scheme
From: "Michael D. Kersey" <mdkersey@hal-pc.org>
Date: Thu, 27 Mar 1997 19:59:04 -0500
Organization: Houston Area League of PC Users
Reply-to: mdkersey@hal-pc.org
Richard Coleman wrote:

> 

> I just read a new white paper written by John Ousterhout

> about scripting languages, called

> 

> Scripting: Higher-Level Programming for the 21st Century

> (available at http://www.sunlabs.com/people/john.ousterhout)

> 

< snipped > 


I don't think that there is anything really new in this paper, although
it is good to revisit what was said in it. Everything that Osterhout
says about scripting languages vs systems languages was said years ago
in another context: 4GL's vs 3GL. Further, if we assume this is the same
argument, plenty of statistics exist to support the productivity
advantages of 4GL's(scripting languages) over 3GL's(system programming
languages) in application development. 



IMHO Lisp and Scheme are properly tagged as "5GL's"; you have a (true)
sense of power with these languages. But indeed they could use some of
the interfaces of the younger scripting languages(or 4GL's) that you
list,  especially with regard to databases and the common GUI's.



A detail: I still don't consider VB either a 4GL or a scripting language
as Osterhout describes for several reasons. For example, despite the
fact that you can use typeless "variant" variables in VB, it is almost
never

done in practice. Au contraire, most of the VB lore and literature
recommends avoiding the variant data type because of the ensuing
problems (either with the programmers' understanding of what's happening
or with VB's unique approach to use of that data type). 

Instead I would put VB in a class by itself, a KGL (kludged generation
language). It's development parallels Microsoft's BORG development
methodology in the small: incorporate every possible feature into a
product until either a) you simply can't support the product any more
due to it's complexity and internal inconsistencies, or b) the users
can't use the product anymore for the same reason.

Michael D. Kersey

<Prev in Thread] Current Thread [Next in Thread>