These protocols were designed for a different world:
1) They were experiments with new technology. They had lots of options because no one was sure what would be useful. Newer protocols are simpler because we now know what turned out to be the most useful combination. And the ssh startup isn't that much better than telnet. Do a verbose connection sometime.
2) In those days the world was pretty evenly split between 7-bit ASCII, 8-bit ASCII and EBCDIC, with some even odder stuff thrown in. They naturally wanted to exchange data. These days protocols can assume that the world is all ASCII (or Unicode embedded in ASCII, more or less) full duplex. It's up to the system to convert if it has to. They also didn't have to worry about NAT or firewalls. Everyone sane believed that security was the responsibility of end systems, and firewalls provide only the illusion of security (something that is still true), and that address space issues would be fixed by reving the underlying protocol to have large addresses (which should have been finished 10 years ago).
3) A combination of patents and US export controls prevented using encryption and encryption-based signing right at the point where the key protocols were being designed. The US has ultimately paid a very high price for its patent and export control policies. When you're designing an international network, you can't use protocols that depend upon technologies with the restrictions we had on encryption at that time. It's not like protocol designers didn't realize the problem. There were requirements that all protocols had to implement encryption. But none of them actually did, because no one could come up with approaches that would work in the open-source, international environment of the Internet design process. So the base protocols don't include any authentication. That is bolted on at the application layer, and to this day the only really interoperable approach is passwords in the clear. The one major exception is SSL, and the SSL certificate process is broken*. Fortunately, these days passwords in the clear are normally on top of either SSL or SSH. We're only now starting to secure DNS, and we haven't even started SMTP.
---------------
*How is it broken? Let me count the ways. To start, there are enough sleazy certificate vendors that you don't get any real trust from the scheme. But setting up enterprise cert management is clumsy enough that few people really do it, hence client certs aren't use very often. And because of the combination of cost and clumsiness of issuing real certs, there are so many self-signed certs around the users are used to clicking through cert warnings anyway. Yuck.
The problem with books is that most people learn by doing, and toy problems don't teach you what a real application is like.
I'd suggest picking an open-source project and doing something with it. Depending upon the type of programming you want to do, add something to Linux, OpenOffice, or any of the number of Java-based things. (I'm currently working with the Sakai course management system. There are plenty of things that need doing there.)
The languages aren't any worse than what you're used to. The problem is that real programming these days tends to involve lots of complex libraries and frameworks. Those are hard to learn in the abstract, which is the reason for my advice.
Whether it make sense for someone to (re)enter programming as a job I can't say. That's a decision for you. There are a lot of problems with the profession. But there's also lots of important things that need to be done, and a lot of the people who think they're programmers aren't up to it. Programming approaches are changing often enough that skills go out of date in a few years. That's both good news and bad news for people like you. Since people have to learn new techniques all the time anyway, it's not like you have to relive the whole last 30 years.
The language depends upon what you want to do. Systems software and desktop applications typically use C-based stuff (C++ is probably the best place to start, although Objective C and other things have advantages.) Web applications use Java or
If you're thinking of web-based work, I strongly suggest learning Javascript and at least one major Javascript programming environment (e.g. jquery or one of its competitors). UIs are increasingly moving into Javascript.
In case anyone is interested, I just looked to see what was actually done about Copernicus. No action was taken during his lifetime. During the Galileo affair, motion around the sun was declared to be erroneous and heretical. Thus Copernicus' major work was taken out of circulation for 4 years, until it could be "corrected." 9 or 10 corrections were made, which appear to have been simply inserting the word "hypothetically" or equivalent, on the grounds that it was a hypothesis that hadn't been proven.
Note that I am not defending the actions of the Catholic Church. I just thought people might want to know what they were. The uncorrected version was put on the Index.The "corrected" version was not, so it continued to circulate. The source I looked at (http://hsci.ou.edu/exhibits/exhibit.php?exbgrp=1&exbid=14&exbpg=4) says that there was no official finding that Copernicus was heretical, although it appears that there was a general condemnation of heliocentrism (at least this is how I read a couple of seemingly contradictory statements).
Now and then we've had problems where good support could help. When we moved to Java 1.6 the JVM started crashing. It turned out to be a problem with a Solaris-specific library. At the time, Solaris support included Java, so they gave us a workaround. We also thought we had GC-related issues, where we could have used help. We'd be interested in trying G1, but there are still enough bugs that Sun advised not doing it without support. Hopefully the support people would know more about the status, and could advise whether it is safe.
However we're talking about maybe one service request per year. So the very high priced contract they quoted us didn't make any sense.
I'm assuming (without having used it myself) that
If
What they had better NOT do: treat it like Solaris. You're only allowed to use it in production if you have support, and the only support they sell is a site license which costs $25 * the number of people in your company + the number of users for your application.
I'm not being entirely silly. I have an application for which I would have been willing to pay for Java support. But the only support Sun would sell us (late 2009, when they had already started Oraclizing) was an unreasonably expensive site-wide support contract.
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?