Sure. CS students are still not getting introduced to FORTRAN even though over 90% of all production supercomputer code uses it. Again I don't program it, but I accept that modern Fortran is not a terrible language - because I looked at it and know a bit about it (I'm not too snooty to do so).  So modern FORTRAN courses are now taught in science departments and passed from professor to student (and it paid my salary as long as I made systems that ran it well).  My 30 yr CS major daughter, who has been at Google for a few years, never saw FORTRAN (or Snobol - much less awk/sed) in her comparative languages course. I think that's a sin.   She's fluent in Python and Java - as well as a ton of tools for 'cloud development and deployment.'  Clearly these are valuable skills and the way a lot of modern programs are deployed.   She can work with C++ and Go (and I think Rust) and saw a dialect of LISP (racket) in her comparative languages course. In her university time, they taught they all about regular expressions and made her and her classmates all use grep/awk/sed in her original algorithms course years ago.

The important thing is not to reject something just because it is old and jump to something because it's new.   I find the current class-library/frameworks cruft as bad (and not a lot different from) the 'access methods' that IBM created in the 1960s, and Multics and UNIX boldly rejected with all the worlds a 'segment' or later file.

This is the importance of teaching and exposing students to ideas (good and bad) from the past so as not to repeat them. BTW: just because an idea failed previously does not mean it will not work later or that such an idea is a good or bad one now.  This is why experience is so important - for a >>great read<< Peter Novigs  Teach Yourself Programming in Ten Years

I often refer to this as picking up 'good taste.'   I agree with Arnold that learning an IDE often seems like you are losing the ability to have a foundation.   I've pointed out reading >>and doing the exercises<< in Rob and Brian's excellent text: The Unix Programming Environment really should be part of all young programmers' experience (even learning to use a document compiler like the runoff family. Once you master ed, regular expressions and the like make you a better programmer.        I'm not saying you must be fluent/use vi or emacs as your primary editor to be a great programmer. Still, I would place a large bet that the best programmers all know how to use at least one of those tools - and I'll also bet that they all could use a QED-derived line editor if that is what was available.

The key to the UNIX philosophy is teaching to think vs. spoon-feeding a current answer.

Sometimes, the latter has its place (I use many GUI-based applications on my mac), but I always have several 'iterm2' windows open with a shell prompt. The problem is that when the former is all you know, your only real experience, I think people that have a wider field of view and a more open mind are going to understand that your experience is quite limited and thus the ability to judge the good/bad-ness of a something might be a tad suspect.

Curmudgeon-ly yours,

Clem