Re: Re: Beyond literate programming...

[larsen]

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

[t'mo]

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. :-)