Different High School Computer Science Strands

A recent talk by Bjarne Stroustrup at Stanford has sparked some conversation in the Computer Science Educators Facebook group. The talk itself doesn’t seem to be available but it was reported online at The Stanford Daily - C++ creator Bjarne Stroustrup reimagines how coding is taught

There is a lot there and I agree with some things in the article and disagree with others. I have less enthusiasm for C++ as a teaching language, especially in early courses,  for example. I’s like to share some thoughts on the idea of different strands and early courses for different audiences. These are initial thoughts intended to start discussion. I am open to the ideas of others.

First off, I understand that the idea of different first CS courses is difficult at the high school level. Stroustrup seems to be focused, as it seems most university CS faculty are, on the university level. Offering different courses is easier there as the size of both faculty and students tends to be larger. I do think that, where possible, high schools should give the idea some thought.

Stroustrup suggests three strands:

One would serve nonprofessionals, or those who only want basic tools. The second caters to scientists who want to focus on application-based programming instead of theory. The third emphasizes engineers or specialists who want to dive deeper into the complexities of software engineering.

I think universities need a strand for scientists who want to delve into theory. Regardless, I think high schools should consider a different set of strands.

One strand would be less theory and more applications based. Probably using Python or R with a focus on libraries more than theory. Statistics could be included as that would be particularly useful for students in the liberal arts. Skip the data structures that computer scientists love so much. Not everyone needs to spend a lot of time on those. Know what they are and where they fit in but not deeply how they are implemented. It’s more important to understand concepts like normalizing data and how to use libraries.

The second strand would be more theoretical for those students who want to be computer scientists and/or software developers. My time in industry taught me that theory is a lot more important than many self taught developers want to admit. There may be a place for C++ here though I would prefer that early in the strand start with C# (or Java if you must). This is where one would get into data structure implementation, Big O and optimization, and theory of computation.

I do think that in high school either strand should start with something like APCS Principles. It is a good base to start with. True multiple strands are very difficult in most high schools of course. If I had to pick one strand it would be the first one. Why? Because that would serve the most students well. Keep the AP CS A course for the serious CS geeks (my people) and make sure that teachers allow those students to go beyond the basics in the other courses where possible.

We need more students with computing skills and knowledge than we need high schools to turn out computer scientists.

Hardware–Heat and Cold

Not all computer problems are caused by software. Sometimes the hardware is the problem. It’s not always easy to tell where the blame lies. One underappreciated factor is the environment. Both mechanical and electronic parts are impacted by heat and cold. There is a reason that computer companies specify operating temperatures.

I think most people understand about overheating but maybe not the problems of to cold.

One day I received a support call from a customer. They were a tomato distributor receiving tomatoes and sending them to supermarkets and grocery stores all over New York City. The problem was that their computer did not work on Monday moorings. Monday afternoon was fine as was the rest of the week. Sure, people have trouble getting started on Mondays but computers should not care about days of the week.

Their computer used floppy disks. Now floppy disks were not sealed in vacuum and the read/write heads had to be a specific distance from the disks. I’d visited the company and knew something about the office. Most of the building was unheated for the good of the tomatoes. I asked if they ran the heat in the office over the weekend. The answer was “no.” The office got pretty cold over a winter weekend. The cold caused the parts of the computer, especially the disk read/write heads to contract pulling away from the disks. As the office  warmed up the tolerances returned to normal and the computer worked just fine.

Electronic parts get hotter as current runs through them. This can cause expansion which can cause all sorts of problems. That’s why fans are installed in computers – to keep things from getting to hot.

Back some years ago, Microsoft donated  a bunch of computers to a school. The computers had been purchased as part of an investigation into counterfeit software. Once the court case was over there was no need to keep the computers. Now these computers had been sitting in a warehouse for quite some time and not all of them were in perfect running order. I was one of several volunteers who were tasked with diagnosing and, hopefully, fixing some of these computers.

One of the computers had a note on it that said it was crashing at a certain part of the installation of Windows. Software problem? Perhaps. So I started an installation and sure enough the computer crashed at the noted location. I tried again but this time the computer crashed almost immediately. So probably not software. I opened up the computer and it seemed a little hot to me. And the fan was not working.

