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'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 | [reply] [Watch: Dir/Any] |
by larsen (Parson) on Feb 20, 2001 at 13:45 UTC | |
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 | [reply] [Watch: Dir/Any] |
by t'mo (Pilgrim) on Feb 20, 2001 at 17:19 UTC | |
Two thoughts: 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. :-) | [reply] [Watch: Dir/Any] |
Re (tilly) 1: Beyond literate programming...
by tilly (Archbishop) on Feb 21, 2001 at 16:54 UTC | |
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. | [reply] [Watch: Dir/Any] |
Re: Beyond literate programming...
by stefp (Vicar) on Sep 25, 2001 at 17:54 UTC | |
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 | [reply] [Watch: Dir/Any] |
Re: Beyond literate programming...
by jepri (Parson) on Feb 20, 2001 at 18:08 UTC | |
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. ____________________ | [reply] [Watch: Dir/Any] |
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,
| [reply] [Watch: Dir/Any] |
Re: Beyond literate programming...
by bladx (Chaplain) on Mar 05, 2001 at 03:51 UTC | |
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: Keep up the great thought proccesses!! bladx ~ ¡muchas veces tengo preguntas! | [reply] [Watch: Dir/Any] |