TITLE: Keeping Up Versus Settling Down
AUTHOR: Eugene Wallingford
DATE: April 13, 2009  7:36 PM
DESC: 
-----
BODY:
The last few days I have run across several pointers
to
<A HREF="http://www.scala-lang.org/">
   Scala</A>
and
<A HREF="http://clojure.org/">
   Clojure</A>,
two dynamic languages that support functional
programming style on the JVM.  Whenever I run into
a new programming language, I start thinking about
how much time I should put into learning and using
it.  If it is a functional language, I think a bit
harder, and naturally wonder whether I should
consider migrating my Programming Languages course
from the venerable but now 30-plus-years-old Scheme
to the new language.

My time is finite and in scarce supply, so I have
to choose wisely.  If I try to chase every language
thread that pops up everywhere, I'll end up
completely lost and making no progress on anything
important.  Choosing which threads to follow
requires good professional judgment and, frankly,
a lot of luck.  In the worst case, I'd like to
learn something new for the time I invest.

Scala and Clojure have been on my radar for a
while and, like books that receive multiple
recommendations, are nearing critical mass for
a deeper look.  With summer around the corner
and my usual itch to learn something new, chances
go up even more.

Could one of these languages, or another, ever
displace Scheme from my course?  That's yet
another major issue.  A few years ago I entertained
the notion of using Haskell in lieu of Scheme for
a short while, but Scheme's simplicity and dynamic
typing won out.  Our students need to see something
as different as possible from what they are used
to, whatever burden that places on me and the
course.  My own experience with Lisp and Scheme
surely had some effect on my decision.  For every
beautiful idea I could demonstrate in Haskell, I
knew of a similar idea or three in Scheme.

My circumstance reminds me of a comment by
<A HREF="http://patricklam.ca/">
   Patrick Lam</A>
to a
<A HREF="http://learningcurves.blogspot.com/2009/04/current-distraction-from-making.html">
   blog entry at Learning Curves</A>:

<BLOCKQUOTE><EM>
I've noticed that computer science faculty
technology usage often seems to be frozen to
when they start their first tenure-track job.
Unclear yet if I'll get stuck to 2008 technology.
</EM></BLOCKQUOTE>

Lam is wise to think consciously of this now.  I
know I did not.  Then again, I think my track
record learning new technologies, languages, and
tools through the 1990s, in my first decade as a
tenure-track professor, holds up pretty well.  I
picked up several new programming languages,
played with wikis, adopted and used various tools
from the agile community, taught courses in several
new courses that required more than passing
familiarity with the tools of those subdisciplines,
and did a lot of work in the software patterns
world.

My pace learning new technologies may have slowed
a bit in the 2000s, but I've continued to learn
new things.  Haskell, Ruby, Subversion, blogs,
RSS, Twitter, ...  All of have become part of my
research, teaching, or daily practice in the last
decade.  And not just as curiosities next to my
real languages and tools; Ruby has become one of
my favorite programming languages, alongside
old-timers Smalltalk and Scheme.

<P ALIGN="right">
<TABLE BORDER="0" CELLPADDING="15">
<TR> <TD ALIGN="right">
         <EM>A language that doesn't affect<BR/>
         the way you think about programming,<BR/>
         is not worth knowing.<BR/><BR/>
         -- <A HREF="http://en.wikipedia.org/wiki/Alan_Perlis">
               Alan Perlis</A>,<BR/>
            <A HREF="http://www.cs.yale.edu/homes/perlis-alan/quotes.html">
               <STRONG>Epigrams on Programming</STRONG></A></EM>
     </TD>
     <TD ALIGN="center">
         <IMG SRC="http://www.cs.uni.edu/~wallingf/blog-images/people/alan-perlis.jpg"
              ALT="Alan Perlis"
              WIDTH="100"
              ALIGN="center">
     </TD>
</TR>
</TABLE>
</P>

At some point, though, there is something of a
"not again..." feeling that accompanies the
appearance of new tools on the scene.  CVS
led to Subversion, which led to ... Darcs,
Mercurial, Git, and more.  Which new tool is
most worth the effort and time?  I've always had
a fondness for classics, for ideas that will
last, so learning yet another tool of the same
kind looks increasingly less exciting as time
passes.  Alan Perlis was right.  We need to
spend our time and energy learning things that
matter.

This approach carries one small risk for
university professors, though.  Sticking with
the classics can leave one's course materials,
examples, and assignments looking stale and
out of touch.  Any CS 1 students care to write
a Fahrenheit-to-Celsius converter?

In the 1990s, when I was learning a lot of new
stuff in my first few years on the faculty, I
managed to publish a few papers and stay active.
However, I am not a "research professor" at a
"research school", which is Lam's situation.
Hence the rest of his comment:

<BLOCKQUOTE><EM>
Also unclear if getting stuck is actually
necessary for being successful faculty.
</EM></BLOCKQUOTE>

As silly as this may sound, it is a legitimate
question.  If you spend all of your time chasing
the next technology, especially for teaching
your courses, then you won't have time to do
your research, publish papers, and get grants.
You have to strike a careful balance.  There is
more to this question than simply the availability
of time; there is also a matter of mindset:

<BLOCKQUOTE><EM>
Getting to the bottom of things -- questioning
assumptions, investigating causes, making
connections -- requires a different state of
mind than staying on top of things.
</EM></BLOCKQUOTE>

This comes from John Cook's
<A HREF="http://www.johndcook.com/blog/2008/07/15/getting-to-the-bottom-of-things/">
   Getting to the Bottom of Things</A>.
In that piece, Cook concerns himself mostly with
multitasking, focus, and context switching, but
there is more.  The mindset of the scientist --
who is trying to understand the world at a deep
level -- is different than the mindset of the
practitioner or tool builder.  Time and energy
devoted to the latter almost certainly cannibalizes
the time and energy available for the former.

As I think in these terms, it seems clearer to me
one advantage that some so-called teaching faculty
have over research faculty in the classroom.  I've
always had great respect for the depth of curiosity
and understanding that active researchers bring to
the classroom.  If they are also interested in
teaching well, they have something special to share
with their students.  But teaching faculty have a
complementary advantage.  Their ability to stay on
top of things means that their courses can be on
the cutting edge in a way that many research
faculty's courses cannot.  Trade-offs and balance
yet again.

For what it's worth, I really am intrigued by the
possibilities offered by Scala and Clojure for my
Programming Languages course.  If we can have all
of the beauty of other functional languages at the
same time as a connection to what is happening out
in the world, all the better.  Practical connections
can be wonderfully motivating to students -- or seem
seem cloyingly trendy.  Running on top of the JVM
creates a lot of neat possibilities not only for
the languages course but also for the compilers
course and for courses in systems and enterprise
software development.  The JVM has become something
of a standard architecture that students should
know something about -- but we don't want to give
our students too narrow an experience.  Busy, busy,
busy.
-----