[plt-scheme] Re: Scheme sources readability

Grant Rettke wrote:
> On Sun, Sep 7, 2008 at 11:59 AM,  <kbohdan at mail.ru> wrote:
>> Matthias Felleisen wrote:
>>> Code in Scheme tends to be 1/4 or 1/3 of the size of Java.
>>> The indentation structure is far more revealing than there.
>>> So I find it as readable as Java or better. You could argue
>>> CL is better, I wouldn't respond then.
>> Yes, agree code size is much smaller, but i'm still not sure
>> if it helps me to lread it.
>> Lets compare with Java: If i see class names like XxxAdapter,
>> XxxVisitor, XxxFSM, XxxModel/XxxView/XxxController it only takes
>> a seconds to understand what is going on.
> 
> kbohdan, my bread and butter is enterprise Java; so thanks for the
> comic relief with your statement that "it only takes a [few] seconds
> to understand what is going on." 

I mean surface understanding and reviewed code expected to be ideal. 
Also expected the same-level sample in scheme.

If it only takes *you* a few seconds,
> then you should probably be bililng $USD in multiples of one thousand
> per hour :)

:) Still trying. Hope you too.

> I would instead argue that the class name captures its intent, but you
> don't need classes to realize the goal of the design pattern itself,
> especially if the pattern only exists to work limitations of the class
> system to achieve the goal of the pattern.

Did i say that i want classes or OOP in scheme ?
BTW, pattern name can be captured in macro.
Please do not consider cases with "legacy GoF patterns" lets
imagine native scheme higher order patterns. Ex:
   - coroutines
   - DSLs
   - monads
   ...

Without pattern catalogue i can see the only way to become good scheme 
programmer : traverse tons of web links and articles without any idea 
what is good in practice and what is just mathematic experiment.
And that is what i'm currenly doing :)


>>> We consider Help Desk a priority because its linked way
>>> of doing docs is superior. As my PhD advisor used to say,
>>> a program (he meant module) is only worth writing if you
>>> also write a paper about it (he meant documentation).
>>  "Help Desk" helps me to understand public interface, but
>> it doesn't help me too much to understand implementation.
> 
> Object-oriented (OO) decomposition of systems doesn't work unless you
> are a product comapny. Virtually everyone doing enterprise development
> does component oriented development (CO) (whether they want to admit
> that or not is another story). Don't confuse using an OO language to
> implement a CO architecture. The *only* thing that anyone should code
> against or care about these days is the class' interface.
> Implementation doesn't matter, especially if you're interested in
> testing. 

Looking at code of big companies like MS, should agree here.
 From this perspective documenting private code probably is not
very important. Simple comment will be enough.

<snip/>

>>> The design patterns of GOF were invented to address
>>> weaknesses in Java and C++'s expressiveness when compared
>>> to Scheme and LISP. Plus, when we discover a "pattern", we
>>> just turn it into a construct via syntactic extensions.
>>  Design patterns (DP) were invented by architect not by programmers.
> 
> Architect == Senior Programmer

"Christopher Alexander" == Senior Programmer ? :)

<snip/>

--
Bohdan