TITLE: Scripting, CS1, and Language Theory
AUTHOR: Eugene Wallingford
DATE: July 30, 2008 12:40 PM
DESC: 
-----
BODY:
Yesterday, I wrote
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-07.html#e2008-07-29T14_03_19.htm">
   a bit about scripting languages</A>.
It seems odd to have to talk about the value of
scripting languages in 2008, as Ronald Loui does in
<A HREF="http://doi.ieeecomputersociety.org/10.1109/MC.2008.228">
   his recent <EM>IEEE Computer</EM> article</A>,
but despite their omnipresence in industry, the academic
world largely continues to prefer traditional systems
languages.  Some of us would like to see this change.
First, let's consider the case of novice programmers.

Most scripting languages lack some of the features
of systems languages that are considered important
for learners, such as static typing.  Yet these
"safer" languages also get in the way of learning,
as Loui writes, by imposing "enterprise-sized
correctness" on the beginner.

<BLOCKQUOTE><EM>
Early programmers must learn to be creative and
inventive, and they need programming tools that
support exploration rather than production.
</EM></BLOCKQUOTE>

This kind of claim has been made for years by
advocates of languages such as Scheme for CS1, but
those languages were always dismissed by "practical"
academics as toy languages or niche languages.  Those
people can't dismiss scripting languages so easily.
You can call Python and Perl toy languages, but they
are used widely in industry for significant tasks.
The new ploy of these skeptics is to speak of the
"scripting language <EM>du jour</EM>" and to dismiss
them as fads that will disappear while real languages
(read: C) remain.

What scripting language would be the best vehicle for
CS1?  Python
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-03.html#e2006-03-05T10_06_47.htm">
   has had the buzz</A>
in the CS ed community for a while.  After having
taught
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-05.html#e2008-05-01T19_11_09.htm">
   a little PHP</A>
las semester, I would deem it too haphazard for CS1.
Sure, students should be able to do powerful things,
but the pocket-protected academic in me prefers a
language that at least pretends to embody good
design principles, and the pragmatist in me prefers
a language that offers a smoother transition into
languages beyond scripting.  JavaScript is an idea
I've seen proposed more frequently of late, and it
is a choice with some surprising positives.  I don't
have enough experience with it to say much, but I
am a little concerned about the model that programming
in a browser creates for beginning students.

Python and Ruby do seem like the best choices among
the scripting languages with the widest and deepest
reach.  As Loui notes, few people dislike either, and
most people respect both, to some level.  Both have
been designed carefully enough to be learned by
beginners and and support a reasonable transition as
students move to the next level of the curriculum.
Having used both, I prefer Ruby, not only for its
OO-ness but also for how free I feel when coding in
it.  But I certainly respect the attraction many people
have to Python, especially for its better developed
graphics support.

Some faculty ask whether scripting languages scale to
enterprise-level software.  My first reaction is:  For
teaching CS1, why should we care?  Really?  Students
don't write enterprise-level software in CS1; they learn
to program.  Enabling creativity and supporting exploration
are more important than the speed of the interpreter.
If students are motivated, they will write code -- a
lot of it.
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-07.html#e2004-07-12T18_58_55.htm">
   Practice</A>
makes perfect, not optimized loop unrolling and type
hygiene.

My second reaction is that these languages scale quite
nicely to real problems in industry.  That is why they
have been adopted so widely.  If you need to process a
large web access log, you <EM>really</EM> don't want to
use Java, C, or Ada.  You want Perl, Python, or Ruby.
This level of scale gives us access to real problems
in CS1, and for these tasks scripting languages do more
than well enough.  Add to that their simplicity and the
ability to do a lot with a little code, and student
learning is enhanced.

Loui writes, "Indeed, scripting languages are not the
answer for long-lasting, CPU-intensive nested loops."
But then, Java and C++ and Ada aren't the answer for all
the code we write, either.  Many of the daily tasks that
programmers perform lie in the space better covered by
scripting languages.  After learning a simpler language
that is useful for these daily tasks, students can move
on to larger-scale problems and learn the role of a
larger-scale language in solving them.  That seems more
natural to me than going in the other direction.

Now let's consider the case of academic programming
languages research.  A lot of interesting work is being
done in industry on the design and implementation of
scripting language, but Loui laments that academic
PL research still focus on syntactic and semantic
issues of more traditional languages.

Actually, I see a lot of academic work on DSLs --
domain-specific languages -- that is of value.  One
problem is this research is so theoretical that it is
beyond the interest of programmers in the trenches.
Then again, it's beyond the mathematical ability and
interest of many CS academics, too.  (I recently had
to comfort a tech entrepreneur friend of mine who was
distraught that he couldn't understand even the titles
of some PL theory papers on the resume of a programmer
he was thinking of hiring.  I told him that the lambda
calculus does that to people!)

Loui suggest that PL language research might profitably
move in a direction taken by linguistics and consider
pragmatics rather than syntax and semantics.  Instead
of proving something more about type systems, perhaps
a languages researcher might consider "the disruptive
influence that Ruby on Rails might have on web programming".
Studying how well "convention over configuration" works
in practice might be of as much use as incrementally
extending a compiler optimization technique.  The effect
of pragmatics research would further blur the line
between programming languages and software engineering,
a line we have seen crossed by some academics from the
PLT Scheme community.  This has turned out to be practical
for PL academics who are interested in tools that support
the programming process.

Loui's discussion of programming pragmatics reminds me
of my time in studying knowledge-based systems.  Our work
was pragmatic, in the sense that we sought to model the
algorithms and data organization that expert problem
solvers used, which we found to be tailored to specific
problem types.  Other researchers working on such
task-specific architectures arrived at models consistent
with ours.  One particular group went beyond modeling
cognitive structures to the sociology of problem solving,
John McDermott's lab at Carnegie Mellon.  I was
impressed by McDermott's focus on understanding problem
solvers in an almost anthropological way, but at the
time I was hopelessly in love with the algorithm and
language side of things to incorporate this kind of
observation into my own work.  Now, I recognize it as
the pragmatics side of knowledge-based systems.

(McDermott was well known in the expert systems community
for his work on the pioneering programs R1 and XCON.
I googled him to find out what he was up to these days
but didn't find much, but through some
<A HREF="http://portal.acm.org/citation.cfm?id=1351185.1351261">
   publications</A>,
I infer that he must now be with the
<A HREF="http://chacs.nrl.navy.mil/">
   Center for High Assurance Computer Systems</A>
at the Naval Research Laboratory.  I guess that accounts
for the sparse web presence.)

Reading Loui's article was an enjoyable repast, though
even he admits that much of the piece reflects old
arguments from proponents of dynamic languages.  It did
have, I think, at least one fact off track.  He asserts
that Java displaced Scheme as the primary language used
in CS1.  If that is true, it is so only for a slender
subset of more elite schools, or perhaps that Scheme
made inroads during a brief interregnum between Java
and ... Pascal, a traditional procedural language that
was small and simple enough to mostly stay out of the
way of programmers and learners.

As with so many current papers, one of the best results
of reading it is a reminder of a piece of classic
literature, in this case
<A HREF="http://home.pacbell.net/ouster/scripting.html">
   Ousterhout's 1998 essay</A>.
I usually read this paper again each time I teach programming
languages, and with my next offering of that course to
begin in three weeks, the timing is perfect to read it
again.
-----