Embedded programming gap

It seems that there is a shortage of programmers who can do embedded systems (which is what computer engineering is mostly about these days).

Critics lay much of the blame for the embedded programming gap at the doorstep of university computer science departments that have tended to migrate curricula toward trendy programming languages like Java at the expense of unglamorous tasks such as how to design and analyze algorithms and data structures.
Struggle continues to plug embedded programming gap | EE Times (by George Leopold)

I’m not so sure that Java is at fault here. It seems to me to be perfectly fine second programming language (after a simpler one like Python that does not require all data structures to be declared before any code is written).  The problem is more that the instruction focuses entirely on designing huge complex data structures and using large libraries of complex software components, rather than on fundamentals:

The problems start early in the curriculum. Too often an introductory Computer Science course will fall into one of two extremes: either focusing on the syntactic details of the programming language that is being used—“where the semicolons go”—or else treating programming as a matter of choosing components and plugging them into a GUI.

The basics—how to design and analyze algorithms and data structures—are covered summarily if at all. Software methodologies such as Object Orientation that are best approached in the context of the development life cycle for large applications, are introduced through trivial examples before their benefits can be appreciated: the proverbial cannon that is used to shoot a fly.

The education of embedded systems software engineers: failures and fixes | EE Times (by Robert Dewar)

I’m not so sure that I believe in Robert Dewar’s proposed solution, though, as he suggests having students do more high-level design (software architecture, rather than nuts-and-bolts programming), which is in direct opposition to his claim that students should be getting more training in low-level languages like C.

Robert Dewar also makes an argument for group work at the university level—something that is common in computer engineering programs, but apparently rare in computer science programs.  At UCSC, I know that all computer engineers, electrical engineers, and game design majors are expected to do group senior projects, and some of their other classes (such as mechatronics) are also group projects.

I think that the lack of group projects in many CS courses is not so much tied to Dewar’s idea “a perhaps regrettable staple of the educational process is the need to assess a student’s progress through a grade, and a team project makes this difficult” as it is to the problem of scale—a group project is only reasonable when the project is too big to be done more efficiently by a single person.  Creating and managing such big projects in lower-level classes would be a major undertaking, particularly in the short time frame of a quarter or semester, when a lot of things other than group dynamics need to be learned. Pasting a group structure onto tiny project would make things worse, not better, in terms of training students to be effective in groups (see Group work).

Some entrepreneurs have addressed the problem by starting up “initiatives like Barr’s week-long, hands-on Embedded Software Boot Camp.”  The idea is to take programmers who already have degrees and supposedly know C and train them specifically in the skills needed to do real-time programming. The cost is not small ($3000 for 4.5 days, if you register early).

Some computer scientists have been pointing out problems in the standard CS curriculum for a while:

I started saying this over a decade ago. I even did embedded stuff in my 3rd year data architecture course—my department was uninterested, and the students had a real hard time wrapping their heads around the thought that there are places where resources are limited.

The department fought me when I said that students needed to learn more than one language (Java). The department disagreed when I said that students should learn how to program for environments where bloated OO methods might not work (… But, the ARE no places where efficiency matters!!! It’s all about “Software Engineering”!).

The students had NO idea what it meant to program for a machine that had no disk, only memory.

Part of the reason CS departments are seen as being so out of touch is BECAUSE THEY ARE!!!

University should not be about job training, BUT it is also NOT about teaching only those things the faculty find interesting.

Struggle continues to plug embedded programming gap | The Becker Blog.

I know that there have been struggles between the computer science and computer engineering departments at UCSC about what programming language to teach first, with the computer scientists arguing for Java and the computer engineers arguing for C and assembly language.  Eventually they reached a compromise (which has been stable for about a decade), with the computer science students taught Java first and the computer engineering students taught C first, then both making transitions to the other language.

I think that both approaches work, but the strengths of the resulting programmers are somewhat different.  For device drivers and small embedded systems, I’d bet on the computer engineers, who have a better grasp of low-level details, interrupts, and hardware/software interactions.  For more complicated projects, I’d want one of the computer scientists doing the high-level programming, teamed with computer engineers to do the detail work.

