http://qs321.pair.com?node_id=59421

I work in a studio which is active, among other things, in graphic design. Here I learnt how much graphic organization of data is important.

Trusting the principle A picture's worth one thousand words, I'd like to apply that to computer programming. I think it's possible to lay out code so that, with a glimpse, we could know what is doing, and how. After, we could focus on the segment we are interested in. I mean something that concerns indentation, syntax highlighting, but much more: teaching (for example, lay out code for books), cognitive sciences and so on.

I ask to monks who have graphic-, art- and desktop-publishing- backgrounds (does anyone?): How much could a program be beautiful and easy to comprehend? Now, I'm going to try something with Adobe Illustrator... :)

see you. lars

Replies are listed 'Best First'.
Re: Beyond literate programming...
by cat2014 (Monk) on Feb 20, 2001 at 00:06 UTC
    I have a bit of a graphics background (a major that was 1/2 computer science & 1/2 photography), but I don't really think that relates too much to this. while I think that your idea of graphically illustrating a program is interesting, I don't really think that would contribute that much to a program.

    I've seen programs diagramed as flowcharts illustrating the different steps a program takes while executing, which is certainly useful for some. It's not as good, though, as a good design for your program. Good abstraction, elegant algorithms, and well written code will, in my opinion, do far more to make a program easy for someone other than the original author to understand than all the flowcharts in the world. Those same 3 things are pretty much my only criteria for the beauty of a program.

    Personally, I think that stuff like tux poster is ok, but not that pretty to look at. I'd rather judge how beautiful code is by 1 set of standards & how beautiful a illustration or painting is by a completely different set of standards. I know a lot of stuff has tried to merge the two (like the antitrust movie desktop wallpapers) but it seems silly to me. -- cat

      Thank you.

      I was actually thinking that the way one develops code is highly non-linear. According to me, the way we study e comprehend it too. Moving from this principle could be useful for books, as I said in my previous message. Or for teamworks, so that different programmers at different levels could communicate between them.

      Code provide at the same time all levels of details: documentation, comments, high-level code, tricks and so on. Good programmers organize this stuff so that one can easily dig trough their code (for example, with POD you can separate documentation from code). I think this could be done more effectively, using principles of graphic design.

      I'd rather judge how beautiful code is by 1 set of standards & how beautiful a illustration or painting is by a completely different set of standards.

      Me too. But, for example, maps of undergrounds are illustrations, and I think I can judge them by aesthetic and readibility standards. I'd like to try to transform computer programs in illustrations. Perhaps this is a complete waste of time. I hope not :)

      It's better I provide an example of what I'm talking about: if I'll have time, I'll do it this weekend.

      see you. larsen

        Two thoughts:

        • I agree with cat2014. There is a certain beauty to "Good abstraction, elegant algorithms, and well written code...". I would only add that the less 'cluttered' the code is, the more beautiful it is.
        • "The map is not the terrain." I think I read this in a book about golf, but the idea applies here. Any 'picture' you want to draw of a program will not be complete. This applies, even if your medium is text. A program when read may or may not be the same program when run.

        So, I don't think it can be done (i.e., how to lay out the code so that with a glance you can know everything about the program), nor that we need to. If you figure out how to do it, however, I'ld like to know the trick. :-)

Re (tilly) 1: Beyond literate programming...
by tilly (Archbishop) on Feb 21, 2001 at 16:54 UTC
    Please keep in mind that people differ. Visual tools like what you intend are virtually useless to me since I am not very visually oriented. I far prefer the richness of text. Not only does a visual metaphor not help me much, but I have trouble providing visual metaphors that help others. That isn't how my brain works.

    Two essays on this theme of possible interest. First of all Unix as literature which explains one of the fundamental philosophical differences between Unix and most other operating systems. And then secondly Neal Stephenson's, In The Beginning Was The Command Line. I won't try to describe it other than to say it is long.

    Some background. Both essays are from when Microsoft's monopoly still looked invincible and the idea of Linux as a serious competitor looked to most people who heard about it like a sad joke.

