How Far We Have Come With Programming Languages

Last night I had a dream during which someone suggested that COBOL would make a good first programming language. They tried to promote the data division and English language syntax as plusses. When I shared this on social media it got a lot of laughs. Few would take this as a serious idea and with good reason.

We used to joke that the hardest part of programming in COBOL was learning how to spell environment. (You had to be there) But really that data division was a bear to get right. The cognitive load was a lot for beginners. Today they are some who think that static variable declarations are enough cognitive load to hold students back and COBOL was a lot of effort.

COBOL is still around and I understand that it has changed somewhat. I thought that “Structured Programming in COBOL” (there was such a book) was a stretch but object oriented  COBOL just boggles my mind.

Most of the people in my age group in the industry have some experience with COBOL. For more than a few it was the first or second or, as in my case, third programming language. Learning multiple programming languages was a big thing early in my career. FORTRAN, COBOL, BASIC, and C (before C++)  were all a part of many people’s tool box. I worked on one project that had code in all four of those languages plus PASCAL.

Today we have a lot of new languages. C++. C#, Java, JavaScript, Rust, and I could go on and on. Today’s languages have more and more powerful decision structures, looping structures and libraries that do things for us that we used to have to program ourselves. We have improved error handling, the ability to use classes and objects, and many other cool features. That doesn’t even touch on powerful IDEs and the ability to compile and get results in seconds rather than hours and days.

With power often comes complexity. Complexity means cognitive load and potential for confusion and errors. We walk a fine line determining what to teach and how to prevent students from getting overloaded. It’s an exciting time to be teaching for sure.

Dealing With Student Misconceptions

I was reading through The Big Book of Computing Pedagogy, as one does, the other night. Specifically, the section on student misconceptions. Misconceptions are one of my favorite topics in teaching computer science. The articles in this book are very helpful in understanding what student misbelieve and why they do so.

I’ve seen students with all of the common misconceptions and, of course, I try my best to help them overcome them before they get students into trouble.I tried to remember if I experienced any of them myself but memory of 50 years ago is very selective. What I do remember is that I had some experiences of getting very close to the hardware early on. While my first course was learning FORTRAN the computer we used required some extra (compared to today) to run. Specifically, it requires that one toggle in some instruction in binary using toggle switches to get it to read in a couple of punch cards that did the next phase of the boot up.

Not long after I learned the first two of what would be 7 or 8 assembly languages over my career. There is something about toggling a memory address so that one could read (in binary lights) or enter information in binary with those same switches to program a computer that give one a good understanding of what memory actually is.t

Those days are long gone of course and while assembly language still gets one close to the computer and gives an understanding of how things like memory work it can also be a gate or barrier to students. It’s actually not the ideal way to understand concepts that one might think. It’s not the sort of visual experience that today’s students are used to learning from.

What we really need is some better visualization tools for introducing concepts. My first thought was using debugging tools such as those built into tools like Visual Studio. One can single step though instructions and view the contents of memory (variable) locations. It works but it is slow and tedious. That may be fine for debugging but for learning it has a high cognitive load that gets in the way of what we’re trying to do in teaching.

So I have been thinking about how to create visualizations that are simple to use and that might help clear up misconceptions. Two things my thinking is focusing on are how variables and memory work and how loops and loop control variables work. Eventually I have to narrow it down to one of them to start. I should probably look at what might already be available first. I thought I would start by asking you, my readers, for suggestions. So, any ideas? How do you help students visualize these concepts? Any suggestions on tools for creating visualizations?

Coding It Yourself Can Be Fun

Every couple of weeks I bake a couple of loaves of bread. The bread mostly gets used for breakfast sandwiches. Now my bread does not look as perfect as what I could get in a bakery. And the bagels? Once in a while I try my hand at bagels, don’t look anything close to what I get at my favorite bagel place. But they all taste good and I find it very satisfying to make it myself.

Coding can be a bit the same. Not everyone writes professional looking (or performing) code but sometimes there is some satisfaction in having a program that works just they way you want it to and does just what you need. Maybe it is not “release to the public” neat and tidy. It may be what we used to call a “programmers program.” In other words, a program that only the programmer who write it could (or would) use. My Wordle solver helper program is one such. It works great – for me. It doesn’t have the error checking a released program should have. And maybe it should start at one and not zero. But it works great for me.

Programming is basically stating a process or method using computer code. My Wordle solver represents my thinking of how I think Wordle could be solved. It was fun to write and is fun to use. It’s not ready for prime time though. Does that make it a bad program? No more than my imperfect bread or bagels are bad. They both meet my needs and that, for me, for these, is all that matters.

In some ways, that is the message we may want to pass on to students. Many, perhaps most, of our students will not become professional software developers. They may still write code for their own tasks or interests though. We need to help them enjoy that experience. One way to do this is to assign projects that are interesting to the student. Open ended projects are good for this but even better is letting students select their own projects.

For semester ending projects, I used to allow students to select from a list of suggested projects and also to have the option to design their own projects (after discussion with the teacher) that solved a problem that they were interested in solving.  Helping students find the fun and satisfaction in solving an assignment promotes their learning. And, I hope, helps them think of computer science as worth doing for themselves.

Names Have Power – Names and Programming

"A rose by any other name would smell as sweet" William Shakespeare.

There are cultures where people have a sort of public name and a secret or true name that is rarely shared because knowing ones true name gives people power over them.  In fact, knowing a name is powerful in all cultures. Consider the difference between calling “hey you” versus calling a child by their actual name. Which way draws them up sharp?

Naming is important in computer programming as well. It’s not always as easy or as simple as beginners assume it is. Mike Zamansky’s post Subtle Errors gives a good example.  Having more than one item with the same name causes the sort of ambiguity that computers do not handle well. Some names (identifiers as we often call them in programming) have special meanings. Getting names slightly wrong can cause other problems.

A name can provide a great deal of information to a programmer. To the compiler names are pointers to more information. A variable name identifies a location to the computer. Other information about the data stored in that location is specified in other ways. The computer doesn’t care what characters make up the name. That it is unique is important but not the characters involved. In many programming languages the case of the letters makes two names completely different. People tend to see them as identical.

Beginners often think that “the computer” pays attention to everything in a program the same way people do. That’s not the case though. I’ve had students write comments in their code believing that the computer will read the comment and perform the action. They may also assume that naming conventions, starting all integer valuable names with “int” for example, will influence the computer. Again, not usually the case.

[Note: back in the day, any variable starting with one of the letters “I” through “n” was automatically an integer.]

Names/identifiers can communicate a lot of information to programmers. They are pretty important for sure.It is easy to gloss over them and minimize their importance. Getting them right though is something worth spending time on.