The word astronomy literally means "law of the stars" (or "culture of the stars"), and is derived from the Greek word astronomia, which itself is made up from the Greek words astron, meaning "star," and nomos, meaning "laws" or "cultures."
(Ya just gotta love Google! )
Bob understands. Thank you.
Who cares? The Greeks are bankrupt. The fact is, we laypeople think of astronomy as viewing and enjoying the stuff of the heavens. That works for most of us, except for anal retentive types, I suppose.
Weird that no one addressed the OPs orig question. I'll try!
There are two technologies that often get in the way. One is just good old poor design. We're fortunate to live in a time where competition has run most poor designs into has-beens. We live in a time of great designs and great value. We're pretty lucky that way.
Second is with software and firmware - especially the latter. It's very hard to write good firmware, especially if you're of the mind to break rules, and programmers often break rules, or get lazy. And the result is nightmare upgrades of operating systems, etc.. How many people remember Windows 3.11 and video driver problems? Man was that a nightmare.
So, I say that technology is a problem gets in the way of your enjoyment, when it doesn't work, or is clunky. I have a very low tolerance for lousy software/firmware.
When I was doing lots and lots of mainframe development years ago, I busted my hump to ensure that my code was readable, well documented, modular (functionally cohesive sections/paragraphs/modules), and well structured. I did a lot of assembler, so adding profuse comments (pseudo code, really) on the side was what you did! But I also did much more COBOL over the long run. COBOL is excellent in that, if you write clear, well structured code, your source code will be self-documenting when you're done, and should be easily decipherable by anyone who knows the basic business processes involved, and the rules that accompany them. COBOL, if done a certain way, can leave your code as easy to read as a book, allowing almost anyone to be able to understand what the code is doing!
I loved those days when I mostly did new program, and system development from scratch! However, later in my career I got to spend all of my time "in the barrel," troubleshooting, and maintaining other people's code. Many were the mornings where I just sat staring at someone's source code, shaking my head, and wondering why! Not that I was the best programmer to ever come down the pike, I certainly wasn't! Over the years, I have coded more than my share of time bombs, and stinkers! However, when you see large programs where the entire PROCEDURE DIVISION is made up entirely of one, long, nested "if-then-else" statement, one single endlessly meandering sentence, that goes on for page, after page, after page, having only one, single, lonely little period to end it. Well my friend, welcome to H-E-Double-Hockey Sticks! Pull yourself up a blazing briquet, and have a seat! This could take a while...
I once had a person on a development team that I was leading, who actually prided themselves on being able to do exactly that! They claimed that the CPU was able to process it more efficiently!!
We went round, and round...
Another one I've seen is where people, rather than to try to understand what the code is doing, would just code a PERFORM statement (think "GOSUB") at what they hoped was a harmless point in the logic of the code, causing it to branch to another seemingly complete program that they had coded at the very bottom of the source code listing, RETURNing back to where they branched out when their code was finished, hoping it all worked out correctly! At least with them, you could see what they did, and it was easily contained if you had to make changes. Though, you couldn't always count on them only having added those blocks of code. No, they probably coded other PERFORM statements, sprinkled throughout the existing code, thinking themselves as being awfully clever for having done it in such an obviously structured manner! Of course, they never left a comment, not even a hint, to show what they had done, or why!! Just a terse comment at the top of the listing, briefly stating what they did, and when they did it:
"7/14/84 - Added code, tested it, it ran to EOJ."
("EOJ" means "end-of-job." In other words, the job ended normally without suddenly blowing up, taking half the planet with it! Don't laugh, I was there when a fellow employee once said something very similar to the "big boss" after a job of his blew up in production! The boss just shook his head, and walked away...)
Honestly, I couldn't make this stuff up if I tried!
Another time, we encountered a batch job where someone had made changes to a program without leaving any documentation at all regarding what the change actually was, why it was done, and (most importantly) who had actually made the change! We only caught it by sheer dumb luck when we got a call from the users, complaining that some of their data was suddenly not making sense, and that they had only discovered it by happenstance when something else entirely unrelated had occurred!
After tracking it down to that one job, and realizing that we didn't have a clue as to what had been changed, we immediately went to the backups of the previous versions of both the JCL, and the source code, in an attempt to restore either, or both to their original state. It was only then that it become horrifyingly clear to us that, had we not gone for the backups on that very day, the tapes that contained their code would have rolled off of the backup list that night (aka, the GDG index), and the tapes that contained their data would have probably been written over. Gone!
The data would have been lost for good!!
Oh, before you ask, did I mention that they didn't even have a disaster recovery plan in place at the time? That's why we would've been nailed, because the only possible route we might've had to recover after something like that happening, did not even exist at the time! There was no alternate recovery site (think, another computer center that could pick up, and do our work), there was no true offsite storage facility (think "Iron Mountain") where we could, at least, safely store the backup tapes that were critical to our being able to get back on our feet if disaster ever struck! No. Instead, their "offsite" storage facility for those particular archive tapes, the absolute last hope they would ever have of recovering after a disaster... was a storage closet in the back of the computer room!
I kid you not. You just can't make this stuff up!
And, if I were to tell you the name of the organization to whom all this belonged, you would probably blanch at first, and then afterwards, reluctantly agree that this is pretty much par for the course for many organizations of this type! Even after 911, it took them almost 10 more years to finally get some semblance of a credible disaster recovery plan into place! And they've been "in the business" for nigh unto 40 years!
It's truly amazing that things like this can actually be happening! It leaves one wondering if we may, in fact, all have good reason to be afraid...
To be very afraid!
I'm sorry, I didn't mean to hijack the thread with that. Once I got started, I was on a roll! However, if anything, it does clearly show how technology can get in the way of an otherwise perfectly good time!