Ruby Impressions

[brueckd at tbye.com]

On 13 Jan 2002, Adam Spitz wrote:

> There's a fundamental difference in values here. I proposed a function
> that would make the code harder to read until you learn what it does,
> but *easier* to read *after* you learn what it does.

Whether or not it becomes any easier to read is very debatable, but the
problem is that, at best, your method would be beneficial only if you are
the only programmer. I spend a lot of time working with other people's
code, and if for each person I have to go look up the definition of their
special init function that's a lot more work and the code is a lot less
readable overall.

> This seems perfectly reasonable to me - it only takes a few seconds or
> minutes for me to look up a function to find out what it does, and it
> makes my code easier to write and easier to read from that point
> forward. I don't want to write my code with the assumption that the
> reader can't learn any new idioms, because that seriously limits my
> ability to express my intentions and eliminate duplication.

Nobody is suggesting you shouldn't introduce new idioms - that's silly. I
will say that idioms are, by definition, peculiarities. Even if they
become widely accepted they are something that new programmers and
"converts" have to learn, so the benefit of an idiom needs to outweigh
that cost. Python's most popular idioms tend to be a useful and elegant
way to do something - if it's not very useful or too darn ugly then it
doesn't become widely used. This is why the standard way to init members
usually works for me and your alternate solution does not - it provides
zero to incremental benefit to a problem that in real life doesn't cause
much pain at a cost that can increase in proportion to the number of
programmers.

> described my reasoning just now. It's a language that's harder to
> learn than Python is, but a bit less restrictive than Python is - and
> the *culture* is a *lot* less restrictive than the Python culture is.

I'm sorry, but I have no idea what you're talking about. For me, Python is
about the ability to quickly produce lots of clean, concise, solid code
that you can understand even if your coworker wrote it or even if you
haven't looked at it for 3 months.  Perhaps your perception that the
community is restrictive is more a misunderstanding of what many Python
programmers value - my own perception is that the community is very open
to ideas that suport those core values.

-Dave