Text and graphics

The last week Ero Carrera in his blog linked to this spectacular site:





These eye catching images evoked an old question in me. Briefly it can be formulated as “text vs graphics”.
Everyone would agree: graphic images are much nicer and more powerful than simple text. There are no limits for images while text is a sequence of predefined symbols. Images are accessible for illiterate while reading text is impossible without knowing its language. One glance at an image is sufficient to grasp its idea while text requires careful deciphering of letters and words. Images can easily affect conscious and subconscious parts of mind. Text can do it too, but to much less degree.
Yet many, if not most, of our data is in the text form. Programmers write programs in text files. Data kept in databases is mostly in text form. If data is not in the text form, we have to process it to extract text or some textual description from it. Web pages are essentially text files with links to graphic images. Ubiquitous XML files are kept in the text form. Even the graphs from the above site are represented in a text language like GDL or DOT or something similar.
How strange that we still continue to use text as the fundamental form of our knowledge. Why is it so? Why this awkward and unnatural device has not yet been replaced by something better? Why is this




more widely used than this? ;)


This entry was posted in Programming. Bookmark the permalink.

12 Responses to Text and graphics

  1. Nearly all programmers have a plain text editor, and our diff tools understand plain text.
    Anyway, I recall a time when I wanted to write a unix shell command where the stdout of one process would be directed into the stdin of two other processes.
    In wondering how my ideal shell language would do this, and I came up with a rather messy syntax inspired by C’s a?b:c operator.
    With a graphical programming language, it would be very easy to drag-and-drop some sort of duplicator object with 1 input and n outputs.
    PS. Thanks for the WMF patch.

  2. hume says:

    I think graphs has it’s advantages in most cases, while the text form is not useless either.On helping ppl understand codes quickly, sometimes text can present more compact and rich information for us, in the example above, we know from the textcodes that more possible values of dl register can take in the program logic than from the graph on first glance, but turn to tracing branches of the codes, the graph form is obvious more effective.the question is that our screen is limited, and maybe text form can afford more information on one screen.
    Another reason why graph form is not so popular is that most code visualization tools is too function limited.eg. GDL graph displayed in Wingraph32 can’t be edited, can’t be searched, can’t be bireyed, can’t be dragged as will….so many limitations, the tool limitations make more ppl frustrated.
    In fact many visualization applications has been used widely, in viusal studio or in borland dev tools, graphic interface design practices have replaced many text editing and typing work, and ppl have been used to that, So I think if more powerful tools and methods afforded, ppl will like that.
    BTW, is the graph generated by IDA 5.x?

  3. White Flame says:

    Computers have always been thought to process data files which are linear streams of bytes of some sort. From their inception, they needed to follow a list of steps, breeding this notion of a linearity of symbols. One of the simplest encodings of this stream is text.
    Text isn’t going away anytime soon. Unix’s main strength is the abundance of tools dealing with linear text streams. As said above, everybody has editors for them, too. All(?) programming languages that deal with files support text reading and writing. Any human developer can easily deal with text files.
    The problem with text isn’t that it’s human-readable characters instead of more abstract objects, the problem with text is that it’s inherently linear. Simple shell scripts tend to fall apart or explode in complexity when it needs to grok a text file that represents an interconnected graph instead of linear data. Most text traversal is simply jumping to another point in the linear text stream, but the linearity is not avoided. Human reading of descriptive or explanatory text requires linear traversal to establish context.
    My major problems with the strict adherence to the status quo of text:
    - Linearity
    - The data which the text represents is combined with viewing details (consider a CVS source code repository where different developers use different indentation and autoformatters).
    - Slow conversion, big files
    - Syntax errors
    As a simple example, I’ve thought for a long time (and I’m sure I’m not alone) that source code editors should save, load, and work with language-specific parse trees, instead of at a text character level, even if they look & act the same to the user.
    Another thing that bugs me is when people talk about dragging stuff around for programming. The basic fact is that moving things around physical space is much slower than typing or using shortcut keys to assemble constructs. Sure, make it graphical by all means, but don’t lock me to the mouse.
    As far as the communication of concepts goes, graphics do not necessarily outweigh text. Graphics do allow for a quick glance overview, as well as poring over details. But in general, a graphical representation has a fixed level of detail. A textual representation can describe as much or as little as it wants to about any portion of the concept described. Text also does not require a significant development effort to add new levels of detail of description, and also is easily searchable. However, text does not offer a quick glance overview unless one is specifically created (Table of contents, etc), in general is slower to glean many concepts from, and is unsuitable for certain nonlinear concepts.
    All in all, I think that many times people latch on to the concept of graphics for the sake of graphics, without truly weighing the strengths and weaknesses of both alternatives.
    (enough rambling)

  4. Myron says:

    > Browsing the web was not safe anymore, regardless of the browser.
    This wasn’t at all true.
    We used both Konqueror/SuSE, Safari/Camino/Firefox for OS X and it was very safe.
    Actually it was more fun that it has been in a long time.

  5. ilfak says:

    Bill P. Godfrey,
    A nice syntax for the shell problem! Do you know any shell which really implements this operator?
    Hume,
    No, the graph is from wingraph32. IDA 5.0 will be much more beautiful :)
    White Flame,
    The linearity of text is the very property which makes it so easy to process it. Plain ascii text can not be surpassed in simplicity by any other form…
    Myron,
    It seems you chose the wrong blog entry and operating system. The choice is yours, of course :)

  6. White Flame says:

    Plain ascii text is not simple to process. You need lexers and parsers to input it, and the size is exploded when outputting it from internal objects. You also have to take into consideration various platform line delimiters, character encodings (okay, breaking a bit from plain ascii), and line wrapping imposed from text editors, and different tab stop sizes might affect it a great deal.
    If a program doesn’t care what the contents of the text is, or does processing based on characters (sed, grep, etc), then sure it’s easy, but it’s not going to be very useful to the program without a lot of effort spent on strings to break it down into meaningful constructs.
    “Everything should be made as simple as possible, but no simpler.” I think that sometimes the use of text-only is trying to create a solution that is too simple for the problem at hand. What we need is a good standard for specifying structured data at varying scopes, so that editors and computers in general don’t have that painful gap between text characters and syntax/meaning. Too bad XML is such a poor implementation of that concept. :)

  7. Ilfak Guilfanov says:

    Well, lexers and parsers are not a problem. There is plenty of choice (free and commercial) on the market. Do you see any difficulties parsing text with them? Problems like the tab size can be solved easily (why not consider all whitespace as word delimiters to start with? ;)
    I agree with you about other drawbacks – usually text representation is too big in size. In general text processing is slower than binary data processing.
    Yet text is there to stay. It is soooo convenient to open a file and say

    while (<F>) { process(); }
    

    Is this the main reason? :)

  8. This is my ideal (unfinished) shell language. It has a rule that string literals have to be in quotes, including command lines.
    cmdA p1 p2 Y cmdB p1 : cmdC p1 : cmdD p1 p2
    Here, the stdout of cmdA is passed into cmdB, cmdC and cmdD which run in parallel.
    Y and : have special meanings, so if you wanted to pass the letter Y as a paramameter, you’d have to say “Y”. (As with all string literals.)
    Nested Y: operations can be performed by placing entire command lines inside round brackets.

  9. Stephen Youndt says:

    You ought to check out mtee. It doesn’t implement your syntas, of course, but the functionality seems to be there.
    http://dcs.nac.uci.edu/~strombrg/mtee.html

  10. Hello,
    A related comment and request. I as well wonder about the difference between text and graphics. As an artist I deal with the visual more than the textual.
    How could I display an entire file, a .jpg for example, in its binary equivilant? I want to print all the ones and zeros that if entered into a computer in sequence could be used to reconstruct the file. Please email me if you have a suggestion or a place for me to look. Thank you.
    I am making a body of work revolving around copywrite issues and where the line of intellectual property rights is drawn.

  11. Yen says:

    I realize you’re dealing in low level languages, but I wanted to throw my opinion into the mix and perhaps make a useful suggestion.
    I’ve been using LabVIEW as a programming tool for over 2 years and I would like to suggest that some of you try it just to see an example of what graphical dataflow programming can be like.
    At least a mostly-well-thought-out product like LV shows that:
    a) Such a language has a significantly lower learning curve (although many sequential-execution-oriented programmers have problems in making the paradigm shift and end up creating a graphical version of text code, which does not work well).
    b) A competent programmer makes the productivity much higher due to not having to deal in annoying things like variable definitions, memory allocations and so on and being able to test and debug the code from the bottom up.
    c) Inherent parallelism in the language makes certain tasks easier. Also, the basic structure of the language simulates a parse tree.
    d) Good visual code is much nicer to look at, more readable and often more condense than text code.
    The downside, at least in LV, comes in performance. NI, the company which makes LV, is not in the programming field – their products are designed for a certain field and it is through evolution, not design, that LV (or G, the language underlying it) can be used for many general (i.e. not specific to its native purpose) programming tasks. It is by no means as flexible as C and can not be used to write many kinds of programs (3D games, for instance).
    The only reason I’m bringing this up is to suggest checking it out to see how graphical programming can be done – I assume that such a design will only really be applicable to a high level language, but I’m not an assembler user, so I wouldn’t know.
    Note – there is a fully functional evaluation version of LabVIEW 8.0 (the newest version) available at NI’s site and it’s a pig. I would suggest trying to find version 7.0, because it should be lighter. Also, there used to be an online version for 7.1 using ActiveX, but I never tried it, so I can’t testify to how good of a simulation it is.
    I don’t think there should be any problems in installing\uninstalling it (I never had any), but it’s your choice. Also, if I remember correctly, LV is by default set up in a sort of “new user mode” which allows the “non-programmers” to use the product much more easily (for instance, the icons in the code appear big, which takes up a lot of code space). This mode does not represent LV as a programming tool and real LV programmers disable most of the fluff as soon as they can. I would be interested to hear about any experiences any of you have with it.

  12. jun says:

    Hi,
    Is there any software of program today that can extract text in a graphic file? for example, i have a scanned document here, usually the output of a scanned document is a graphic file, in this graphic file, is it possible to extract the texts so that i can transfer it to word document and edit it?