Re: Beyond literate programming...
by stefp (Vicar) on Sep 25, 2001 at 17:54 UTC
    Trusting the principle A picture's worth one thousand words, I'd like to apply that to computer programming.

    I dont think that visual programming is the general way to go except for specialized problems like automata. The real barrier to break is the ASCII monofont, monosized, monocolor conventions for programming languages. I call it the teletype barrier because these conventions have been shaped by that physical device. Typographically speaking, the only significant progress has been the generalization of lower case letters.

    When a mathematician writes a formula (is that the right word in English?), it is often an algorithm, almost a program. A mathematician uses many alphabets and many fonts, indices and exponents. We can't. These conventions have been improved by generations of mathematician starting with Viéte (these starting date are often biased by nationality :)

    Such "formulae" are certainly not graphical in the sense you implied, but the underlying conventions leads to a neat layout so that it is "parsed by our eyes" instead of being slowly deciphered.

    I think Mathematica is an interactive environment that uses such conventions but it is expensive (1000$) and mosttly specialized in Mathematical rule based programming. I am not surprised when searching on thenet pages about the history of mathematical notation to trip on this conference by Steven Wolfram. His concern is the one that motivates this node Given its historical basis, it might have been that mathematical notation--like natural language--would be extremely difficult for computers to understand. But over the past five years we have developed in Mathematica capabilities for understanding something very close to standard mathematical notation. I will discuss some of the key ideas that made this possible, as well as some features of mathematical notation that we discovered in doing.

    There is a chicken an egg problem here in getting a real interactive literate programming environment: which comes first, the typesetting rich language or the editing environment? But there is hope. Check TeXmacs, this is an WYSIWYG structural editor. Very roughly speaking, conceptually, this is a mix of TeX and emacs. If correctly extended, it could provide such an environment. And the perl communauty, with its motto TMTOWTDI, is more prepared than any other to accept possibly different representations for the same program.

    As for classical litterate programming, the tools developped by Knuth are not interactive enough. But they are fine to generate a documentation to be read off-linelike The Stanford GraphBase; A Platform for Combinatorial Computing

    -- stefp

Re: Beyond literate programming...
by jepri (Parson) on Feb 20, 2001 at 18:08 UTC
    Just based on what I've seen around the place, you have the chance to break some ground here. I have run across a few well-intentioned efforts such as eerr what's it called... Visual Smalltalk or Smarttalk or something. Agonisingly painful. You had to draw lines between boxes to indicate actions, or function calls, and the boxes represented functions or variables. It took a long time to do simple tasks, although I could see how it could be a useful tool for some work.

    Then there was supposedly a windowing system called NEWS that had a cool code representation program that drew your code out with symbols for different things like variables and functions. I saw a screen dump and the program looked like a weird heiroglyph - very cool.

    If anyone knows of this program, I would be grateful for a copy, although I guess I could program it myself in my copious free time (hah!)

    I also found a two dimensional programming language. It was on a page with lots of malformed programming languages such as brainfuck and dis.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.

Re: Beyond literate programming...
by jynx (Priest) on Feb 21, 2001 at 05:42 UTC

    How much could a program be beautiful and easy to comprehend?

    < humor> hmmm, don't know, why not read erudil's There can be only one and find out? </humor>

    Seriously, The main problem i have with graphic tools to do code programming is that for the most part they don't allow enough flexibility and creativity from the programmer. Coding html* with a page editor may be easier, but getting into the thick of it with some (gasp-in-horror) javascript with layers and (please-stop-it-hurts) java for interactivity and (thanks-for-the-reprieve) perl for the amusing stuff is a lot more powerful and comprehensive than a couple links on a badly colored site**.

    What i mean to say is that coding by hand from someone who knows what they're doing is a much more powerful, flexible idiom. Coding graphically may be useful to the novice to understand things, but if they are ever to rise up to be a great programmer they need to understand the underlying material as well, which doesn't get conveyed well, if at all, in graphic-based programming. These are at least my opinions of the state of it so far...

    nuf evah,
    jynx


    * html is just an example, and probably not the best at that...
    ** Not that all sites done by graphic web authoring tools are bad, it's just the stereotypical case when used by people who don't know computers or the WWW well enough to find either in a well-lit room with large signs, semaphores, and an usher. And web authoring tools can indeed be useful in the right circumstances (which aren't as hard to come by as i might lead on     =)

Re: Beyond literate programming...
by bladx (Chaplain) on Mar 05, 2001 at 03:51 UTC
    Hi larsen

    Your idea of a newer, better, faster, well maybe not faster, but different idea of a visual programming learning experience may be the ticket for some types of visual learning people! Also, as was stated earlier, it would make it easier for different level programmers to talk about certain ideas without the current level of difficulty it is already at.

    Even though this is a great idea and such, there are some drawbacks:
    1. Not everyone is a visual learner as would benefit from this approach to programming.
    2. This idea may have already been thought of and implemted in specific programming books.
    3. Would this get beginners to programming off on the wrong foot? What I mean is, by not actually seeing the code in its true form, how will people learn that code doesn't always look all colorful and such.
    No offense or anything by the cons I have stated about this idea, but there are a plentiful amount of pros that can make this idea a worthwhile reality available to many people that wish to program! From a designers point of view (such that I am an art designer of sorts,) I tend to consider true code to not be considered as 'art' persay such as paintings, or layouts, etc. are. Programming IS an art, don't get me wrong... but you have to judge it on a different caliber of scale. If you don't get what I mean, just pm me or something, and i'll try to answer your questions :o)

    Keep up the great thought proccesses!!

    bladx ~ ¡muchas veces tengo preguntas!