Re: deciding between ruby and python

[warning, long post :]

On Tuesday, April 6, 2004, 4:34:20 PM, Ville wrote:

>     Gavin> That's a poor man's substitute.  Seriously.  It means you have to name
>     Gavin> everything you're doing, and pollute the function namespace *for no
>     Gavin> good reason*.  Yes, you can "do it", but it's ugly in comparison.
> 
> You don't really pollute it much, because you can always use the same
> name. The old name (and as such, the old definition too) is clobbered
> by the new name. If you always use big L for this purpose, 
> 
> Also, you can do the deffing inside functions too. So it's not even
> visible at module level.

True.  That's a pretty good compromise.  I'd like to see Ruby support
"functions within functions" more properly, but there's probably some
reason it doesn't fit.  At the moment, if you def within a def, your
inner def actually takes place in the outer scope.  There's a
workaround if you need it, but I dislike workarounds.

>     Gavin> Can you provide an implementation in the same style in Python?  It's
>     Gavin> not that I don't believe Python can count characters, lines and words
>     Gavin> in a string.  But I don't believe it can carry outside state into its
>     Gavin> "substitute for blocks".
> 
> Yes. Python supports lexical closures. The only gotcha is that you
> can't 'assign' the names of free variables to point to new objects,
> i.e. it has to be the same object, though it can be mutated. So you
> can use e.g. length 1 array to contain the other object.

That's an unfortunate limitation.  Just like Java.  Given that
limitation, does it really count as a lexical closure?  (I'm out of my
expert range there.)


> The following code:
> 
> ------------------
> 
> def get_char_counter():
>     chars = [0]
> 
>     def filepusher(f):
>         chars[0] += len(open(f).read())
>         return chars[0]
> 
>     return filepusher
> 
> acc = get_char_counter()
> 
> print acc("/bootsect.dos")
> print acc("/bootsect.dos")
> 
> -------------------
> 
> Prints out:
> 
> -------------------
> 201
> 402
> -------------------

I've seen an example like that before.  I don't understand why the
return value changes.  You are asking for a character count of an
unchanging file.


>     Gavin> # Connection: the database connection is automatically released at
>     Gavin> # the end of the block, including if there is an exception therein.
> 
> try - finally blocks are used for this in Python. 
> 
>     Gavin> # Transaction support: any exception in this block will cause a
>     Gavin> # "ROLLBACK".  If all is fine, a "COMMIT" is performed at the end.
> 
> try:
>    stuff()
> except:
>    rollback()
> else:
>    commit()
> 
> But I admit that the ruby approach seems cleaner here. It's probably
> easier to use and the logic doesn't clutter the code.
> 
>     Gavin> I'd like to see the same program written in Python.  I don't know the
>     Gavin> Python database interface, but I expect it would need to have explicit
>     Gavin> exception handling.  There would also be no automatic releasing of
>     Gavin> resources.
> 
> Back when I did db programming, I didn't think it was such a big
> deal. It seems bigger on the paper, though. 

Quite right.  But power steering in cars is not such a big deal,
either.  It just becomes a hassle to live without once you're used to
it.

>     Gavin> To prove me wrong, please present your best effort at translating the
>     Gavin> database programming example above into Python.  Of course, you may
>     Gavin> disagree with my frame of reference instead, but I think that's pretty
>     Gavin> good.
> 
> Yes, I do indeed disagree with your frame of reference. I just don't
> think this issue such big a deal.

It may not be a "big deal", but that doesn't invalidate the frame of
reference.  It demonstrates higher-level programming as applied to a
very practical domain, which was the purpose of the exercise.

To do 10 transactions, you have to write 10 "try/finally" blocks.  I, on
the other hand, only need to write 1 "try/finally" block.

To do 100 transactions, you have to write 100 "try/finally" blocks.  I
only have to write 1.

And in fact, since the database library implements it for me, I don't
have to write any. There will never be a superficial transaction-
related bug in my code, because there was no opportunity for mistyping
or omitting.

A higher degree of reuse == higher level programming.

And when you apply that across several domains instead of one, it
makes a big difference to your code as a whole.

> you might want to go googling for
> more elaborate discussion - code blocks have indeed been suggested for
> Python, they just didn't happen. It seems to pop up every now and
> then, so perhaps they will be in Python some day if they are deemed
> valuable enough.

I imagine it's hard to see the value of code blocks as an "added
feature".  We're only human, after all.  They are only useful if the
pervade the language.  That way, when you're new to the language, you
see them being used in very useful ways.  That familiarises you with
the concept, and then you go: "hang on, does that mean I can do ____
myself?  Wow, what a cool feature!"  That's my experience, anyway.

That's what really rocks about Ruby: people come up with excellent new
ways of applying the technology that I would (probably) never have
thought of.  And they usually involve getting the computer to make the
programmer's life much easier.

With other languages, the limits of discourse seem to be design
patterns (i.e. arrangements of classes) and refactoring techniques.
Those are certainly worthwhile, but Ruby's flexibility seems to spread
the discussion into a new dimension.  And some design patterns (e.g.
delegate, singleton) are directly implementable in Ruby.  E.g.:

  class DataManager
    include Singleton
    # ...
  end

  DataManager.instance.do_something   # the one and only instance

That's another instance of writing the code (ensuring there's only one
instance of a class) once and using it conveniently.  I doubt there
are any other popular/practical languages that enable this level of
reuse.
  
I acknowledge that sometimes the techniques I speak of are more
focussed on "doing cool things" than "getting things done".  But there
is usually some overlap.  I'd say Ruby is an engine-room of innovation
just as much as it is a practical programming language.  Matz even said
(about continuations) "I just implement the feature; you have to work
out what to do with it." (paraphrased)

My point is that many people benefit from this engine-room side of
Ruby.  Just as nearly every feature of Ruby is swiped from or inspired
by another language, so Ruby is contributing to the evolution of
existing languages (Python, Perl) and design of "new" ones (Groovy).
The contribution comes about by demonstrating the worth of unorthodox
features and approaches.

It's pretty common knowledge in our communities that Python used to
lack certain useful features and this situation was improved after
2.0 or 2.1 or thereabouts (e.g. inheriting built-in classes,
OO-vs-function-call interfaces).  I'm sure it would be acknowledged
that Ruby was a factor in some of the changes.  Well, I'm also pretty
confident that that process is not complete.  Python needed to correct
some of its design mistakes; Ruby does too.  Work is underway on Ruby
2.0, which will be a very bold break from the past.

That is some context in which to view the significance of things like
code blocks (and other features, to be sure).  In fact, the point I
make above probably go a long way to explaining the "difference"
between Python and Ruby (the subject of this thread, after all).  But
they are "just" my opinion, so it doesn't necessarily make good fodder
for when the question invariably comes up.

Cheers,
Gavin