By contrast a university professor has spent years contributing to their field. They often possess expertise that you can't find anywhere else. This means that their commitment to teaching may not be 100%-- they'd rather be doing research-- but if you son is smart and talented, and wants to take his education to the next level, being able to work with a professor is a huge advantage. Professors work on interesting new problems. Also, particularly in computer science, professors frequently have contacts in private industry, and they act as conduits to the most desirable jobs. Here's the list of my frequent employers for students in my lab: Microsoft, Google, Facebook, Apple, Amazon, IBM. We're all doing great; we love our jobs, and it's because we went to a research university.
Now, I am most certainly not saying that having a good education and getting a highly-paid, very interesting job is the exclusive domain of universities. Definitely not. I'm not even saying that you can't do it on your own. What I am saying is that you'd be foolish to conclude that they are a waste of your money (my MS and eventual PhD cost me NOTHING out of pocket). Furthermore, if you want to maximize your chances for success, you should seriously consider public universities. The amount you pay for undergrad tuition is worth the debt. The same cannot be said for many other institutions of higher learning.
I don't think your feelings about Windows Server contradict my point: Microsoft is moving into a software-as-a-service model. It shouldn't be surprising that you want to ditch the old model. In many ways, it doesn't matter if you don't use Microsoft handheld devices; if you do things on the Internet, you almost certainly use their cloud services. And if anything can be learned from Apple's example, it's that rapid innovation can happen when you have the capability to vertically integrate. There are really only three players out there right now that can do that: Apple, Google, and Microsoft. I think it would be silly to call any one of those companies irrelevant.
I think your criticism against lock-in is fair, and this is clearly one of Microsoft's strategies, and I suspect that it will continue to be to some degree. But on the language front, you are wrong. Not only are Microsoft's newest languages open-source (F#, TypeScript), but they are also cross-platform and collaboratively developed with open source groups. And, of course, you can run all
While it is theoretically possible that all of this is a deadly Microsoft-bait-and-switch just waiting to happen, having worked at Microsoft, I can say that doing so would fly in the face of a lot of hard work by many, many people there. I was as critical about Microsoft as you were (dig into my
Microsoft is a big company (the Redmond campus is mind-bogglingly huge to me) and they have a lot of corporate momentum. Despite this, in my opinion, I've seen my daily interactions with people do a complete 180 in the last couple of years. Microsoft knows that the era of selling boxed copies of proprietary software is coming to an end. So you're simply wrong about Microsoft not being able to change.
Whatever algorithm Google is using to do this, I think its details are in the public interest. I'd like to see them publish its details.
On the other hand, many properties about programs themselves can and should be verified. A great deal of current programming language research is devoted toward both improving the capabilities of automatic program verification as well as designing languages more amenable to verification. Functional languages, for instance, rule out entire classes of bugs present in imperative languages. People complain that they're hard to understand. Maybe. I argue that they're hard to understand if you're the kind of person who does not care about whether your program is correct or not.
Unless and until some unforeseen, miraculous breakthrough happens in language design, GCd languages will always be slower when it comes to memory management. And because memory management is so critical for complex applications, GCd languages will effectively always be slower, period.
This isn't true. Have a look at Quantifying the Performance of Garbage Collection vs. Explicit Memory Management. The take-away is that GC'd languages are only slower if you are unwilling to pay an extra memory cost; typically 3-4x of your explicitly-managed program. Given that GC gives you safety from null-pointer dereferences for free, I think that's a fair tradeoff for most applications (BTW, you can run the Boehm collector on explicitly-managed code to identify pointer safety issues).