What's better about Ruby than Python?

[Jacek Generowicz]

Re: What's better about Ruby than Python?

Hans Nowak <hans@zephyrfal con.org> writes:
[color=blue]
> Jacek Generowicz wrote:
>
> [re-binding __builtins__ considered harmful]
>
> I see your point. The obvious answer would be "so don't do that,
> then". Of course, the same answer would apply to writing abusive
> macros.[/color]

Exactly.
[color=blue]
> Python usually strikes a good balance between being permissive and
> restrictive.[/color]

In your opinion. The opinions of others, as to where a "good balance"
lies, will be different. And that's just fine. That's why we have
different languages.

I happen to agree that Python strikes a good balance. I also think
that Common Lisp strikes a good balance. The position of "good
balance" is a function of the language's audeince.
[color=blue][color=green]
> > Just because a stupid or malicious programmer could do "bad things" is
> > not a reason to reduce a language's power. (You end up with Java.)[/color]
>
> You are right, but one could wonder if the drawbacks don't outweight
> the benefits. Python is already powerful as it is (compared to
> languages other than Lisp ;-). I'm not sure if powerful macros would
> do much good.[/color]

Well, with an interactive language[*] you can easily get two types of
programmers: the providers, and the users. A good macro facility
allows the provider types to create very useful abstractions for the
user types. The user types can use those abstractions without having
the faintest clue that they are built using macros, and can happily
program in the language without ever writing one of their own. (A bit
like metaclasses.)

Just because there are macros or metaclasses in a language, does not
mean that everyone needs to know about them, while everyone can
benefit from them.
[*] I guess that this is not exclusive to interactive languages, but I
suspect it's more marked.

But, wrt macros in Python, I don't really see what Python macros would
look like. Lisp code is represented in a fundamental, hierarchical,
easily transformable built-in data type. This ain't true for Python.

Sometimes I think "if Python had Lisp-like macros, what I am trying to
achieve right now would be so much easier". This doesn't mean that I
would necessarily advocate the inclusion of macros in Python. What I
object to, is the suggestion (which has been made repeatedly around
the thread) that macros are evil and should be avoided, and that
macros are responsible for the fragmentation/death of Lisp.

Macros are great. If a good, Pythonic macro system could be invented,
I am sure that it could be put to great use, and that it would not
engender the death of Python. I am not sure that such a system can be
invented. I do not suggest that such a system _should_ be added to
Python.

[Andrew Dalke]

Re: What's better about Ruby than Python?

Kenny Tilton:[color=blue][color=green][color=darkred]
> > > as when we go for the
> > > productivity win of untyped variables and give up on bugs strong[/color][/color][/color]
static[color=blue][color=green][color=darkred]
> > > typing is supposed to find.[/color][/color][/color]

Jacek Generowicz:[color=blue]
> Note that Kenny said "untyped _variables_" not "untyped objects" or
> "untyped language".[/color]

Ahh, I hadn't caught that.

I did know Lisp had strong dynamic typing with optional static typing,
which was why I was surprised he mentioned it. I still don't understand
why he said it given that Python similarly meets the quoted statement.

Andrew
dalke@dalkescie ntific.com

[Kenny Tilton]

Re: What's better about Ruby than Python?



Andrew Dalke wrote:[color=blue]
> Kenny Tilton:
>[color=green][color=darkred]
>>>>as when we go for the
>>>>productivit y win of untyped variables and give up on bugs strong
>>>[/color][/color]
> static
>[color=green][color=darkred]
>>>>typing is supposed to find.
>>>[/color][/color]
>
> Jacek Generowicz:
>[color=green]
>>Note that Kenny said "untyped _variables_" not "untyped objects" or
>>"untyped language".[/color]
>
>
> Ahh, I hadn't caught that.
>
> I did know Lisp had strong dynamic typing with optional static typing,
> which was why I was surprised he mentioned it. I still don't understand
> why he said it given that Python similarly meets the quoted statement.[/color]

?? I was just giving another example of how lisp errs on the side of
letting us shoot ourselves in the foot. I was not saying anything about
Python.

--

kenny tilton
clinisys, inc

http://www.tilton-technology.com/

---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
-- Bob Uecker

[Andrew Dalke]

Re: What's better about Ruby than Python?

Mario S. Mommer:[color=blue]
> Lisp is simple.
>
> (<operator> <item-1> <item-2> ...)
>
> Where's the problem?[/color]

Quantum mechanics is simple. It's just H | psi> = E | psi>

What's H mean? And psi? And bra-ket notation?

