der Mouse wrote:
That's an interesting distinction, but it doesn't really map to reality. There are lots of academic computer scientists who actually study implementation issues. Me, for instance :) We publish in security at USENIX Security, NDSS (Network and Distributed Systems Security, I am on the PC for 2005 <http://www.isoc.org/isoc/conferences/ndss/05/cfp.shtml>), more broadly for systems at USENIX (plug: I am on the Freenix program committee for 2005 <http://www.usenix.org/events/usenix05/cfp/freenix.html>), OSDI, SOSP, etc.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).
Even more broadly, people publishing stuff at SIGGRAPH are often doing at least as much with implementation as algorithms.
Another perspective (overheard at a conference 12 years ago):
* Scientists build stuff in order to learn stuff. * Engineers learn stuff in order to build stuff.
So both classes learn stuff and build stuff, but for different motives. As a result, the output of scientists is often informative, but not so often useful, and the output from engineers is often useful, but not so often informative. To the contrary, it is rather poor work if a scientists work is not informative, and disastrous if an engineer's work is informative (e.g. the Tacoma Narrows bridge, or Microsoft Windows :)
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.
Agreed.
What this means for acamdeia is less clear. In particular, most CS and... however, the programming skills that universities teach is usually a side-effect of something else they are teaching: topics like algorithms, graphics, database, operating systems, networking, etc. They teach you the topic, give you a development project in that topic, and expect you to pick up the programming skills along the way.
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).
This effect is more pronounced the more advanced the school is. The thought is that programming is a relatively simple topic, so while a community college will spend most of their time teaching programming, a top-tier university will spend about 2 weeks teaching the frosh to program, and the rest of it they are supposed to gather while studying actual computer science.
What is broken about all this is security: the above approach teaches the kiddies to implement software anyway they can, under a lot of time pressure, and with very little QA pressure: graders have no time to rigorously test assignment hand-ins, and certainly not time to pen-test them.
Bringing us back to the root of this thread: we have been waiting forever for security to make it into the basic CS curricula. The rate of progress is not encouraging.
Thus, to really separate the programs, you'd have to pull theFor that to work, there would have to be programming content in curricula to pull out :) OTOH, on reflection I tend to agree that unless "how to program *safely*" is a subject, that you cannot expect kids to infer it, and so successfully teaching security
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
-- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
