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
