OT: Crazy Programming
Chris
chris at cmb-enterprises.com
Mon May 13 23:10:34 EDT 2002
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.
More information about the Python-list
mailing list