The reason my original forays into Lisp around 1990 failed was
because the documentation I had for learning it didn't talk about
anything I found interesting, like doing file I/O and graphics. It
went on-and-on about data structures and manipulating them.

My later attempts were by trying to customize my Emacs LISP
setup, and getting various errors because I didn't know the
quoting rules well enough.

Since then it's been limited to incidental learning, like seeing examples
and trying to figure them out. Eg, consider Gabriel's "Worse is
Better" essay. The section "Good Lisp Programming is Hard"

http://www.ai.mit.edu/docs/articles/good-news/subsubsection3.2.2.4.html

gives this example

(defun make-matrix (n m)
(let ((matrix ()))
(dotimes (i n matrix)
(push (make-list m) matrix))))

(defun add-matrix (m1 m2)
(let ((l1 (length m1))
(l2 (length m2)))
(let ((matrix (make-matrix l1 l2)))
(dotimes (i l1 matrix)
(dotimes (j l2)
(setf (nth i (nth j matrix))
(+ (nth i (nth j m1))
(nth i (nth j m2)))))))))

and says the above is both "absolutely beautiful, but it adds
matrices slowly. Therefore it is excellent prototype code and
lousy production code."

I've done a lot of matrix math, but even now cannot simply
look at the above code to figure out what it does, much less
does wrong. But I can figure them out from, say, Java,
in which I have no programming experience at all.

I've also looked at Lisp code when evaluating a package
written in Lisp. I was able to figure that library better than
the above, partially because I had already looked at 15 other
packages which did the same task, so knew the structure
of the solution. I turned out that the Lisp code was no more
powerful or flexible than the ones written in the other languages.
I didn't see good reasons to use Lisp for the problems in my
domain.
[color=blue]
> You shouldn't confuse success with quality. For experimental evidence
> look at music charts. On the other hand, if people feel more
> confortable with python, then so be it.[/color]

Quips are easy: "You shouldn't confuse power with quality."
[color=blue][color=green]
> > And I assert that it's because Lisp as a language does not encourage
> > the sort of code sharing that the languages I mentioned above do.[/color]
>
> This is ridiculous. You don't know Lisp so you do not have an idea
> (hint: what you say is wrong), and thus you shouldn't be saying this.[/color]

Not being able to program in Lisp doesn't mean I don't know anything
about it. I've read the histories, the articles like Gabriel's, listened
to others as they talk about their experiences with Lisp, and decisions
to use an alternate language. I understand the decision to emphasize
its parse tree based approach over a more syntax oriented one. And
as you say, the semantics in Lisp are for the most part shared with
other languages.
[color=blue][color=green]
> > So while it is very expressive for a single person, a single person
> > can only do so much.[/color]
>
> People regularly work in teams on lisp projects. Is that just an
> illusion of mine?[/color]

No. My take on things is that the people who do use Lisp these days
are self-selected for those who either 1) do things alone, ie, can and
will build everything from scratch, or 2) work hard at making sure
their code can be used by others. By "work hard" I mean smart
people willing to focus on the community and learn about the 7
or so different ways of saying 'equals' and the importants of closures
and all the other things needed to become good Lisp programmers.

The people I know focus mostly on developing new computational
techniques and only want to implement that part of the code, pulling
in code from elsewhere if possible. Hence, not #1 nor #2. (There
are some #1 projects, and the #2 people are almost invariable from
CS, learning Lisp first and biology second.)

In other words, the overlap between the types of people who are
good at programming in Lisp and those who decide upon a career
in computational life sciences is low.

Another possibilty I'm considering now is that the additional
flexibility that Lisp has, eg, for making frameworks, isn't needed
for the programming problems faced in this field, which for the
most part are either data munging or compute-bound algorithmics.
When then choose a more flexible language of a lesser one is
easier to learn and use? But a real Lisper would, I think, argue
that it means those tools are available for the few times it is needed.

Andrew
dalke@dalkescie ntific.com

[Hung Jung Lu]

Re: What's better about Ruby than Python?

Alexander Schmolck <a.schmolck@gmx .net> wrote in message[color=blue]
> To recap: usually, if I change a class I'd like all pre-existing
> instances to become updated ...... AFAIK doing this in a
> general and painfree fashion is pretty much impossible in python[/color]

If I understand correctly what you want, then it is possible and
relatively painfree in Python. Please let me know if the following
snippet is ok.

#
# example of replacing a class in Python
#

import weakref