Aha! It turns out that one of the wires connected to the fan was not actually connected. The fan was not getting power and so was not running when the computer got hot. Connecting the wire fixed the problem and everything went perfectly.

It pays to be aware of environmental conditions both inside and outside the computer.

Software Learning Stories - Comments

Continuing my software learning stories series, I will talk a bit about commenting code.

One customer I supported many years ago was a Jewish cemetery. In the Jewish tradition, visiting grave sites is very important. For this reason, a database had been created that stored the location of every grave in the cemetery. This allowed the people there to easily draw maps so that family members could visit their relative’s grave sites. Unfortunately, the database started losing records. I was called in to find and fix the problem.

It was quickly determined that the database software created by the company I worked for was at fault. Now this was proprietary software which means that the source code was not readily available. Especially not externally to the company. Someone from corporate headquarters came out with the source code to help find the problem.

Now apparently, someone at another company had purchased a source code license for the software. A junior developer was told to remove the comments from the copy provided to that other company. (Mean I know!) Unfortunately, they neglected to keep a fully commented copy for internal use. This meant that we, the home office person and I, had to do a lot of figuring out what was happening in some very complicated code.

We eventually solved the problem, if I remember correctly, but it took a lot longer than it should have. Or would have if we had had commented code.

One more comments story. While I was an undergraduate I wrote some fun graphics programs. They were mostly written on punch cards in FORTRAN IV. Years later I decided to rewrite one in Visual Basic to display on a screen. I figured that I was a smart guy and it would be easy. Unfortunately, when I first ran it the program drew what sort of looked like random lines and not the cool geometric shapes I was aiming for. The mess looked strangely familiar though.

Now it turns out that in my attic I had the original card deck. I dug it out and there were comments for many of the key lines. One of them was a reminder that a key method expected degrees to be expressed in radians. Ah ha! That was the missing piece of my new program. I fed a method in radians and my new program worked perfectly.

A good reminder that we can’t remember everything and even our own code can benefit from a good comment in the right place.

The software learning stories series:

• Software Learning Stories – Comments
• Software Learning Stories–Bugs are Undependable
• Software Learning Stories–Constants

Software Learning Stories–Bugs are Undependable

There is a joke in the software development community that “it’s not a bug. It’s an undocumented feature.” It’s typically used when a bug is too hard to fix or that is ordinarily harmless. Depending on such bugs is not a good idea though. Some people ignore the risk though.

Many years ago I was working for a company that made some great hardware and, well, let us say, less impressive software. One of their products was a FORTRAN compiler. FORTRAN has a FOR loop – a counting loop. The language specification calls for the loop to determine if it should continue at the top of the loop.

FOR loops have a starting and ending value. These values can be held in variables and if the loop determines that the end value is greater than or higher than the starting vale, if counting up, that the loop will not execute. This company’s compiler checked at the bottom of the loop. This violate the specification and created a situation where the loop always executed at least once.

One of the customers I was supporting took advantage of this bug. They did it often. Unfortunately the company I worked for came out with a new version of the compiler. This version was outstanding. It was one of the first optimizing compilers and generated very fast, efficient code. The developers were also extra careful to make sure it confirmed to the official language specification. So the customers programs broke.

I got the call from their VP of software development and explained what happened. Being a smart guy, he realized that the fault lay with his developers and not our software. Crisis averted for me. Some extra work for the customer’s development team. Hopefully, the developers learned to understand how software was supposed to work and not take “advantage” when it worked differently.

The software learning stories series:

• Software Learning Stories – Comments
• Software Learning Stories–Bugs are Undependable
• Software Learning Stories–Constants

Software Learning Stories–Constants

I am a big fan of using stores to teach. Stories are more memorable that contextless theoretical statements. In my career, over fifty years of programming, I have run into a few that I have told again and again. I thought I might share a couple of short stories here. I'll start with a story about why hard coding numbers can be a very bad idea.

Some years ago I was working on a team of five people creating a huge test structure to test computer systems. The systems were called VAX Clusters. These systems consisted of, initially, sixteen nodes.  These nodes consisted of a disk storage node, and up to fifteen computers. Actually, any mix of computers and disk storage controllers totaling sixteen nodes. Now these computers were expensive, more like a million dollars or more than what we think of as computers today.We

