IO
I was never too interested in I/O operations as a programmer. Reading user input and printing things to the screen seemed boring when I first started, and dealing with String buffers for network I/O was similarly unappealing. But the reason I found it tedious was because I was thinking about it the wrong way.
Input
Input is everything. Input drives not only every function but the entire purpose for the software in the first place. The need for computing has always been to quickly process large amounts of calculations. Where math deals with problems such as "solve for x when y equals 0", computing deals with problems such as "list all possible values for y for all values of x between 0 and three million." The similarity the two share is the importance of the input. In the example before, "all values of x between 0 and three million" would be the input, and the output would be all the values of y.
Software solutions require different inputs, but understanding the input can help reduce a problem's complexity. For example, I work on a product that generates tens of thousands of rows of information based on a store's location. As complicated as the innerworkings of that software product are, the inputs are pretty simple: a set of latitudes and longitudes and the stores they belong to. Obviously, there is more to the input then I'm saying, but the point is that it doesn't matter how the data that goes into the system is processed to produce the output. It could be a simple string replace function, or it could involve literal rocket science. In the end, the system is simply a machine that takes one thing as input on one end and outputs something else on the other end.
Output
It's very frustrating when a computer crashes. That's because the inputs - such as furious clicks or vigorous key pressing - are not producing any outputs. Nothing changes on the screen. It's still blue.
In math, 2 plus any number will always give me a solution. It would be absurd if I added two plus fifteen on my calculator and the calculator responded with nothing. In software, the same is expected of a computer. Input should always lead to output.
In the video games I make, the input to the software are the presses of the buttons on the screen. The output is technically the changes in the pixels on the screen. Internally, a lot is being done to decide which pixels go where, but externally, all the player is really aware of is that the screen changed or the sound changed.
In more corporate-minded software, the output is usually some variation of the data used in the input. Either way, the output of a computer is always in some way mechanical, even if random numbers are used in the input.
I'm not saying that I'm completely swayed and interested in I/O operations now, but I do have an appreciation for them based on how they dominate literally every level of a software solution from the beginning to the end. Maybe I'll warm up to them some day.
Comments:
Leave a Comment
Submit