I actually don’t like either C or Java as a first programming language.  I think that students would be better off starting with Scratch, which gets them quickly into multi-threaded code, real time operation, and race conditions, without burdening them with a lot of syntax.  Then they can switch to Python to learn about code syntax, types, and objects, without the burden (or support) of compile-time type checking.  After that they can switch to Java to learn about declaring all their data structures and having very rigid type rules (useful for bigger projects to make interfaces between different design groups more explicit).  In parallel with learning Python and Java, they should learn C and C++ in the context of the Arduino microprocessor (or similar small microprocessor) to control real-time physical systems.

The computer engineers could even skip Java, and learn their rigid type systems strictly in C++ (which they are more likely to use later), though Java is cleaner and makes the learning somewhat easier.

Computer scientists should not stop with this handful of languages, though, as they are essentially all Algol derivatives.  The CS students should also learn a couple of languages that come from different lineages (LISP or Haskell, for example).

Object-oriented programming

In the comments on Mark Guzdial’s blog Computing Education, Alan Kay occasionally grouses about the abuse of the term “object-oriented programming”. Alan has some justification for this, as he originated the term sometime around the time he put out Smalltalk in 1972.  (Sorry, I’ve not been able to find the first use in print of “object-oriented programming”.  You’d think that Google Books would be helpful there, but their year information is so full of data-entry errors that it is hopeless.)

Alan is quoted in Go To: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Maverick Scientists and Iconoclasts—The Programmers Who Created the Software Revolution by Steve Lohr as saying that Smalltalk is “still the only real object-oriented language.” (That was a decade ago, so he may have changed his mind since then, or some new language may meet his criteria.)  I’m not quite sure what his criteria are, but Simula, Java, and C++ do not meet it.  I can easily see his point about Java and C++, as the objects there are rather limited in what they represent, and polymorphism is very limited indeed.

Alan Kay had a guest post on Mark Guzdial’s blog: Alan Kay on Moti’s “Objects Ever?” CACM Article where he described “real OOP” as “encapsulated modules all the way down with pure messaging”.  I’m not sure what he means by “pure messaging” and “all the way down”—at some point you have to get to the machine’s language, which is going to involve manipulating the state of registers or words in memory. The “message” abstraction is a handy one for polymorphism, though one that carries a fair amount of overhead if used in a purist way without being optimized out by compilers.

I think that Python may come closer than most languages in common use to what Alan means by an object-oriented language, though it is certainly possible (even common) to program in Python in a purely procedural way and to assign state from outside the object (something that Alan Kay regards as “abstract data types” and not “object oriented programming”).  I do a fair amount of programming in Python, and I appreciate the polymorphism of sequences and containers, but I don’t often create new objects myself, generally finding it easier to have a handful of procedures using existing objects.

Bjarne Stroustrup, who developed C++, wrote a paper in 1995 on what object orientation is and what programming styles C++ supports: Why C++ is not just an Object Oriented Programming Language.  He had very different ideas from Alan Kay’s.  Both see run-time polymorphism as important (though to my mind, that is very awkward in C++), but Bjarne also includes abstraction (which I think Alan would agree with) and inheritance (which Alan emphatically does not consider important for object orientation, and deliberately left out of Smalltalk).

Stroustrup also wanted C++ to usable for other programming styles, as indeed it mostly is.  C++ is used as programming language for tiny microcontrollers, where many of the operations are twiddling bits on hardware interfaces.  The popular Arduino microcrontroller boards use C++ as the main programming language, though the computers have only 2k bytes of RAM and 32k bytes of flash memory for programs (and that’s twice what they had a couple of years ago).  To make compiled code small and fast, a lot of the run-time flexibility has to optimized out by the compiler, which requires a lot of declaration of types by the programmer—anathema to Alan Kay’s notion of object-oriented programming. What works well on the tiny microcontroller is abstraction and (sometimes) inheritance, but not run-time polymorphism.  This is indeed how most C++ programmers use the language, even for big projects on bigger computers.I’ve programmed in C++ as my main programming language almost as long as the language has existed (I spent a summer at Bell Labs in Al Aho’s group when Bjarne was developing C++), and I almost never use run-time polymorphism in C++.  So C++ has become popular because it is optimized for non-object-oriented programming, while allowing fairly decent abstract data types.