Advertisement
Guest User

Untitled

a guest
Oct 20th, 2016
67
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.52 KB | None | 0 0
  1.  
  2. Imagine each file in your code is a signal tower, and the towers send messages to each other to run the program.
  3. In a normal program, you run wires between any towers that need to talk to each other, and they send messages along those. Each wire is labeled with the kind of message that goes through it. This means that if you want to see exactly how two towers are talking to each other, all you need to do is look at the wires that run between them and read their labels. The problem with this is, if you’re going to be changing your program a lot, you’ll constantly be taking down wires and stringing up new ones, which is a lot of work. Most programs don’t change too often, so that’s not usually a problem. Websites, though, change constantly, so this becomes a major pain for the developers. So instead, the towers in web programs talk to each other using signal flags. Each tower has a copy of a book that tells them what flags to use, which is great because when you want to make a big change, all you need to do is mail the towers a new copy of the book instead of mucking about with a crane lift and a bunch of cables. BUT, if you’re not the one who wrote the book and you’re trying to figure out how 2 towers in particular talk to each other (which is mostly what you do when you start out after joining an existing project), you can’t just look at the wires, you either have to sit there staring at the towers while they’re doing their thing and keep track of what flags they use, or try to read this huge-ass book that has all the instructions for every tower in the entire country listed in pretty much random order.
  4. On top of that, for reasons I’m not going to include in this analogy, each of your tower operators only speaks one language, and most of them are different. Some speak English, some Spanish, some Chinese, some French, some Swedish and so on. In a regular program, all the signals that a tower receives come straight from the towers that are sending them, and each one has to be translated from the language it arrives in into the one that the tower operator speaks. Web developers, though, said screw that, and they set up one tower that specializes in translating exactly one language to another. So if a signal is sent in English and needs to go to a tower that speaks Swedish, it goes to the English-to-French tower, then the French-to-Chinese tower, then the Chinese-to-Russian tower, and finally to the Russian-to-Swedish tower. This makes everything nicely organized on the large scale and lets each operator get really good at translating between just two languages, so it’s more efficient. BUT, it means that if you’re trying to figure out what’s going on between two towers, not only do you have to worry about figuring out the flags but the message might go through 3 or 4 towers in between, and you have to trace it along that path the whole way, deciphering the signals as you go. On top of THAT, instead of just one person (the user) waiting at one end tower for their message, you’ve got hundreds or thousands or millions of people waiting at dozens of different towers, and you don’t want any of them to wait longer than they have to just because somebody else’s message is really complicated. So, when you’re adding new flag instructions to the book you have to write all these super complicated extra instructions about what to do while they’re waiting for the message they’re expecting from another tower, so that the whole thing doesn’t get bogged down. And that is why web dev is frustrating for a new developer.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement