I think it could make a difference. As a long time hacker (and BS/MS of CS degree holder), I think there are tremendous academic/"real world" disconnects betwe

I think it could make a difference. As a long time hacker (and BS/MS of CS degree holder), I think there are tremendous academic/"real world" disconnects between understanding the paradigms of programming languages, choosing appropriate implementation languages for projects, and the fact that programming language is often chosen for you (because of platform reasons or "popularity" in the SW engineering labor pool, e.g. Java, C#, or others because of management perceptions of skillset availability in the programmer market). Heck, I struggle getting my group to allow us to write new software instead of using unsatisfactory existing frameworks and solutions. Forget about pushing the envelop by saying something crazy, like maybe Ruby/Sinatra would be a good choice for this CRUD app . . . I suspect, but cannot prove, that a proper programming languages class would improve a hacker's ability to know and choose the right tool to attack a problem. My own experience with, of all things, SQL, has led me to be much more productive/effective in producing software that works when measured against lines of code written. But frankly, I think that it is going to be hard to get the kind of deep exposure you need in a different programming paradigm in a one semester course as an undergrad to make much difference here - it was only after spending months of time in the deeper pool of db programming, that I wrapped my head around actually thinking differently about problems. The simpler truth is that there seem to be a number of bright programmers who can write the vast majority of standard corporate software with a less than optimal language/platform choice. Sure, maybe it would have been faster or more expressive to have used J to solve a particular problem, but if somebody hacked the solution out in C#, the end-users of the software don't care at all. I think you are correct that most of the academic world vastly overestimates how much choice is available at most software shops to chose the "right tool for the problem." I do like the CTM book by Peter Van Roy mentioned in the article very much - it is not a book that I used as an undergrad or grad student, but I have been skimming it and like very much how it is laid out and has a single language/env where it implements different programming paradigms. What I wish I was personally better at would be having a small set of languages, easily available and justifiable to non-technical decision makers that I knew would make my team more productive. Sort of a "problem patterns" knowledge that you would automatically think "aha, language X is often used for this type of problem space" that was taught. But you'd need someone in a programming languages course with a deeper exposure to industry computing to pull it off as an instructor . . . But I think the key benefit might simply be breaking the hacker's mind from thinking OO and procedural only . . . if people don't learn functional and declarative programming, how can they begin to fathom the situations where it's exactly the right way to conceptualize a solution?