Obviously, we had a lot of code that used sixteen as a number. Or more commonly, 15 since loops and arrays start at zero. These numbers were used everywhere! Everything was fine until the company announced that they were now going to support 32 nodes in a cluster. Uh oh! We spent a lot of time, weeks in fact, changing the code to support 32 nodes. It was not just a matter of doing some sort of bulk edit. Each line of code had to be examined, evaluated, changed if appropriate and then everything had to be tested completely. It was a lot of work.

We did get smart though. We defined a couple of constant variables and used these named constants in place of hard coding specific numbers. Something we should have done in the first place of course.

Later, actually several later times, when the number of supported nodes was changed again, we only had to edit a few constants, rebuild the system, and things worked very well. Lesson learned: Hard coding magic number is not a good idea. There is a real place for constants.

The software learning stories series:

• Software Learning Stories – Comments
• Software Learning Stories–Bugs are Undependable
• Software Learning Stories–Constants

Teaching The Writing of Secure Code

One of the great problems of teaching computer science is that there is a limited amount of time to teach and an unlimited amount of things that can be taught. There is very little degree of agreement of what must be taught. Teachers do the best they can but there is a good amount of variation on what gets taught. One thing that seems to always (or close to always) get left out is writing safe and secure code.

Few teacher give more than a cursory mention of error handling for example. The try/catch keywords get a little use but not much. For the most part, when a student program goes wrong it just crashes. Student programs tend to depend on the user entering information in the way the program is set up to receive it. This works, more or less, in the context of student projects because the projects are generally designed to test or use specific concepts other than error handling.

Outside of school, validating data as it is input is pretty important. There is a classic XKCD comic that highlights this idea. Bonus as it includes a school context. This is one way to at least talk about the concept even if there isn’t a lot of time and ability to reenforce it with a project. Though, string manipulation projects are sometimes a good way to talk about writing code to force specific forms of data formatting.

 

Back in the day, learning C (before C# or even C++) we talked a lot about memory management and things like overflowing strings and buffers. Ignoring those things was a major cause of security breaches. That’s probably true today as well.  Modern languages with string objects, garbage collection, and other forms of memory management reduce some of the risk but students will benefit with some discussion of the topics. 

Another topic that merits some discussion is validating where inputs come from. Data from a user input is obvious, usually.  Data from files a bit less obvious. Data from other code is the least obvious and potentially the highest risk.

Many years ago I was part of an operating system development group and we were adding many layers of security. Great stuff but we thought a great deal about making sure the right security information was passed along. Code deep in the OS was responsible for sharing security information with user level code. We worked hard to make sure that only trusted information was allowed to reach different levels of code. We also worked hard to make sure that only reliable information went down to lower levels.  That users can’t always be trusted is an important lesson at any level.

Secure code is a complicated issue of course. I have a great book called “Writing Secure Code” and it is almost 800 pages long. Not realistic for a high school CS class of course. I do think we can and should spend some time on the topic though. Ideally in the context of various other topics during a course. A few stories, or even cartoons, may help make the topic more memorable.

High School Cybersecurity Course–What Belongs

The last few years have seen a huge expansion in the number and types of cyber security courses in high schools. Much of this has been driven by a growth in the realization that we, society, governments, businesses, need more help making our systems secure from bad actors. CS ed as career development. Great in career technical schools of course. Yet another CS elective in comprehensive schools as well. Pretty easy to sell to school boards and administrations.

The CollegBoard has jumped on the bandwagon with AP Career Kickstart Cybersecurity Pilots.  I did take a look through that program. To me, the first course looks a lot like a standard IT/Networking course. I guess that makes sense as a prerequisite. After all,step one of a secure network is setting up a network.

The second course looks a lot more like what I think about as cybersecurity. Could be a good course. I hope that some of the pilot teachers will share what they learn while teaching it.

I don’t know that all courses calling themselves cybersecurity are that deep though. From what I have seen, some courses that call themselves cybersecurity are mostly about staying safe on the internet. That’s not a bad thing as long as proper expectations are set.

One related topic I have been thinking about is writing secure code. Is there room for that in high school? On the other hand, are we doing students a disservice by not talking about it at all? That’s the area of cybersecurity I hope to spend some more time thinking about. I’m more of a coder than a network guy.