Python vs Ruby
aleaxit at yahoo.com
Mon Oct 24 17:09:13 CEST 2005
Michele Simionato <michele.simionato at gmail.com> wrote:
> Alex Martelli wrote:
> > ... remember Pascal's "Lettres Provinciales",
> > and the famous apology about "I am sorry that this letter is so long,
> > but I did not have the time to write a shorter one"!-)
> This observation applies to code too. I usually spend most of my time
> in making short programs
> that would have been long. This means:
> cutting off non-essential features (and you can discover that a feature
> is non essential only after having implemented it)
This one is difficult if you have RELEASED the program with the feature
you now want to remove, sigh. You end up with lots of "deprecated"s...
somebody at Euro OSCON was saying that this was why they had dropped
Java, many years ago -- each time they upgraded their Java SDK they
found out that half their code used now-deprecated features.
Still, I agree that (once in a while) accepting backwards
incompatibility by removing features IS a good thing (and I look
forwards a lot to Python 3.0!-). But -- the "dream" solution would be
to work closely with customers from the start, XP-style, so features go
into the code in descending order of urgence and importance and it's
hardly ever necessary to remove them.
> rethinking the problem to a superior level of abstraction (only
> possible after you have implented
> the lower level of abstraction).
Yep, this one is truly crucial.
But if I had do nominate ONE use case for "making code smaller" it would
be: "Once, And Only Once" (aka "Don't Repeat Yourself"). Scan your code
ceaselessly mercilessly looking for duplications and refactor just as
mercilessly when you find them, "abstracting the up" into functions,
base classes, etc...
More information about the Python-list