Re: languages (was: Re: ``Shut-up and Hack!")

[Jonathan S. Shapiro]

On Sun, 2006-08-13 at 18:12 +0200, address@hidden wrote:
> Hi,
> 
> On Sat, Aug 12, 2006 at 06:53:26PM -0400, Luis Araujo wrote:
> 
> > As a sidenote, briefly referring to John Ousterhout , when he talks
> > about scripting programming:
> > 
> > "They give up execution speed and strength of typing relative to
> > system programming languages but provide significantly higher
> > programmer productivity and software reuse."
> 
> I don't buy the productivity arguement in general. Sure, this is very
> important in areas where you have to come up with code as fast as
> possible, like prototyping and scripts. And in these areas, higher-level
> languages are very popular indeed.

Ousterhout's talk is now a long time ago, and it is interesting to look
at how the landscape has changed since then. Consider:

There are (at least) two classes of "scripting" languages:

  1. The ones where declaring types is optional or impossible
     (e.g. lua)
  2. The ones where even fields and variables are declared implicitly
     (e.g. python)

And then, in Ousterhout's comparison, there are statically typed
languages like C. Osterhout's objections to C are largely incorrect. On
the one hand, C does *not* provide strong typing. On the other,
Ousterhout seems to miss the elements of "convenience" and
"abstraction" (which is essential for reuse), both of which are very
important to the success of scripting languages.

So now here is an interesting thing: if you are willing to declare
structure field types, truly modern languages can infer essentially
everything else, and provide very high levels of abstraction. So, for
example, programming in Standard ML or Haskell gives you much stronger
static typing than C but nearly all of the convenience of scripting
languages -- the missing bit there is a decent plugin and extension
mechanism, and people have been working on that.

I was never convinced by Ousterhout's argument -- at the time I was
working in the language tools group at AT&T Bell Laboratories, and our
observation was that no program *ever* ends up staying 10-20 lines over
its lifetime, and if you don't plain to maintain from the start you are
doomed. But even if you *do* accept his argument, it's worthwhile to
notice that the programming landscape has changed, and the argument may
no longer be true today.


shap