class InstanceAware:
dict = weakref.WeakVal ueDictionary()
def __init__(self):
self.__class__. dict[id(self)] = self
def __str__(self):
return 'Hello from %s class instance with id=%s' %
(self.__class__ .__name__, id(self))

def replace_class(O ldClass, NewClass):
olddict = OldClass.dict
newdict = NewClass.dict
for instance_id in olddict.keys():
instance = olddict[instance_id]
newdict[instance_id] = instance
instance.__clas s__ = NewClass
del OldClass

class A(InstanceAware ):
dict = weakref.WeakVal ueDictionary()

class B(InstanceAware ):
dict = weakref.WeakVal ueDictionary()

x = A()
y = A()
z = A()

print '--- Class A has %d instances' % len(A.dict)
print x
print y
print z

del z
replace_class(A , B)

print '--- Class B has %d instances' % len(B.dict)
print x
print y

output:

--- Class A has 3 instances
Hello from A class instance with id=12072832
Hello from A class instance with id=12177240
Hello from A class instance with id=15770208
--- Class B has 2 instances
Hello from B class instance with id=12072832
Hello from B class instance with id=12177240

regards,

Hung Jung

[Terry Reedy]

Re: What's better about Ruby than Python?


"Mario S. Mommer" <m_mommer@yahoo .com> wrote in message
news:fzoeyihycs .fsf@cupid.igpm .rwth-aachen.de...[color=blue]
> Lisp is simple.
>
> (<operator> <item-1> <item-2> ...)
>
> Where's the problem?[/color]

The very uniformity of everything (including operators?) being a
possibly recursive list and the actual practice of relatively deep
(compared to Python and similar languages) nesting. If a lisp
expression ends with 10 to 20 closing parentheses (which I have seen),
then there were at least 10 to 20 pending operations waiting to be
closed. This many layers is a bit much for many or most people.
There is also the 'problem' of having to read inside out and
backwards. Ok for a line or two, less ok for multiple lines.

Consider the opposite extreme for an accumlator-based machine:

Assembly is simple.

<operator> <simple-operand>

Where's the problem? The very uniformity of doing everything in
sequential baby steps. Once people learn and understand the baby
steps, bigger chunks like
discrim = sqrt(b*b-4*a*c)
are easier to grasp than the assembler equivalent. Empirically, it
seems that most people prefer the mix of steps with expressions to
either extreme of all steps or all expression, even though both
syntaxes express function composition.
[color=blue]
> Granted, you need an editor that helps you to match the parens[/color]

This may make deep nesting more manageable, but does not make it
shallower. Yes, one could also write a 10-line, 10-layer expression
in Python, but I doubt I would.

Terry J. Reedy

[Borcis]

Re: What's better about Ruby than Python?

Andrew Dalke wrote:[color=blue]
>
> Quantum mechanics is simple. It's just H | psi> = E | psi>
>
> What's H mean? And psi? And bra-ket notation?
>
> The reason my original forays into Lisp around 1990 failed was
> because the documentation I had for learning it didn't talk about
> anything I found interesting, like doing file I/O and graphics. It
> went on-and-on about data structures and manipulating them.
>
> My later attempts were by trying to customize my Emacs LISP
> setup, and getting various errors because I didn't know the
> quoting rules well enough.[/color]

The only thing I ever did in (X)emacs was a nicely working code animator for
MOO procedures, actually it was a client-server thing, there was a reversible
code decorator, and the decoration led the code upon execution by the MOO to
surround each one of its steps by a handshake with the XEmacs client, that the
latter converted to an animating transformation of the source code text before
the user's eyes and control. I was left with the impression that Xemacs (and
its lisp) were dependable.
[color=blue]
>
> Since then it's been limited to incidental learning, like seeing examples
> and trying to figure them out. Eg, consider Gabriel's "Worse is
> Better" essay. The section "Good Lisp Programming is Hard"
> http://www.ai.mit.edu/docs/articles/...on3.2.2.4.html
> gives this example
>
> (defun make-matrix (n m)
> (let ((matrix ()))
> (dotimes (i n matrix)
> (push (make-list m) matrix))))
>
> (defun add-matrix (m1 m2)
> (let ((l1 (length m1))
> (l2 (length m2)))
> (let ((matrix (make-matrix l1 l2)))
> (dotimes (i l1 matrix)
> (dotimes (j l2)
> (setf (nth i (nth j matrix))
> (+ (nth i (nth j m1))
> (nth i (nth j m2)))))))))
>
> and says the above is both "absolutely beautiful, but it adds
> matrices slowly. Therefore it is excellent prototype code and
> lousy production code."[/color]

