.png)
Not so long ago, LLMs were incapable of producing output that matched the quality of a competent human. Hence the derogatory term “slop”. Like it or not, this is no longer always the case. You can get very good results after a series of prompts. With some luck, on the first try.
Of course, very good does not mean perfect. If you care about every little detail, or about having things done your way, as many of us do, then sure, you will be able to nitpick endlessly. For example, LLMs tend to prefer quick-and-dirty fixes over principled solutions.
But there are plenty of cases where that’s exactly what’s needed. In particular, LLMs are superb at prototyping or one-off scripts, where we care less about the exact choice of abstractions and just need a solution good enough to make progress.
This is certainly useful for a working software engineer. At the same time, it presents a serious challenge for educators: how do we adapt the curriculum when a model can breeze through student-level tasks?
Every functional programming course used to have the same silent assumption baked into it: that writing the code is the hard part. This had two implications:
- The amount of code a student could write during the course was low.
- A lot of learning would take place in the process of writing that code.
This meant that a handful of small exercises could fill an entire week. For example:
- Express function composition and argument flipping using nothing but the
SandKcombinators. - Define the factorial and the Fibonacci sequence via
fixrather than explicit recursion. - Implement Peano arithmetic on
data N = Z | S Nwithout touching a built-in numeric type. - Write out
Functor,Applicative, andMonadinstances by hand for a dozen types in a row, until the pattern behind them becomes visible.
Getting a solution to any of these exercises is no longer hard. Every item on that list is one prompt away from a complete, idiomatic solution. Understanding that solution is another matter. It is not obvious that this is bad, but it is obvious that it invalidates a lot of course design, ours included.
This post is about the choice we made. The next one is about how the course will be structured and graded.
Ban or embrace?
Broadly, there are two answers to the LLM question.
Ban. One approach is to barricade ourselves against new technology and require students to complete tasks unassisted. After all, that is how we learned back in the day, and it evidently worked, so the idea is to recreate similar circumstances for our students.
There are two major problems with this:
- It does not match the environment students will find themselves in when they enter the job market. Companies are adopting LLMs and encouraging their use to get more done in less time.
- Faculty resources are limited. Giving lectures and talking to students is the pleasant part of the job, but grading homework has always been a chore. Some students will use LLMs anyway, and catching them turns that chore into a nightmare.
Embrace. The other approach is to let students use the tools and raise the bar on what we ask of them. Allowing the use of technology in a class about technology sounds like the natural choice.
This, too, is not without issues:
- We cannot tell from the submission alone what the student has learned. A submission can be excellent and still say nothing about the person who submitted it.
- The course has to be redesigned. We need tasks and assessments that reveal whether students understand the problem and can explain, test, and modify the code, even when a model helped write it.
As an experiment, and because doing nothing is not an answer either, we are developing a new functional programming course based on the Embrace approach.
We would like to hear from others facing the same problem: if you teach, how would you deal with LLMs in your course?
Discussion: https://www.reddit.com/r/haskell/comments/1wufrkf/teaching_haskell_in_the_age_of_llms_part_1_ban_or/
In the next post, we will describe how the course is structured and how we plan to grade it.
