OT: Crazy Programming

[Chris]

In article <3CE05339.6660B6BA at engcorp.com>,
 Peter Hansen <peter at engcorp.com> wrote:

> Chris wrote:
> > 
> > > Chris wrote:
> > >         ...
> > > > While I enjoy Python - and I do... it opned up the world of OO
> > > > programming for me - I think there's almost a danger in things being too
> > > > obvious.  Creativity can be a messy business, but ultimately it leads to
> > > > better places.
> [...]
> > In the end I'm not trying to say Python's approach is bad.  Quite the
> > contrary, I like Python quite a bit, and have defended it amongst Perl
> > devotees.  I just think that there is an advantage to a bit of
> > ambiguity, at times.
> 
> You've said there's a danger in things being too obvious, and that there
> are advantages to a bit of ambiguity, but you haven't yet stated what
> that danger nor what those advantages might be.

The danger is stagnation.  A certain approach works, so that's what gets 
used, even when there are other better(shorter, more readable, more 
consistent, more elegant, faster, more "direct", etc.) ways of 
approaching a problem.

The advantage to a little bit of ambiguity is that it forces attention 
to detail that really gets the neurons firing.

> Is it just a gut feeling, or do you really have specific examples on
> which you base these claims?

Well, in writing Perl modules I could continue to use(to access a data 
member of an object, stored as a hash):

   package Person;
   sub name {
      my $self = shift;
      if (@_) { my $self->{name} = shift; }
     return $self->{name};
   }

And use this as:

   print $guy->name("John");

Or, I could try out lvalue subroutines and use something like:

   package Person;
   sub name : lvalue {
      my $self = shift;
     $self->{name};
   }

   print $guy->name="John";

With Ruby, my personal favorite, there are iterator methods, which 
someone might never discover if they were content to simply use for 
loops.  Or they could manually construct accessor methods for classes, 
since that works perfectly well, even though it's nowhere near as 
elegant as attr_accessor/attr_reader/attr_writer.

> Personally, I reject both of them outright, after starting with the
> premise that when programming I'm engaged in a practical endeavour,
> not an artistic one.

With all of the people I know who've gone into "computer science" 
because "they can make a lot of money", and not because they have any 
kind of passion for it, I take a bit of offense at that idea.