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

Reply via email to