Place the two languages chosen for COGS 8, Python and NQC, in the spectrum of such alternatives as StageCast and NetLogo. What language(s) would you choose for this audience and this classes' purposes? Why?
To start my discussion, I want to dismiss StageCast and NetLogo as good alternatives for a programming language for this course.
StageCast is a compelling alternative as an introduction to an abstract notion of programming and computing. The irresistible appeal as an aid to introducing these abstract concepts is that StageCast itself is completely non-abstract. That is, students see very concretely the effects of their programs in the actions of the objects in the visual environment. Another benefit of StageCast that should not to be underestimated, is the level of student interest and fun that the graphics and game qualities provide. If one goal of the course is to provide outreach to students who would not normally consider studying computer science, nontraditional approaches are needed to break out of the existing computer science cultural mold.
However, the scope of StageCast's utility is so limited, that it simply does not qualify as a practical programming skill to acquire in itself. Given an assumption that such a practical programming skill will be learned at a later date (e.g. if StageCast is used in K-12 level education or in the beginning of a longer series of courses), then it has great potential to prepare students for that future occasion. However, in our course it would replace, not foreshadow, the acquisition of an actual practical programming skill, and is therefore not acceptable.
NetLogo is an interesting system that allows novices to rapidly achieve the ability to explore experiments in group dynamics. NetLogo takes some steps towards being a practical programming language; it has a much more traditional language interface than StageCast. But this surface similarity must not distract from the fact that it too has a limited scope of applicability in the world. If the goal of our course were to explore group dynamics, NetLogo's contribution to making a programming approach to the problem accessible to students would be ideal. But again, its limited scope makes it inappropriate for our goals.
It is painful to dismiss StageCast and NetLogo so quickly, since they have such appealing qualities. The following is a bit of an impromptu analogy, but perhaps it will help clarify my stance on the critical difference between the abstract and the practical when it comes to programming. When US weapons inspector David Kay reported finding "dozens of weapons of mass destruction-related program activities" in Iraq, it was decidedly not up to the claims that actual functioning, deployable weapons were going to be found. Of course when considered on its face, the existence of these "dozens of...activities" is quite alarming and the future threat posed is quite serious. But considered in context, an undeniable fundamental difference exists between these "related activities" and a physical, operational weapon. Similarly, StageCast and NetLogo seem to me to be "programming-related program activities," whereas what we are looking for in this course is real, operational programming skill.
Unforunately, NQC, a programming language chosen for use in COGS 8, may seem to fall victim to the same line of reasoning that killed StageCast and NetLogo. Although, as suggested by the name, NQC shares syntax with C, it clearly has a limited applicability--LEGO mindstorms. Also, let us assume for now (and will be justified in detail later) that C is not a good teaching language either. Therefore a language other than NQC/C will need to be taught in the course, as is in fact planned for the coming quarter of COGS 8. Then I think the use of NQC in this course cannot be philosophically justified. However much we may want to excuse ourselves, it is clear that asking the students to interrupt their learning of the Python language, to do a series of assignments in NQC, is a distraction.
Note however, that what should be done in the coming quarter, given the reality of logistical constraints, is a different question. The use of robots is a compelling teaching device that in this case, and for only part of the quarter, I think justifiably supercedes the language consideration.
At the far end of the spectrum from StageCast and NetLogo is C and C++. Even further still are assembly language and even binary programmming. First, let us consider assembly and binary programming. At first it may seem ludicrous to even consdier them, but some have seriously argued for their use in introductory courses. A textbook, Programming From The Ground Up that introduces Computer Science using Linux x86 assembly language has been developed. Donald Knuth continues to believe in assembly language, using it in his Art of Computer Programming series (although it is difficult to argue that an appropriate audience of these books is a beginner, non-Computer-Science student). (He acknowledges skepticism regarding this decision, saying "Many readers are no doubt thinking, Why does Knuth replace MIX by another machine instead of just sticking to a high-level programming language? Hardly anybody uses assemblers these days.")
The genius of Donald Knuth notwithstanding, assembly is not the right choice for our audience and goals. While assembly doesn't suffer from the narrow applicability problem of StageCast and NetLogo in terms of the range of things that can be accopmlished in the language, it still fails to meet the goal of giving our students a practical programming skill. Students simply cannot write their own useful programs in assembly, for the same reasons that professional programmers don't work in assembly--it woud take too long. This argument says nothing about the utility of assembly language as a pedagogical tool. In fact, in the same way that a system like StageCraft can excel in teaching students about the abstract conceptual process of programming, I believe working in assembly has certain cognitive benefits. But again, in the absence of an expected future education in a more practical language, assembly becomes less attractive.
Without repeating the argument against assembly in too much detail, I will also apply it to C and C++. Again, their practical application in terms of a range of uses is clear. But they are quickly becoming the assembly language of our day. Bogged down with too many low-level details, students will never be able to achieve a meaningful level of skill and accomplishment in just one quarter. More justification of this argument is found in my previous writings for this course, and it will be more clear as the constrast to more ideal languages is discussed below.
I propose that our non-CS programming course, and even CS programming courses, need to follow in the revolution that has taken place in the programming arena itself. More and more serious applications are being written in high level languages, such as Java and Python, whose accessible high-level style previously may have been looked down upon as too easy.
But the ease with which very ambitous goals are achievable in modern languages has been compelling the community to take them seriously. Advances in virtual machine and compiler technology have also removed previous barriers such as complaints about poor performance. Even those who still work in C and C++ are invariably transforming them into something resembling languages like Java and python by using STL libraries, for example declaring "stl::string" instead of "char*".
I put Java and Python both in this category of modern languages, although Java is in some ways closer to C++ than Python. For this reason, I believe Python is the right language for this course, since our students have only one quarter and will need a language that maximizes the speed at which they can reach a functioning skill level. For a heavy Computer Science majors course, Java might be prefered, although Python would be a legitimate choice there as well.
By virtue of their acceptance in the community for commercial-grade applications, and the ease of accessiblity to beginners, languages like Python are outstanding in meeting our criteria of providing students, in one quarter, a useful practical programming skill. But what about some of the cognitive acrobatics benefits of using assembly, or the fun and visual interest of StageCast (or the robotics angle of NQC)? Must we just accept that compromises must be made in some areas?
An argument for the cognitive challenge of programming in a language like Python is found here. In summary, the process of using the extensive libraries available in a language like Python is far from dumbed-down. It involves careful planning and thoughtful debugging.
For excitement, Python offers the ability to implement just as visually interesting graphics as StageCast, albeit with a little effort from the instructor. It seems that StageCast may be solving a problem that is over time solving itself. It was created as a response to the difficulty and lack of visual excitement for students approaching a language like C/C++. But with Java and Python, similar results can be achieved, but in the context of a non-specialized language platform. A perfect example is Paul Kube's "Snack Time" assignment, that allows students, by writing one very simple Java routine, to create complex competitive behaviors in a GUI-based virtual bot game.
Educators no longer need to select between the far ends of the language spectrum, represented by StageCast on one side and C/C++/assembly on the other. The benefits of former are accessiblity and student engagement, and the latter allows for students to be acquiring and practicing a skill that has value outside of the assignemnt. But each has significant failings, namely a complete lack of the advantages of the opposite end. Today, languages like Python, situated in the middle but with the benefits of both, are a perfect choice for introductory programming courses. Courses taught in these languages will be beneficial and attractive to Computer Science majors and non-majors alike.