The Great Programming Language Debate

I’m at ACM SIGCSE TS 2015. That’s the Associate of Computing Machinery’s Special Interest Group for Computer Science Education’s annual Technical Symposium. You can see why abbreviations are used. I’ve been attending this symposium since 2007 (I think I missed 2008 though).

There is an annual debate – what programming language to teach in. I think it is time we stop having this debate, for several reasons. Of I will give you those reasons and then tell you what languages that I think should be taught.

Reality tells me that the programming language doesn’t matter that much. Instead the critical skills are computational / algorithmic thinking, problem solving skills, and communication / teamwork skills. Programming is a tool we use to express our solutions to problems. A tool we use to express algorithms and to engineer systems.

My own programming career has told me that we need to be flexible as practitioners of computer science. I’ve gone from, in rough chronological order:

  • basic
  • pascal
  • C++
  • Java
  • C
  • Perl
  • C++
  • Java
  • Ruby
  • Erlang
  • Java
  • C++

So what does this say? It says that you need to be able to move between languages and paradigms. Someone with solid CS fundamentals will be able to move from one language to another and even one programming paradigm to another with minimal effort. That’s not to say you can pick up a language you’ve never seen and be super productive right away. In the order of a few weeks, you should be mostly up and running though.

In conclusion – what should be used as instructional languages? Here are my thoughts. I think that students should come out of a 4 year, BS degree having learned

  • 2 OO languages, one of which should be C++
  • 1 functional language
  • One “scripting” language

In the OO world, learn something that requires you to think about memory. C++ is really the gold standard here. Modern C++ (C++11/C++14) are quite nice and the language has come a long way. The other should be some kind of language that runs in a managed environment, or does reference counting. Something like Java/C#/Objective-C. Personally, I would pick C++ and Java.

Functional: Scheme? Haskell? Erlang? Clojure? It doesn’t matter much to me what this is. What matters is that you learn to think in the functional paradigm. Immutable state, closures, functions as first order items, etc. Personally, if I were teaching, right now I would probably use Erlang or Scheme/Racket for this purpose. Not because it is a markable skill. The language is not the skill, the way of thinking is the skill!

“Scripting language”: I’m probably unfairly bundling things here, but what I’m thinking is runtime interpreted style languages. Python, Ruby, etc.

4 languages – I think that gives a computer scientist a solid foundation for being able to change, adapt, and grow throughout their career. This is essential, because what language will we be programming in in 10 years, I don’t know, but it possibly hasn’t been invented yet.

How should you order these? Doesn’t matter too much. I would still avoid C++ as an introductory language, but having taught that last year, it is manageable, but there are still silly things that should be avoided. If I had it to do over, I would have started with vector before array, as passing arrays to functions in C++ is a mess that introductory students should not have to deal with.

In summary – maybe we should end the language debate and agree that students will learn programming paradigms. Once they get into industry, we can teach them that language we use. If someone is worth hiring, they’re worth investing some startup time on.

Thoughts from a former educator.

Need teaching materials?

Since I am leaving academics, I have decided to open source all of the materials that I have created over my 3 1/2 years as a professor.

This contains material from Miami University (2005 – 2007) and the University of Cincinnati (2013 – 2014) and contains material from these courses:

  • Computer Science 1
  • Computer Science 2
  • Data Structures
  • Enterprise Application Architecture
  • Large Scale Software Engineering

You can find it all on

What the hell happened? Part 1

I’m nearing the end of my time as a professor and I’m down to less than three weeks before I board a flight to start my new (old) job. I’m sure a lot of people are wondering exactly what went wrong this year. The story goes deeper/further back than that.

Sometime in the late 90s, I decided that college professor was the job for me. I took a rocky path to get there, but eventually earned my PhD in the field, and… couldn’t find a job. I was kind of unemployable in Cincinnati (where I was living at the time). Industry wasn’t really an option in Cincinnati, and while I had a teaching job at the time, it was 9 month contracts, and I was eventually going to be time-limited out of that position.

So, we jumped. We went out into the unknown, and tried something new on. Very early on, during my days at, I had this feeling that I didn’t belong there, that academics was surely the place for me. But I stick it out because because I needed to explore that career path and for lack of a better option. Seriously, there aren’t many people who want to hire someone with a Ph.D. in computer science for software engineering jobs.