The pythonist can only wonder, before such code, whether the transform
consisting in replacing all parentheses with zeroes (eg null strings) is
reversible; and how it could be doctored to be reversible, if it isn't.

On a sideline, shouldn't the "absolute beauty" of the code mean that a
good enough compiler should *understand* well enough its intent
to substitute more appropriate code ? Of course, we would supply the compiler
simultaneously with the complete layer of methods.

The next step would be to integrate our intelligent compiler in the IDE, so
that the student having typed the above would be proposed coherent completion
upon typing " (defun substract-matrix ..." or " (defun multiply-matrix ..." :)

Cheers B

[Kenny Tilton]

Re: What's better about Ruby than Python?

Terry Reedy wrote:[color=blue]
> "Mario S. Mommer" <m_mommer@yahoo .com> wrote in message
> news:fzoeyihycs .fsf@cupid.igpm .rwth-aachen.de...
>[color=green]
>>Lisp is simple.
>>
>>(<operator> <item-1> <item-2> ...)
>>
>>Where's the problem?[/color]
>
>
> The very uniformity of everything (including operators?) being a
> possibly recursive list and the actual practice of relatively deep
> (compared to Python and similar languages) nesting. If a lisp
> expression ends with 10 to 20 closing parentheses (which I have seen),[/color]

Not often, I hope. Then again, I for one hate too much code in one
function or even too much code in one source file! So I break things up
a lot. Funny thing is, I do not end up with a lot of functions for
functions' sake, things just tend to be reusable.

This one is really personal taste. I think I have a very low tolerance
for lotsa code in one place.

OTOH, lotsa closing parens means highly functional code. That is very
good for code quality.

kenny

[Michele Simionato]

Re: What's better about Ruby than Python?

Hans Nowak <hans@zephyrfal con.org> wrote in message news:<mailman.1 061515908.27282 .python-list@python.org >...
[color=blue]
> One of Python's strengths is that you can create powerful abstractions with
> functions and classes. But no matter what you do with these, they will always
> be functions and classes that adhere to some common language rules. There is
> no way to go "over the top" and change the language proper.[/color]

This is a mere illusion. There are metaclasses and descriptors now.
[color=blue]
> Right now I can
> read everybody's Python code (unless deliberately obfuscated); this would
> change if there were macros that were so powerful that they would change
> language constructs, or allow new ones. Maybe they would make your problesm
> easier to solve, but Python itself would lose in the long run.
>
> My $0.02,[/color]

We already have things worse than macros. Still I am not suggesting we
should add them, because of KISS. But the idea of Python being well
behaved is a mere illusion, however well kept. See my other posts
on "macros revisited" for more on this.

Michele Simionato, Ph. D.
MicheleSimionat o@libero.it

http://www.phyast.pitt.edu/~micheles

--- Currently looking for a job ---

[Michele Simionato]

Re: What's better about Ruby than Python?

Hans Nowak <hans@zephyrfal con.org> wrote in message news:<mailman.1 061515908.27282 .python-list@python.org >...
[color=blue]
> One of Python's strengths is that you can create powerful abstractions with
> functions and classes. But no matter what you do with these, they will always
> be functions and classes that adhere to some common language rules. There is
> no way to go "over the top" and change the language proper.[/color]

This is a mere illusion. There are metaclasses and descriptors now.
[color=blue]
> Right now I can
> read everybody's Python code (unless deliberately obfuscated); this would
> change if there were macros that were so powerful that they would change
> language constructs, or allow new ones. Maybe they would make your problesm
> easier to solve, but Python itself would lose in the long run.
>
> My $0.02,[/color]

We already have things worse than macros. Still I am not suggesting we
should add them, because of KISS. But the idea of Python being well
behaved is a mere illusion, however well kept. See my other posts
on "macros revisited" for more on this.

Michele Simionato, Ph. D.
MicheleSimionat o@libero.it

http://www.phyast.pitt.edu/~micheles

--- Currently looking for a job ---

[Michele Simionato]

Re: What's better about Ruby than Python?

