>>> I think over the past 40 years or so, as a discipline, we've failed >>> rather miserably at teaching programming, period. >> Right. But on the other hand, that's not surprising - [because >> we've mostly not even _tried_ to teach programming, as opposed to >> computer science or software engineering]. > Care to explain what do you think a 'programming course' should have > that is not covered in SE or CS courses (or curricula)?
A computer scientist is a theoretician. A software engineer is a designer. A programmer is an implementer. A computer scientist can prove you can't, in general, sort faster than O(n log n) (and a good one can recast this as an explanatino of why). A software engineer can look at the application and decide which sorting algorithm is approproate for _this_ task, including, perhaps, choosing one with O(n^2) worst-case behaviour because of some application-specific property. A programmer can sit down and implement a sorting algorithm. There is a good deal of overlap, of course; it's rare to find anyone who is wholly one of these without any bleedover from the others. In particular, any really good person in any of the three fields is going to have a good deal of skill/knowledge from the other two mixed in. What this means for acamdeia is less clear. In particular, most CS and SE programs actually include a good deal of programming, partly because that's what many of the students actually want, partly for historical reasons, and partly because you do need some familiarity with programming to be a good CS or SE (just as you need some CS/SE to be a good programmer). Thus, to really separate the programs, you'd have to pull the programming out of the CS and SE curricula and put them in a programming curriculum, perhaps with some new material added. I'd actually argue for going the other way, though, since the lines between the areas are actually rather artificial, drawn not so much because there really are boundaries there as because humans like to draw boundaries around things. What this has to do with _secure_ coding...well, nothing, directly. But part of teaching programming really ought to be teaching the security side of it, and whether you call it CS or SE or programming, that's something I agree academia has mostly failed at. Security for CS includes things like a bit of cryptography, some of the mutant complexity theory that considers a problem that's O(1) 99% of the time O(n^n) the other 1% easy rather than hard; security for SE includes things like writing interface contracts that specify what _isn't_ defined as well as what _is_; security for programmers includes things like not overrunning buffers. Again, there's a lot of overlap. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
