Thursday, February 23, 2023

Does It Run in the IDE?

I was reading a tweet from a person saying they lost points a program written with pen and paper because the teacher thought the code would not run. When the student asked the teacher to write the code on the computer it ran.

The Twitter discussion was on the wrongness of code assignments on paper but I am not sure that paper coding assignments are necessarily wrong. I suspect that the problem in the Twitter user's case may have been a teacher who is experienced. I could be wrong of course.

The real problem is a teacher putting too much faith in their own mental execution of the code on the paper. I have found it a good practice to enter code I was the least unsure of into an IDE and run it on the computer. I’d almost always check code I thought did not work. Students can be very clever and write code that doesn’t look like it will work but does work. Or code that does look like it works but doesn’t.

This all points to problems with testing computer programming in general. Writing code for evaluations is problematic in a number of ways. Yes, I know the AP exams do it that way. I’ve only graded the AP A exam once but I can tell you it’s not that easy. Handwriting can be hard to read for starters. I’ve already mentioned how clever students can be. I loved the 10 line code answer for a guestion that was looking for a one line return statement. I could have saved myself a lot of time if I could have verified it by running it.

Asking students to write code in an IDE offers logistical issues for starters. There is also the issue of students being able to look at each other’s screens and sharing files. Some object to students using autocorrect, error checking, and help files. All the sorts of things professional developers use. Some teaches do prefer code turned in electronically because it allows for auto graders. I’ve discussed them here several times. Basically, mixed feelings.

Evaluating student knowledge is one of the more difficult tasks programming teachers. It’s a problem with no easy answers. For now, I think, the best policy is to use a variety of assessments.

Tuesday, February 14, 2023

People Are Bad At Giving Instructions

One of the things that make me sure that programming will be around for awhile even with better and better artificial intelligences is that people are bad at giving instructions. Well, that may be unfair. They are reasonably good at giving instruction to other people but that is not the same as being good at giving instruction to the literal minded.

The most famous instruction, I first heard it from Grace Hopper almost 50 years ago is the instruction for using shampoo “Lather, Rince, Repeat.” There is a lot left out there. Most obviously, repeat how many times? It also doesn’t say if one should wet their hair first. In computer terms, an infinite loop without setting initial conditions.

I recently bought a new cover for a light switch. The first instruction was to turn off the circuit breaker for the switch. Good advice. On the other hand, the instructions did not say to reset the circuit breaker when finished installing the cover. A literal minded installer would never have a working switch.

Of course, people figure these things out. We are aware of the larger context and are good at filling in missing pieces. Computers are not that good at any of this.

Part of what we teaching when teaching programming is how to give instructions. Not just how to translate those instructions into code but to fully understand and describe the steps needed to complete at task. I believe these are necessary skills. I think they will translate to other fields. Not that I have proof but it seems logical. In any case, we’re going to have to get good at giving instructions if we are going to tell AIs what code  to write.

Sunday, February 12, 2023

CS Students–Learn Your IDE

Eugene Wallingford had a great post on WHAT WHAT DOES IT TAKE TO SUCCEED AS A CS STUDENT? It’s got a lot of good advice and I recommend it to students in high school or university. For now I want to focus on one or two pieces of his advice. Specifically, “Get to know your programming environment”

For the most part, in class, teachers have time to do an introduction to the development environment but not much more. We run through “Hello World” or similar to walk students though creating a project entering code, and running their first program. That;s all we have (or perhaps all we make time) for.

Typically there is a lot more to a development environment than what we show students. Even a simple IDE like IDLE for Python or Visual Studio Code has a lot or options and functions we don’t go over in class.

Students who spend some of their own time exploring their development environment are going to have an easier time though out their course. Indeed, throughout their CS career.

Related to learning your development, Prof Wallingford suggests keeping your IDE open while reading through textbooks or other resources. That lets one more easily try out code examples while studying. That goes a long way towards understanding what one is reading. When I review textbooks or other teaching resources I always run the code examples for myself. In part , to see if they are correct of course but also to see for myself what students will see and learn from the example.

Writing code that is not specifically assigned for a course is always a help for learning. If a student takes the time to experiment with a project of their own interest they will do far better in the course they are taking.