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