En un mensaje anterior, der Mouse escribió: > >>> 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.
Well, my view is that a computer scientist is a scientist, which means he looks into new/open problems. He'd better recall you can't sort faster than O(n log n) based on comparisons, as a phisicist better recall general relativity laws, but it can be a theoretician or an applied one (for example, designing new programming languagues, etc). A software engineer applies stablished methods (if shuch a thing exists today is left as an excercise to the reader) to tackle problems. But that includes desigining, testing and programming. They are just different parts of the software life cicle but all of them should be undertaken as professional grade tasks. So, in short, I think that programming is included in SE is included in CS. Where "A is included B" means that any individual with an B degree should have the knowledge necessary to successfully performs A's dutties (he might not have the experience). I don't agree with David Wheeler's statement that secure coding should be taught instead of more basic things like sorting algorithms. Both are important, but I believe that properly understading foundations is more important that 'don't trust the input'. Of course there's more to security than that, but that leads me to my main point. How should secure coding be taught? I've considered 'secure coding' courses, and the idea allways look kind oversized. How much can you teach that students can't read themselves from a book? Can you fill a semester with that? I'm interested in people's experiences here. Adding a 'security chapter' to existing courses seems more appropiate (at least to me). At the end of our Programming II course, I showcase students the vulnerabilities that can be understood or are related with what they've saw in class: these includes buffer overflows, input validation, integer over/underflows, race conditions, least priviledge, etc. I stress that these are only samples, and point them to links (like David's great 'Secure Programming How-To') and books. I haven't had the chance to evaluate the impact of that, but it is on my to-do list. Similary, some other courses where security can be plugged include operating systems, networking, SE, system's design, etc. I'd be interested to hear what people think of the two approaches (separate security courses vs. spreading security all over the curricula). Regards. Fernando.