On a related note, you also (and maybe foremost) have to understand the domain of the program and problems specific to it. Personally, the only time I was able to read code in a productive way was while I was dissatisfied in some way be each of the existing solutions to a given problem and was trying to came up with one suited to my particular needs, trying to combine the best traits of the existing ones. It was always ten minutes of reading code, at least an hour of extending my own implementation, then maybe switching to the next functionality, again ten minutes of reading code, and so on.
In other words, I think the advice given to programmers should not be just "read good code", but rather "compare your code with existing one" - you will appreciate the beauty of the classic Lisp implementations much more if you first try to implement your own interpreter for a programming language, only then you will know what to look for when reading. Cheers, Jarosław Rzeszótko 2012/12/2 John Nilsson <j...@milsson.nu> > Agreed. > > A program is very context dependent in my experience thought. So you'd > probably also want a pretty good record of the people and the environment > in which it was created to make sens of it. > > BR > John > Den 2 dec 2012 14:37 skrev "Julian Leviston" <jul...@leviston.net>: > > Concrete is better than abstract for learning. >> >> Julian >> >> >> On 03/12/2012, at 12:23 AM, John Nilsson <j...@milsson.nu> wrote: >> >> Yes. >> >> Hence you write a pattern language and spare people the agony of reading >> the programs it was discovered in. >> >> Which was precisely my point. Maybe this is is why we dont read programs >> and why we instead have pattern literature as our primary means of >> communicating interesting design ideas. >> >> BR >> John >> Den 2 dec 2012 14:18 skrev "Pascal J. Bourguignon" <p...@informatimago.com >> >: >> >>> John Nilsson <j...@milsson.nu> writes: >>> >>> > Isn't the pattern language literature exactly that? An effort to >>> > typeset and edit interesting design artifacts. >>> >>> Unless you're programming in lisp(*), reading a program written with >>> patterns is like looking at the wave form of "Hello world!" said aloud. >>> >>> >>> (*) See: >>> http://groups.google.com/group/comp.lang.lisp/msg/ee09f8475bc7b2a0 >>> http://groups.google.com/group/comp.programming/msg/9e7b8aaec1794126 >>> >>> -- >>> __Pascal Bourguignon__ http://www.informatimago.com/ >>> A bad day in () is better than a good day in {}. >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> >> > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc