Oops, I accidentally dropped the mailing list. On Mon, Dec 17, 2018 at 3:09 PM Chris Smith wrote:

On Mon, Dec 17, 2018 at 12:25 PM Fernando Alegre wrote:

...

I am also testing material for other courses with a couple of teachers and also directly with a small group of advanced students. I liked the CodeWorld environment so much that I decided I would try it with the advanced students, and the feedback I got has been very interesting. Apart from their dislike of the syntax and similar nuances, their main complaint is that functional programs are too dense, and that increases their cognitive load too much, so that, even though they can write the code, they do not enjoy doing it. I am struggling to find ways to make it more enjoyable for them, as it is really fun for me.

Thanks for sharing this. I've been thinking about similar things. My observation is that composing expressions seems to be a very unfamiliar, and therefore uncomfortable, way of working for many students (perhaps for many non-students, as well). It's natural for students to worry about what they need to do, but not about how to connect it to what's already there. Therefore, they want to just add the right thing in their code. They can tolerate having to add it between some curly braces. But thinking about how the new addition is related to the whole, where it fits, and how it's combined, seems to be a step too far for many. Beginners in imperative languages have exactly the same problems when they are forced to program with nested blocks of control flow and other substantial structure. But imperative code comes with a default aggregation on statements, while the functional environment mostly forces you to be explicit about how subexpressions are composed together, from the beginning.

On the one hand, I'd like to argue that increasing students' familiarity with this kind of thinking, which I see as part of the essence of a mathematical world-view, is in fact the goal, and therefore worth doing regardless of student support. But, if course, you can't really force anyone to learn anything against their will, so this answer is not sufficient. In any case, I suspect we're seeing the same thing, and I think you're right that it's often a fight to get students on-board because the functional environment asks them for more careful thinking than they would like it to. If you do find an answer to this, I'd love to see it.

My best answer so far is to allow students to see the program's structure in a variety of ways. The "Inspect" button in CodeWorld is an example of this. When a student shoves something into a drawing at the wrong place and becomes frustrated, I often find it helpful to ask them to open up the Inspect dialog, and take a look at how different expressions in their code define their own pictures, and check that against what they expected. It helps, but it doesn't make the problem go away. Luite and Shae and I talked at ICFP this year about a more general-purpose system for examining the meanings of expressions in a running Haskell program, and I think it's doable with GHC 8.6 and a lot of work. I'm still waiting on GHCJS to reach a stable 8.6 milestone before I give it a shot. There's a brief write-up at https://github.com/google/codeworld/issues/741, but the idea is certainly not specific to CodeWorld (except for the UI portion). I think having something like this at one's disposal would make it easier to give students a feeling for the idea that each of their subexpressions really is a meaningful value in its own right, and really understanding that as a tool for comprehending code seems to be the key for getting over the unfamiliarity and finding the power of this way of working. But, that could be me just being optimistic.

Chris