[plt-scheme] Re: Scheme sources readability

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 read 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." If it only takes *you* a few seconds,
then you should probably be bililng $USD in multiples of one thousand
per hour :)

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.

>> 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. I think, though, perhaps you are looking at this from a
maintainers perspective? If that is the case, there is Helpdesk
documentation for private methods, isn't there?

> From your point of view nobody guarantee that it should be
> easy for third person to understand even interface of private
> module not even saying about its implementation. IMHO, this
> is not the case for commercial software development.

The only thing that matters is its interface, but that doesn't prevent
you from documenting private methods. PLT doesn't document private
methods?

>> 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

> In programming DP are addressing history proven successful code
> patterns used both in coding and understanding source code.

Patterns are really more about recognizing a particular approach to
some problem and giving it a common name.

> Despite the fact that i can implement most of patterns as macros
> doesn't mean that scheme community should not pay attention on
> architecture and force all starting scheme programmers to
> invent the bike.

Of course.