TITLE: A Family of Functions from a Serendipitous Post, and Thoughts about Teaching
AUTHOR: Eugene Wallingford
DATE: January 05, 2023 12:15 PM
DESC: 
-----
BODY:
 Yesterday, Ben Fulton
<a href="https://mastodon.social/@benfulton@fosstodon.org/109631929184503885">
   posted on Mastodon</a>:
<blockquote><em>
 TIL: C++ has a <tt>mismatch</tt> algorithm that returns the first
 non-equal pair of elements from two sequences.  ...
</em></blockquote>

 C++'s <tt>mismatch</tt> was new to me, too, so I clicked through to
<a href="https://en.cppreference.com/w/cpp/algorithm/mismatch">
   the spec on cppreference.com</a>
 to read a bit more.  I learned that <tt>mismatch</tt> is an algorithm
 implemented as as a template function with several different signatures.
 My thoughts turned immediately to my spring course, Programming Languages,
 which starts with an introduction to Racket and functional programming.
 <tt>mismatch</tt> would make a great example or homework problem for
 my students, as they learn to work with Racket lists and functions!
 
 I stopped working on what I was doing and used the C++ spec to draw up
 a family of functions for my course:
<pre>
    ; Return the first mismatching pair of elements from two lists.
    ; Compare using eq?.
    ;   (mismatch lst1 lst2)
    ;
    ; Compare using a given binary predicate comp?.
    ;   (mismatch comp? lst1 lst2)
    ;
    ; Compare using a given binary predicate comp?,
    ; as a higher-order function.
    ;   ((make-mismatch comp?) lst1 lst2)
    ;
    ; Return the first mismatching pair of elements from two ranges,
    ; also as a higher-order function.
    ; If last2 is not provided, it denotes first2 + (last1 - first1).
    ;   (make-mismatch first1 last1 first2 [last2]) -&gt; (f lst1 lst2)
</pre>

 Of course, this list is not exhaustive, only a start.  With so many
 related possibilities, <tt>mismatch</tt> will make a great
 <em>family</em> of examples or homework problems for the course!  What
 a fun distraction from the other work in my backlog.

 Ben's post conveniently arrived in the middle of an email discussion
 with the folks who teach our intro course, about ChatGPT and the role
 it will play in Intro.  I mentioned ChatGPT in
<a href="https://www.cs.uni.edu/~wallingf/blog/archives/monthly/2022-12.html#e2022-12-11T09_09_50.htm">
   a recent post</a>
 suggesting that we all think about tools like ChatGPT and DALL-E
 from the perspective of cultural adaptation: how do we live with
 new AI tools knowing that we change our world to accommodate our
 technologies?  In that post, I mentioned only briefly the effect
 that these tools will have on professors, their homework assignments,
 and the way we evaluate student competencies and performance.  The
 team preparing to teach Intro this spring has to focus on these
 implications now because they affect how the course will work.  Do
 we want to mitigate the effects of ChatGPT and, if so, how?

 I think they have decided mostly to take a wait-and-see approach
 this semester.  We always have a couple of students who do not write
 their own code, and ChatGPT offers them a new way not to do so.  When
 we think students have not written the code they submitted, we talk
 with them.  In particular, we discuss the code and ask the student
 to explain or reason about it.

 Unless the presence of ChatGPT greatly increases the number of students
 submitting code they didn't write, this approach should continue to
 work.  I imagine we will be fine.  Most students want to learn; they
 know that writing code is where they learn the most.  I don't expect
 that access to ChatGPT is going to change the number of students
 taking shortcuts, at least not in large numbers.  Let's trust our
 students as we keep a watchful eye out for changes in behavior.

 The connection between <tt>mismatch</tt> and the conversation about
 teaching lies in the role that a family of related functions such
 as <tt>mismatch</tt> can play in building a course that is more
 resistant to the use of AI assistants in a way that harms student
 learning.
 
 I already use families of related function specs as a teaching tool
 in my courses, for purely pedagogical reasons.  Writing different
 versions of the same function, or seeing related functions used to
 solve slightly different problems, is a good way to help students
 deepen understanding of an idea or to help them make connections
 among different concepts.  My <tt>mismatch</tt>es give me another
 way to help students in Programming Languages learn about processing
 lists, passing functions as arguments, returning functions as values,
 and accepting a variable number of arguments.  I'm curious to see
 how this family of functions works for students.

 A set of related functions also offers a tool both for helping
 professors determine whether students have learned to write code.
 
 We already ask students in our intro course to <b>modify</b> code.
 Asking students to convert a function with one spec into a function
 with a slightly different spec, like writing different versions of
 the same function, give them the chance  benefit from their
 understanding the existing code.  It is easier for a programmer to
 modify a function if they understand it.  The existing code is a
 scaffold that enables the student to focus on the single feature
 or concept they need to write the new code.

 Students who have not written code like the code they are modifying
 have a harder time reading and modifying the given code, especially
 when operating under any time or resource limitation.  In a way,
 code modification exercises do something simpler to asking students
 to explain code to us: the modification task exposes when students
 don't understand code they claim to have written.

 Having ChatGPT generate a function for you won't be as valuable if
 you will soon be asked to explain the code in detail or to modify
 the code in a way that requires you understand it.  Increasing the
 use of modification tasks is one way to mitigate the benefits of
 a student having someone else write the code for them.  Families
 of functions such as <tt>mismatch</tt> above are a natural source
 of modification tasks.

 Beyond the coming semester, I am curious how our thinking about
 writing code will evolve in the presence of ChatGPT-like tools.
 Consider the example of auto-complete facilities in our editors.
 Few people these days think of using auto-complete as cheating,
 but when it first came out many professors were concerned that
 using auto-complete was a way for students not to learn function
 signatures and the details of standard libraries.  (I'm old
 enough to still have a seed of doubt about auto-complete buried
 somewhere deep in my mind!  But that's just me.)

 If LLM-based tools become the new auto-complete, one level up
 from function signatures, then how we think about programming
 will probably change.  Likewise how we think about
 <em>teaching</em> programming... or not.  Did we change how we
 teach much as a result of auto-complete?

 The existence of ChatGPT is a bit disconcerting for today's profs,
 but the long-term implications are kind of interesting.

 In the meantime, coming across example generators like C++'s
 <tt>mismatch</tt> helps me deal with the new challenge and gives
 me unexpected fun writing code and problem descriptions.
-----