'for every' and 'for any'

[Quinn Dunkan]

On Wed, 29 May 2002 03:46:01 -0400, Oren Tirosh <oren-py-l at hishome.net> wrote:
>On Tue, May 28, 2002 at 04:01:40PM +0000, Quinn Dunkan wrote:
>> >An expression is easy to use in an if statement where you get an else 
>> >clause. Using combinations of break makes it harder to use both the positive 
>> >and negative case. I often find myself rearranging my code and sometimes 
>> >inverting tests just to get what I want. That's not what programming is all 
>> >about. I'd rather concentrate on the task at hand than on how to express it.
>> 
>> Then drop those functions into your personal utility library and use 'em
>> as often as you want :)
>
>I don't have a personal utility library. It's on purpose. I don't have
>personalized key bindings. I try to avoid customization.  Customization is
>a big part of what makes one programmer's code difficult to maintain by
>another programmer, what makes on programmers's workstation unusable by 
>another and makes combining code from several sources difficult.

Um, customizing your workstation is only going to cause problems for other
people if they use your account.  I'm hoping they don't do that?  No one can
use my wacky setup but they don't need to because I log out when I'm done.

All of the good programmers I've seen working have idiosyncratic setups.  I've
never heard of any problems because of it as long as they can edit text and run
cvs or whatever, but I've seen plenty of problems suffered by people who
exclusively use poorly chosen defaults.

And if you're writing code with another programmer, yes, you both need to use
the same libraries.  You should also use the same language :)

Of the hard-to-maintain code I've looked at, it's always been not enough
abstraction, rather than too much.  People who are used to C and Pascal seem to
be especially used to reinventing common operations, probably because
non-polymorphic static languages make it hard to write generic anything.

>Just one little example: I hate it when different parts of the code use 
>their own customized constants for ints from specific sizes.  Is it 
>u_int32_t, uint32_t or guint32? I hate it when a big project starts and the 
>programmers all start to waste their time on writing a yet another library 
>with all this stuff.

That's a complaint about C's type system, and is not relevant to the issue.

The question of C programmers re-writing a utility library is also not
relevant because the question is not re-writing vs. re-using a utility
library, but using one vs. not using one.  There seems to be some kind of
cultural thing where C programmers like to reinvent stuff.  Or something.
I'm not really a C programmer so I don't know.

Would you avoid certain abstraction mechanisms in C because it led to a mess
when you tried it in FORTRAN 30 years ago?

>One of the things I like about Python is that it comes with everything in
>the box. 

The way I see it, one of the major advantages of dynamic flexible languages
like python and lisp is the ability to program "bottom up" (to use graham's
terminology) by writing a lot of little generic interoperable parts that can be
stacked up later.  No language can come with everything in the box, and an
attempt to make it so is trouble because everyone's needs are different.

I agree that programming is not rearranging loops but about expressing the
problem as directly as possible.  The chances are slim that you'll be able to
directly express your problem in "pure syntax".

Anyway, obviously you're free to follow whatever convention you wish.  I'm just
saying that I don't agree with it so I don't go for the "but I can't use this
solution because my religion forbids it" line.