There was always this nagging feel of “I got a PhD, why am I not using it to work in academics?” It was almost if I was letting my degree down, and not living up to my training.

Flash forward a few years, and I was finally able to make peace with not having a career in academics. And then, I had an opportunity to switch to a career in academics. For us, it wasn’t even a choice. Being where we were in life was always sort of a consolation prize. Even though there were several red flags, we took the job, moved all our stuff and jump in face first to a different life.

The problem – this different life didn’t fit. It didn’t fit in anyway. Just like I used to feel that I didn’t belong in industry, I now felt like I didn’t belong in academics. Only this time, the feeling was much stronger, more more immediate, and much more screaming “you must do something about this!” My new job was not good for me, and not good for my family. The increased working hours, increased stress, and less time with my family, all added up to a big negative that needed to be dealt with.

This year has been devastating to me, my immediate family, and my extended family. We can only hope that this turns out to be the worst thing that happens in our lifetimes. And we faced a series of difficult choices. Stick out what isn’t working, try to find something and salvage the wreckage, or go back to what was working. We chose to go back to what was working.

It took me until the age of 35 to figure out what I wanted to do when I grow up. Unfortunately this discovery had to come in the form of huge life lessons and undue strain on the relationships in our lives. Now I know, and I can move forward knowing that it is a path we chose.

I don’t know if these costs will ever be “worth it.” We have huge piece of mind in knowing that we tried something. We have huge piece of mind knowing that the life we will be living going forward is not a consolation prize, but a choice to do the best we can in the world every day.

One thing for sure – it is time to move on. This life isn’t working, and it is time for one that works.

Just a little bit of insight into what went wrong. We have more to share, but all in good time.

Long Distance Commuting

Thankfully this is going to be temporary, but I’m now scheduled to begin my few weeks of work with some long distance commuting.

Lucky for me, I have been hoarding my frequent flyer miles for years, so each trip will only cost me $7.50 in fees for redeeming the award ticket.

By the numbers. Over a period of 21 days, I am scheduled to be flying 14656 in 10 flights visiting 5 different airports (CVG, ATL, SJC, LAX, SEA).

Lots of in-flight wifi will be purchased and lots of working from planes / airports / etc.

Private? The false assurances of C++

Yet another reason I believe that C++ is the wrong language for teaching introductory programming. Because of the way classes are laid out in memory, it is trivial to show (a good thing), but it is also trivial to access those private member variables directly.

TLDR? – View the gist on github

Let’s break this down. We have a class called Point


The point class in this instance represents a 2D and has the private member variables of x and y.


If we have, say, a local variable (Point p;) we can do some basic calculations. This may be compiler / OS / architecture dependent, but this works in 32-bit linux w/ gcc on i386.


When we run this code, we see that the sizeof(point) is identical to the sizeof(int) + sizeof(int). Since classes in C++ are based on structs in C. This is just a tight packing of the member variables.

And if the base pointer for &p is 0xa43c then we see that the address of x is the same, and y is off by 4 bytes (the size of an int).

Now – if we just try to access the private member variable directly, i.e. p.x = 27; the compiler will detect that we’re trying to do something bad and give us an error (good!).

However, through the magic of memory addresses and pointers we can change that. It is a simple cast. First we get a pointer to our instance of the Point class, and then we re-interpret that as a pointer to an int. From there we can start derferencing and using pointer math.


That’s it. A simple cast and some pointer math and private doesn’t mean anything. Who needs encapsulation anyway?

DRY, Shy and Tell the Other Guy

It has been a little while since I’ve pulled out this article by the pragmatic programmers (Andy Hunt and Dave Thomas), Keep it DRY, Shy, and Tell the Other Guy.

I’m going to use this in the first week of teaching CS 1 students classes (in C++) for the first time. To me, the critical point is the “tell the other guy” part. The way they present it is the more useful of the OO metaphors. It isn’t calling a function on a object to achieve some goal. It is sending a message to some object, with apathy towards the details of how it is done.

I think this is the key to breaking from procedural programming and moving successfully towards object-oriented programming.


The students in my Computer Science 2 class have recently been coding a bowling scoring program. I decided to see what this looked like in Earlang. I spent over two years writing Earlang code (for work, yes I got paid), and really like the language. Now that I have this done, it makes the c++ look long winded and over-complicated with all the conditional checks.