"Andrew Dalke" <adalke@mindspr ing.com> wrote in message news:<Qfh1b.265 4$Ej6.1149@news read4.news.pas. earthlink.net>. ..[color=blue]
> For observational evidence of this, I suggest my own
> subfields, computational biology and computational chemisty.
> In the first there are bioperl, biopython, biojava, and bioruby,
> all with active participants and a yearly confererence organized
> by open-bio.org. But there is only a rudimentary biolisp project
> with minimal code available and just about no community
> involvement. In the latter, Python takes the lead by far over
> any language other than C/C++/Fortran with commercial support
> for a couple toolkits and several more free ones beyond that.
> There's even a workshop in a couple weeks on the representation
> of biomolecules for Python. There are also some Java and C++
> toolkits for chemical informatics. And again, there is no Lisp
> involvement.
>
> I ask you why. And I assert that it's because Lisp as a
> language does not encourage the sort of code sharing that
> the languages I mentioned above do. So while it is very
> expressive for a single person, a single person can only
> do so much.
>
> Andrew
> dalke@dalkescie ntific.com[/color]

I would say simply that Lisp has a much steeper curve than Python
& comparable languages. Scientists want to do science, not CS.
Moreover, they typically don't have very hard programming problems
(I mean conceptually, not numerically). So, a scripting language is much
better for somebody who is simply a CS amateur, with a different field
of research. On the other hand, a CS academics would probably prefer
Lisp/Scheme over a scripting language, at least I think.

That said, I do agree that the presence of hundreds of dialects works
against the adoption of Lisp. For instance, this stopped me (together
with other factors).

Michele Simionato, Ph. D.
MicheleSimionat o@libero.it

http://www.phyast.pitt.edu/~micheles

--- Currently looking for a job ---

[Michele Simionato]

Re: What's better about Ruby than Python?

"Andrew Dalke" <adalke@mindspr ing.com> wrote in message news:<Qfh1b.265 4$Ej6.1149@news read4.news.pas. earthlink.net>. ..[color=blue]
> For observational evidence of this, I suggest my own
> subfields, computational biology and computational chemisty.
> In the first there are bioperl, biopython, biojava, and bioruby,
> all with active participants and a yearly confererence organized
> by open-bio.org. But there is only a rudimentary biolisp project
> with minimal code available and just about no community
> involvement. In the latter, Python takes the lead by far over
> any language other than C/C++/Fortran with commercial support
> for a couple toolkits and several more free ones beyond that.
> There's even a workshop in a couple weeks on the representation
> of biomolecules for Python. There are also some Java and C++
> toolkits for chemical informatics. And again, there is no Lisp
> involvement.
>
> I ask you why. And I assert that it's because Lisp as a
> language does not encourage the sort of code sharing that
> the languages I mentioned above do. So while it is very
> expressive for a single person, a single person can only
> do so much.
>
> Andrew
> dalke@dalkescie ntific.com[/color]

I would say simply that Lisp has a much steeper curve than Python
& comparable languages. Scientists want to do science, not CS.
Moreover, they typically don't have very hard programming problems
(I mean conceptually, not numerically). So, a scripting language is much
better for somebody who is simply a CS amateur, with a different field
of research. On the other hand, a CS academics would probably prefer
Lisp/Scheme over a scripting language, at least I think.

That said, I do agree that the presence of hundreds of dialects works
against the adoption of Lisp. For instance, this stopped me (together
with other factors).

Michele Simionato, Ph. D.
MicheleSimionat o@libero.it

http://www.phyast.pitt.edu/~micheles

--- Currently looking for a job ---

[Neil Hodgson]

Re: What's better about Ruby than Python?

David Abrahams:
[color=blue]
> BTW, the C++ preprocessor is a fairly weak macro system. A higher
> level metaprogramming facility that knows more about the underlying
> language could be a lot cleaner, clearer, safer, and more expressive.[/color]

What do you think of OpenC++?

http://www.csg.is.titech.ac.jp/~chiba/openc++.html

Neil

[Neil Hodgson]

Re: What's better about Ruby than Python?

David Abrahams:
[color=blue]
> BTW, the C++ preprocessor is a fairly weak macro system. A higher
> level metaprogramming facility that knows more about the underlying
> language could be a lot cleaner, clearer, safer, and more expressive.[/color]

What do you think of OpenC++?

http://www.csg.is.titech.ac.jp/~chiba/openc++.html

Neil

[Jacek Generowicz]

Re: What's better about Ruby than Python?

mis6@pitt.edu (Michele Simionato) writes:
[color=blue]
> That said, I do agree that the presence of hundreds of dialects works
> against the adoption of Lisp. For instance, this stopped me (together
> with other factors).[/color]

So why did the presence of "hundreds of dialects" of scripting
languages not stop you adapting a scripting language ?

As I've mentioned elsewhere; objecting to the existence of multiple
dialects of Lisp (essentially, languages which represent their source
code in a form they can easily manipulate), as as daft as objecting to
the existence of multiple dialects of the Algol Language family, or to
the existence of multiple languages with significant indentation.