Input/Output

   In [1]programming input/output (I/O or just IO) refers to communication of
   a computer [2]program with the outside environment, for example with the
   [3]user in [4]real world or with the [5]operating system. Input is
   [6]information the program gets from the outside, output is information
   the program sends to the outside. I/O is a basic and very important term
   as it separates any program to two distinct parts: the pure
   [7]computational system (computation happening "inside") and I/O which
   interconnects this system with the real world and hence makes it useful --
   without I/O a program would be practically useless as it couldn't get any
   information about the real world and it couldn't present computed results.
   In [8]hardware there exists the term "I/O device", based on the same idea
   -- I/O devices serve to feed input into and/or get output from a physical
   [9]computer, for example keyboard is an input device and monitor is an
   output device (a computer without I/O devices would be useless just as a
   program without I/O operations).

   Note that I/O is not just about communication with a human user, it also
   means e.g. communication over [10]network, reading/writing from/to
   [11]files etc.

   It is possible to have no input (e.g. a [12]demo), but having no output at
   all probably makes no sense (see also [13]write-only).

   I/O presents a challenge for [14]portability! While the "pure computation"
   part of a program may be written in a pure platform-independent language
   such as [15]C (and can therefore easily be compiled on different
   computers) and may be quite [16]elegant, the I/O part gets more ugly.

   This is because I/O is inevitably messy: an abstract, portable I/O library
   really tries to do the impossible task of unifying all wildly differing
   physical computers and their architectures under some simple functions;
   for example consider an I/O library will offer a function such as
   drawPixel(x,y,color) that draws a pixel to the screen -- how do we make
   this work for all computers? What value is color here, is it RGB, a color
   index, HDR value? What if a computer doesn't allow writing to arbitrary
   parts of screen coordinates because it lack a frame buffer, or what if
   such operation is painfully slow there (some computers may just want to
   write pixels sequentially in possibly varying orders we can't predict)?
   WHAT IF the computer doesn't even have a raster screen but instead has a
   [17]vector screen? Even such things as files residing in a tree of
   directories are something that's highly established but not necessarily
   the only way a computer may work, some computers may for example support
   files but not directories, how does our library take this into account?
   How do we deal with file names with very weird characters, what if someone
   makes a file system where file names are actually [18]rich text or where
   files aren't places in directories but are rather points in [19]3D space
   or something? So an I/O library has to inevitably make many assumptions
   about what a "normal" computer looks like and what will likely help it
   operate fast etc. It has to decide how to deal with unsupported things,
   for example if we try to display color on a black and white display will
   it cause an error or will we try to somehow approximate the color just
   with shades of gray? And of course with new I/O devices appearing (VR,
   brain interfaces, ...) the library will have to be constantly [20]updated.
   So the I/O part of the program will usually require some platform specific
   [21]library or a library with many [22]dependencies; for example to
   display pictures on screen one may use [23]SDL, [24]OpenGL, Linux
   framebuffer, CSFML, [25]X11, [26]Wayland and many other libraries, each
   one handling I/O a bit differently. Whatever library you choose, it may be
   unavailable on some other platform, so the program won't run there. Some
   hardware platforms (e.g. many game consoles) even have their own exclusive
   I/O library, use of which will just tie the program to that single
   platform. There are programming languages and libraries that try to
   provide platform-independent I/O, but as said such approach is limited as
   it has to assume some common features that will be available everywhere;
   for example [27]C has a standard platform-independent I/O library stdio,
   but it only allows text and binary input/output, for anything advanced
   such as graphics, sound and mouse one has to choose some 3rd party
   library. [28]Unix philosophy also advises to only use text I/O if
   possible, so as to "standardize" and tame I/O a bit, but then again one
   has to choose what communication [29]protocol/format to use etc., so the
   problem just shifts from standardizing library API to standardizing
   protocols. So generally I/O is a problem we have to deal with.

   How to solve this? By separating I/O code from the "pure computation"
   code, and by minimizing and [30]abstracting the I/O code so that it is
   easily replaceable. Inexperienced programmers often make the mistake of
   mixing the pure computation code with I/O code -- it is then very
   difficult to replace such I/O code with different I/O code on a different
   platform. See [31]portability for more detail. Also if you don't have to,
   avoid I/O altogether, especially if your project is a library -- for
   example if you're writing a 3D rendering library, you do NOT actually need
   any I/O, your library will simply be computing which pixels to draw and
   what color they should have, the library doesn't actually have to write
   those pixels to any screen, this may be left to the user of the library
   (this is exactly how [32]small3dlib works).

   I/O also poses problems in some programming [33]paradigms, e.g. in
   [34]functional programming.

   TODO: code example

Links:
1. programming.md
2. program.md
3. user.md
4. irl.md
5. os.md
6. information.md
7. computational_system.md
8. hardware.md
9. computer.md
10. network.md
11. file.md
12. demoscene.md
13. write_only.md
14. portability.md
15. c.md
16. elegance.md
17. vector.md
18. rich_text.md
19. 3d.md
20. update_culture.md
21. library.md
22. dependency.md
23. sdl.md
24. opengl.md
25. x11.md
26. wayland.md
27. c.md
28. unix_philosophy.md
29. protocol.md
30. abstraction.md
31. portability.md
32. small3dlib.md
33. paradigm.md
34. functional.md