I think we really need to separate the two aspects of CS education. Universities should not be job training centers and vice versa. We already have bootcamps, etc. which provide very practical training. I'm pretty sure that CS is the only field with complaints about not being practical enough. Mathematics, physics, medicine, etc. all manage to get along fine.
Being “job ready” (whatever that means) is a side-effect and a byproduct of a university education, not the end. The telos is to teach you how to learn and think well. In this regard Racket is almost as good as you can get. (I’d personally rank the Shplait language (new; implemented in Racket/Rhombus) as best for teaching.)
Anyone who learns Racket will have learned ways of deconstructing problems that will make them far superior in problem solving to those who learn only e.g. Java and only know how to do things the OO™ way.
When a Harvard dropout writes a small system in PHP, and needs to call in the big guns to try to unfuck the situation [1], who should he call? Someone who got really good at jQuery at university?
Besides, aren't modern mainstream languages bragging about having nothing to learn? Learn go in just a couple of days, etc.?
I will say that the credential was a big part of why I studied CS in my 30s. I learned a number of languages along the way.
At this point, nearly all the code I write is in JScript, Pl/SQL, Python, and T-SQL. I learned none of these while in school: Javascript was not yet invented when I was getting the degree.
I will say that SNOBOL, of all odd languages, was useful to me after school in learning Perl.
There have been dozens or hundreds of things called "remote method" or "remote procedure" or "remote function" invocation. However, not a single one of them has overcome the fundamental problem that you can not have something that is semantically identical to the function call presented by programming languages, because programming language functions simply do not have the concept that you are accessing it over a network, and they take heavy and critical advantage of the resulting simplifications.
Someone more clever than wise may stand up and point out that technically even a local function call is unreliable in many of the same ways that a network call is. However, even if many of the same problems can theoretically arise, the distribution of the problems are fundamentally different, which is why you do not guard every single function call in your program for all the network-type errors, and it generally works, whereas if you program that way in a networked environment, it generally does not work.
Personally I've come to prefer messages very strongly to "RPC" as the foundation of a system. Messages can trivially implement an RPC-like system, but RPCs can not implement a message-like system. Even if you implement an RPC called "SendMessage", you're still adding synchronization on the RPC system sending over the call and waiting for the response. Among other things, but that's the big one.
It’s impossible to make RMI behave exactly like local method invocation. It introduces many error cases and performance challenges you don’t normally have to consider.
