TITLE: Programming Like a Student Again
AUTHOR: Eugene Wallingford
DATE: September 27, 2021  2:04 PM
DESC: 
-----
BODY:
 For the first time in many years, I got the urge this fall to
 implement the compiler project I set before my students.

 I've written here about this course many times over the years.
 It serves students interested in programming languages and
 compilers as well as students looking for a big project course
 and students looking for a major elective.  Students implement
 a compiler for a small language by hand in teams of 2-5,
 depending on the source language and the particular group of
 people in the course.

 Having written small compilers like this many times, I don't
 always implement the entire project each offering.  That would
 not be a wise use of my time most semesters.  Instead, when
 something comes up in class, I will whip up a quick scanner or
 type checker or whatever so that we can explore an idea.  In
 recent years, the bits I've written have tended to be on the
 backend, where I have more room to learn.

 But this fall, I felt the tug to go all in.

 I created a new source language for the class this summer, which
 I call Twine.  Much of its concrete syntax was inspired by
 <a href="https://en.wikipedia.org/wiki/SISAL">
    SISAL</a>,
 a general-purpose, single-assignment functional language with
 implicit parallelism and efficient array handling.  SISAL was
 designed in the mid-1980s to be a high-level language for large
 numerical programs, to be run on a variety of multiprocessors.
 With advances in multiprocessors and parallel processors, SISAL
 is well suited for modern computation.  Of course, it contains
 many features beyond what we can implement in a one-semester
 compiler course where students implement all of their own
 machinery.  Twine is essentially a subset of SISAL, with a few
 additions and modifications aimed at making the language more
 suitable for our undergraduate course.

<table border="0" cellpadding="0" cellspacing="0"
       style="float: right; margin-left: 3em; margin-right: 1em;">
<tbody><tr><td>
   <img src="http://www.cs.uni.edu/~wallingf/blog-images/academic/sisal.jpg"
        alt="the logo of the Twine programming language"
        width="150"
        align="right" />
</td></tr></tbody>
</table>

 (Whence the name "Twine"?  The name of SISAL comes from the
 standard Unix word list.  It was chosen because it contains
 the phrase "sal", which is an acronym for "single assignment
 language".  The word "sisal" itself is the name of a flowering
 plant native to southern Mexico but widely cultivated around
 the world.  Its leaves are crushed to extract a fiber that is
 used to create rope and twine.  So, just as the sisal plant is
 used to create twine, the SISAL programming language was used
 to create the Twine programming language.)

 With new surface elements, the idea of implementing a new front
 end appealed to me.  Besides, the experience of implementing
 a complete system feels different than implementing a one-off
 component...  That's one of the things we want our students to
 experience in our project courses!  After eighteen months of
 weirdness and upheaval at school and in the world, I craved
 that sort of connection to some code.  So here I am.

 Knocking out a scanner in my free time over the last week and
 getting started on my parser has been fun.  It has also reminded
 me how the choice of programming language affects how I think
 about the code I am writing.

 I decided to implement in Python, the language most of my student
 teams are using this fall, so that I might have recent experience
 with specific issues they encounter.  I'd forgotten just how
 list-y Python is.  Whenever I look at Python code on the web, it
 seems that everything is a list or a dictionary.  The path of
 least resistance flows that way...  If I walk that path, I soon
 find myself with a list of lists of lists, and my brain is
 swimming in indices.  Using dictionaries replaces integer indices
 with keys of other types, but the conceptual jumble remains.

 It did not take me long to appreciate anew why I like to work
 with objects.  They give me the linguistic layers I need to
 think about my code independent of languages primitives.  I know,
 I know, I can achieve the same thing with algebraic types and
 layers of function definitions.  However, my mind seems to work
 on a wavelength where data encapsulation and abstract messages
 go together.  Blame Smalltalk for ruining me, or enlightening me,
 whichever your stance.

 Python provides a little extra friction to classes and objects
 that seems to interrupt my flow occasionally.  For a few minutes
 this week, I felt myself missing Java and wondering if I ought
 to have chosen it for the project instead of Python.  I used to
 program in Java every day, and this was the first time in a long
 while that I felt the pull back.  After programming so much in
 Racket the last decade, though, the wordiness of Java keeps me
 away.  Alas, Python is not the answer.  Maybe I'm ready to go
 deep on a new language, but which one?  OOP doesn't seem to be
 in vogue these days.  Maybe I need to return to Ruby or Smalltalk.

 For now I will live with OOP in Python and see whether its other
 charms can compensate.  Living with Python's constraints shows up
 as a feature of another choice I made for this project: to let
<a href="https://pypi.org/project/pycodestyle/">
   pycodestyle</a>
 tell me how to format my code.  This is an obstacle for any
 programmer who is as idiosyncratic as I am.  After a few rounds
 of reformatting my code, though, I am finding surrender easier
 to accept.  This has freed me to pay attention to more important
 matters, which is one of the keys ideas behind coding and style
 standards in the first place.  But I am a slow learner.

 It's been fun so far.  I look forward to running Twine programs
 translated by my compiler in a few weeks!  As long as I've been
 programming, I have never gotten over the thrill of watching my
 compiler I've written -- or any big program I've written -- do
 its thing.  Great joy.
-----