Ruby Impressions

[Andrew Dalke]

Adam Spitz:
>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. 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.

Lookee here.  You again bring up a strawman argument that neither I nor
anyone else here has suggested, and it's one with which I do not agree.
The people who use and maintain my software are not going to be developers.
They will be scientists with some (usually) limited programming experience.
I made that quite clear in my earlier statements.  Hence, I must put more
effort into optimization for the understanding of others, not for myself.

Don't misunderstand me.  Scientist are perfectly able to remember all
sorts of odd little details - almost by definition.  But it doesn't mean
they like doing so for things outside their field.  A goal of mine though
is to make programming as enjoyable for them as it is for me.  I've seen
many a code where the brute force way was implemented; eg, using var1, var2,
var3, var4, var5 rather than a list of size 5.  I interpret this and other
less simplistic examples to mean that my target audience is willing
to type more in exchange for needing to know less.  Your target audience
is not my target audience, so it's less of a concern.

It is not that they cannot learn new idioms, as you try to position things
above.  It is that learning a new idiom with the sole advantage of saving a
few simple lines of code is not worth their time to invest in
understanding -
that that could be better spend in understanding why a certain sidegroup is
more likely to cause DNA intercalation.

There *are* idioms which are much more useful and powerful, and which
scientists enjoy using once they learn it.  But from my exprience, this
proposal of yours is not one of them.

>But Andrew (and probably lots of other Python programmers) reacted to
>my statement with immediate distaste, because... well, he's made his
>reasons clear, and probably most of you agree with him anyway. That's
>perfectly reasonable too.

Distaste?  The only distaste I have is for your use of rhetorical tricks
to make your point rather than more well reasoned arguments.  I said that
there are cases where I've used mechanisms similar to yours but that I
didn't find it generally useful enough to be a standard part of the
language.
I and others pointed out perhaps now a dozen quite different ways to
implement
it for Python if deemed important for a local problem.  I tried to outline
the reasons for why I made my decision, partially on the hopes that you or
others would correct my mispeceptions and perhaps I would learn something.

I don't think there was any place where I said the idea itself was
distasteful, and if so, I apologize.  There was one place where I said:

] As far as I can tell, it dynamically calling the Ruby compiler on
] the fly.  That seems horrendously complicated to me.  Doesn't the
] code I show above do essentially the right thing you want?

but that was in reference to the implementation, not the idea.  I happen
to believe that calling the compiler on the fly is fraught with subtle
problems, such as difficulties in debugging and possible security holes,
and have seen - in most cases - that eval/exec based solutions are usually
as easily and more understandably done with other mechanism.  And I myself
outlined two such mechanisms which seem to meet your criteria.

>Ruby is made for the people out there who nodded their heads when I
>described my reasoning just now.

There should be a set of reasons to choose one language over another.  It is
not always true that a single language can and should be the best choice.
I have solid experience with Tcl, Perl, Python, C++, C, awk, and Pascal, and
a nodding acquaintance with Fortran, Ruby, APL, Smalltalk, Eiffel, and
Postscript; and that's omitting a slew of so-called "small" languages I've
used and still others I've forgotten I knew.  I believe I have some idea of
when to use those solutions for the application domains I'm in.

Software developers should have nodded their heads when I described my
reasons for why I generally prefer not using your idiom and also why I
have used it in some of my code.  Maybe not agreed with it, but agreed with
the process behind it.  That is independent of the language.  They should
also have some idea of why, amoung all the languages I've used and
considered, I decided to focus for now on Python.

> 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 still not sure about this "less restrictive" bit.  You've clearly said
you are not an experienced Python developer.  I and others here have pointed
out various ways to get what you wanted in Python.  You have also pointed
out
things you have said Python cannot do (eg, modify a module or a class on
the fly); statements which are, in the general sense in which you made them,
incorrecty.

Yes, there are some things which Ruby does better than Python.  On the other
hand, there are some things which Python does better than Ruby.  I listed
some
earlier, but an easy one is that I have found there are a few (rare) times
when multiple inheritance makes sense.  In terms of what the two languages
can do, I feel they are comparable yet dissimilar enough that a linear
"more/less" scale isn't useful and ends up being more argumentative than
anything else.

Arguments over what a language implementation does do is different; in
that case you can start talking about performance, number of supported
architectures, specialized support for platform-specific feathers, size of
the libraries, easy of use for beginning developers, easy of use for
exprienced developers, learning curve in-between, maintainability, etc.
But those do not apply when tryingto judge the concept of "restrictive."


(To flesh out that multiple inheritance preference with an example, I
find MI really useful in exception classes, where I want something to be
a module-specific error and also a standard error, so it can be caught
and used appropriately by both standard Python code and also by code that
understands how to deal with specific nuances of that module's errors.
In other words, the following construct is useful:

  class ModuleKeyError(ModuleError, KeyError):
    def __init__(self, name, lineno):
        ModuleError.__init__(self, lineno)
        KeyError.__init__(self, name)
    def __str__ ....
)

>Some people will like this, and they're the ones who might enjoy
>taking a look at Ruby.

Do you assume that I haven't taken a look at Ruby?  That I haven't
read through the Pickaxe book?  That I haven't followed several months
of c.l.rb?  That I haven't read through at least some the Ruby source
code?  That I've actively discouraged people not to look at Ruby?

If so, you would be wrong.  I've done all of these.  What I have also done
is outlined the problems I have with Ruby and the underlying basis for
those problems as defined by the goals I have, with at least the implicit
request that people correct any misunderstandings I may have.

>The rest of you should stick with Python and thank your lucky stars
>that you don't have to use this silly Ruby thing.

No.  You should take a look at Ruby to see a different way of doing
things.  You should get an appreciation (for those without Smalltalk
experience) for code blocks.  You should judge for yourself the merits
of methods which may end in a '?' (to indicate tests) or '!' (to indicate
a mutable method).  Of a different way of doing modules.  Of the pros
and cons of built-in vs. native threads.  Of the ease of use of Ruby's
garbage collection over the greater platform independence and guaranteed
semantics of CPython's gc.

You should do as others do here on c.l.py and learn from different
languages to understand not only what makes Python fun but where the
warts are, and where other paths through the language wilderness may
take you.  Without c.l.py I might never have heard about Haskell, or
O'Caml, or Icon, or K, or a dozen other languages.

For that is part of the c.l.py way.  And that is also part of the c.l.rb
way if Matz' posts are any indication.

>Now let's all go make fun of some Java people.

While I hope you mean this in jest, that is absolutely not my intent,
nor hope, nor aspiration.

                    Andrew
                    dalke at dalkescientific.com