Gas station without pumps

2012 May 17

Embedded programming gap

Filed under: Uncategorized — gasstationwithoutpumps @ 20:30
Tags: , , , , , , , ,

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).



  1. I don’t know who can take the credit (or blame) at the CS department at Univ. of Copenhagen, but our introductory course uses Standard ML (a functional programming language like Haskell). I think the reason is two-fold.

    First, my guess is that the reasoning was similar to Dijkstras: “Right from the beginning and all through the course, we stress that the programmer’s task is not just to write down a program, but that his main task is to give a formal proof that the program he proposes meets the equally formal functional specification” []. This goal is much easier met using a functional language than an imperative language where the state of a program can change and responsibility is harder to place.

    Second, about half the students starting at CS have never tried programming before. To ‘even out the playing field’ we teach a language that no student has ever seen before.

    Personally I think it works quite well. It is of course frustrating for some freshmen students (I’m guessing mostly to those who are intimate with some imperative programming language in advance), however it emphasizes the role of the computer scientist, not as an engineer who needs a large practical toolbox, but as a computational mathematician who must think about proofs of correctness and time- and space-complexity.

    Our second course teaches Java and after that students are basically expected to master any programming language without formal training (which is interesting for some, but hard for others). I wish we were forced to use Python at some point, but I guess Ill have to find my own motivation for learning it.

    Comment by Rasmus — 2012 May 18 @ 00:08 | Reply

    • I didn’t learn Python until “encouraged” to teach it in place of Perl to bioinformatics students. I had always hated the ugliness of Perl, teaching it only because it was the de facto standard for bioinformatics glue programs.

      Once I was convinced that Python had gotten enough traction in the bioinformatics community, I learned enough Python in about 2 weeks to teach it, and it has become my main programming language (supplanting C++). I’ll probably have to switch back to C++ if I write a tool that needs higher speed or better memory efficiency, but for most of what I’ve been doing for the past couple of years, Python has been adequately fast and I’ve only occasionally needed memory management tricks (like using typed NumPy arrays instead of Python lists) to deal with Python’s rather inefficient memory management.

      Doing functional programming first is an approach that I think works well for mathematical computer scientists and algorithm analysis, but not so well for embedded-system engineers.

      Comment by gasstationwithoutpumps — 2012 May 18 @ 08:24 | Reply

  2. Most CS programs have a software engineering course in which a group project is required. Many have a yearlong capstone project requirement as well. I teach the software engineering course at my school, and boy, do my students learn about working in a group!

    Comment by Bonnie — 2012 May 18 @ 10:45 | Reply

  3. I don’t know Python so I don’t know if it works like PHP or not. But I had my software engineering students use PHP for the first time ever, largely because of our client’s requirements, and found it to be a horrific language for shaky programmers, largely because of its lack of type declarations and lack of compile-time checking. The students could not do simple things like look at a function and understand what type was being returned, without wading through the implementation of the function. This leading to constant errors in which they wrote code expecting the wrong kinds of structures. And of course, because of the lack of compile time checks, these errors were often very frustrating and time consuming to find. Students wasted hours and hours over the course of the semester stamping out bugs that would never have happened if functions had return types and typed parameters. I could not imagine trying to use a language like that with novices. I always tell my students “The compiler is your friend. It keeps you from doing Bad Things”.

    Back in March, in total depths of despair over the difficulties my students were having because of PHP, I posted this on Google+

    Oh PHP, let me count the ways in which I hate thee…
    I hate the way that variables change type when I least expect it.
    I hate the fact that functions do not have return types so I have to sift through the code to see if anything is returned or not.
    I hate the fact that it is interpreted rather than compiled, so that simple mistakes that any decent compiler would pick up instead turn into impossible to debug runtime errors.
    I hate the way that people mix HTML, logic, and database calls together into one big unreadable glop.
    I hate the fact that when I look at a PHP program, I cannot discern any organization or structure.
    I hate dollar signs in front of variable names.
    I hate the silly constructors in pseudo-object-oriented PHP.
    I hate the heredoc syntax, the fact that the closing identifier must be on the first character of the line, and the fact that a construct called something as silly as “heredoc” even exists.

    Comment by Bonnie — 2012 May 18 @ 10:53 | Reply

    • One of our professors were asked: “Why not use python in your courses? It gives you such great freedom”.

      To which he replied: “Sure, freedom to shoot yourself in the foot and the head at the same time”.

      I dont think python or php are bad per se, but while learning programming (particularly before students had machine architecture), strongly typed languages help greatly in understanding what is going on.

      Comment by Rasmus — 2012 May 19 @ 02:19 | Reply

      • Python is strongly typed, but not statically typed. (Objects have types, but variables can hold any object.)

        Compile-time type checking is a valuable asset for large, complex programs—particularly ones written by multiple programmers.
        The machinery needed to set up programs for compile-time type checking is a distraction from the main concepts for beginning programmers and is usually not needed in the small programs that students write.

        The main problem I see with Python as a teaching language is not the lack of static typing, but the inability of Python interpreters and compilers to detect typing errors in variable names.

        Comment by gasstationwithoutpumps — 2012 May 19 @ 10:23 | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a free website or blog at

%d bloggers like this: