[jimwise]

I'm not sure I agree -- it's my experience that too often `practical concerns' become an excuse to teach faddish details of what is being done in the `real world' now, instead of provide any sense of the parts of the field which don't change with each new technology.

I'd rather teach a new hire who had worked through a curriculum built around SICP[1] or HtDP[2] the languages and technologies we actually use here -- even though we never write a line of scheme -- then teach a student who got a four year `Computer Science' education focused on the details of a particular programming language or technology stack how to use that very stack to accomplish lasting things...

[1] http://mitpress.mit.edu/sicp/

[2] http://www.htdp.org/

[onan_barbarian]

This is a false dichotomy. I would rather a student who had gotten a coherent CS education in some random Algol-descended language who had worked on a curriculum consisting of a great big chunk of algorithms, systems work (os, compilers, networks) and architecture.

I am finding many "high-church-of-X" approaches to CS increasingly unsatisfying, whether it's rabid OO, the rabid 'functional programming solves all problems', Stephanov's 'grind away for 6-12 months putting the basics on a RIGOROUS FOUNDATION without solving a single interesting problem' book, etc...

My feeling is that many of these religious attitudes will not survive the first contact with a truly serious enemy - in other words, a system with substantial complexity that can't be expressed in an elegant way. I don't think it's a mistake that strong FP guys spend so much time hacking around on compilers, type systems, regular expressions, etc. Maybe a foray into scientific computing - but if you're biting off problems that were previously tackled by a bunch of nested loops in HPF, maybe these aren't the world's most hairy algorithms either.