What's better about Ruby than Python?

[John J. Lee]

Re: What's better about Ruby than Python?

aahz@pythoncraf t.com (Aahz) writes:
[color=blue]
> In article <87oeykb22l.fsf @pobox.com>, John J. Lee <jjl@pobox.co m> wrote:[color=green]
> >
> >Rest assured, *definitely* no relation. :-)[/color]
>
> No relation to what?[/color]

T*m*t*y R*e.

Did I miss something?


John

[Kenny Tilton]

Re: What's better about Ruby than Python?



Chris Reedy wrote:[color=blue]
> Doug Tolton wrote:
>[color=green]
>> On Tue, 19 Aug 2003 13:43:11 +0200, Alex Martelli <aleaxit@yahoo. com>
>> wrote:
>>[color=darkred]
>>> Doug Tolton wrote:
>>> ...
>>>
>>>> abstractions and better programmer productivity. Why not add Macro's
>>>> allowing those of us who know how to use them and like them to use
>>>> them. If you hate macros, or you think they are too slow, just don't
>>>> use them.
>>>[/color][/color][/color]


.....

[color=blue]
> I'm curious. Why do you feel such a need for macros? With metaclasses,
> etc., etc., what significant advantage would macros buy you? Do you have
> any examples where you think you could make a significantly crisper and
> easier to read and understand program with macros than without.[/color]

This macro:

(defmacro c? (&body code)
`(let ((cache :unbound))
(lambda (self)
(declare (ignorable self))
(if (eq cache :unbound)
(setf cache (progn ,@code))
cache))))

Let's me write this (for some slot of an instance):

(c? (+ 10 (left self))) ;; self ala smalltalk

Instead of this:

(let ((cache :unbound))
(lambda (self)
(declare (ignorable self))
(if (eq cache :unbound)
(setf cache (+ 10 (left self)))
cache)))

The above macro is a toy version of the real thing, which expands to this:

(make-c-dependent
:code '((+ 10 (left self)))
:rule (lambda (c &aux (self (c-model c)))
(declare (ignorable self c))
(+ 10 (left self))))

Clearly (c? (+ 10 (left self))) is more readable; all the dataflow
wiring is hidden. And the application is more maintainable should I
decide to change the implementation of my dataflow hack.

This kinda thing is when Lispniks use macros, to silently wrap code with
infrastructure necessary to satisfy some frequently arising requirement.

Especially cool above is that I capture the code in symbolic form in a
separate slot for debugging purposes, as well as hand it to the compiler
as the body of the lambda function. Took me way too long to think of
that when I had no idea what lambda was backtracing. But as soon as I
changed the macro, every (c? ) form (and there are hundreds) was debuggable.

I think macros are no harder to learn than an API, and most Lispniks
won't stray to any language that lacks procedural macros (ie, they are
useful), so maybe it comes down to what someone else said in this
thread: Python is not trying to be everything. Fair enough. Let Python
be Python, let Lisp be Lisp.

ie, If someone wants macros, they probably would also like special
variables and closures and lexical scope and multi-methods and they may
as well get it over with and learn Lisp and stop trying make Python more
than it wants to be.


--

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

[Aahz]

Re: What's better about Ruby than Python?

In article <87vfssylkf.fsf @pobox.com>, John J. Lee <jjl@pobox.co m> wrote:[color=blue]
>aahz@pythoncra ft.com (Aahz) writes:[color=green]
>> In article <87oeykb22l.fsf @pobox.com>, John J. Lee <jjl@pobox.co m> wrote:[color=darkred]
>>>
>>>Rest assured, *definitely* no relation. :-)[/color]
>>
>> No relation to what?[/color]
>
>T*m*t*y R*e.
>Did I miss something?[/color]

Yes, you did, but don't worry about it -- I delight in obscure jokes.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz

[Dave Brueck]

Re: Brandon's abrasive style (was Re: What's better about Ruby than Python?)

Ramon Leon Fournier <moncho.leon@gm x.net> wrote in message news:<bhtsck$37 jp5$1@ID-114614.news.uni-berlin.de>...[color=blue]
> Brandon J. Van Every <vanevery@3DPro grammer.com> wrote:[color=green]
> > - Python is not a good language for low-level 3D graphics problems. C++ is
> > better.[/color]
>
> Well, not just for low-level 3D graphics. There are many other things
> you would not code in Python unless you are a complete fool. Your
> companies mail server, for instance.[/color]

Actually, that's not a very good example - Python is *very* well
suited for many types of servers, mail servers included. The I/O heavy
nature of many servers lessens the significance of Python being slow
in terms of raw CPU speed. Lots of I/O can also mean the effects of
the GIL less of a factor on multi-CPU boxes than they otherwise would
be. Finally, given the fact that you don't see too many buffer
overruns and other similar security holes in Python, I'd sleep
*better* at night implementing my server in Python than in C++.

But I do agree with the notion that Python isn't good for *all*
problems, as does everyone else it seems. ;-)

-Dave

[JanC]

Re: What's better about Ruby than Python?

jjl@pobox.com (John J. Lee) schreef:
[color=blue]
> Mind you, I am the type who, when faced with a new language, tends to
> read everything slowly, chew the cud, *then* start writing.[/color]

Sounds familiar, you're not the only "sick puppy"... ;-)

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[JanC]

Re: Why announce a killfile? (was Re: What's better about Ruby than Python?)

"Brandon J. Van Every" <vanevery@3DPro grammer.com> schreef:
[color=blue]
> You and I have different social theories. My social theory is, people
> are very stubborn. Nobody will engage in Right behavior the minute
> you tell them to. But if I killfile people, and tell them why (i.e.
> "Because you are a Troll Hunter, and such people are useless."), then
> someday they may wake up and figure it out. It may be 6 months from
> now, it may be 2 years from now. The point is to have a cumulative
> effect on people's newsgroup behavior.[/color]

You know this proverb: "change the world, start with yourself" ?

--
JanC

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9

[Olivier Drolet]

Re: What's better about Ruby than Python?

Alex Martelli <aleax@aleax.it > wrote in message news:<ExR0b.215 26$zN5.666078@n ews1.tin.it>...[color=blue]
> Doug Tolton wrote:
> ...[color=green]
> > Linux is based on...[/color][/color]

(...)
[color=blue]
>... a zillion mediocre ones.
>
>
> Alex[/color]


Macros, as found in Common Lisp, do not change the underlying language
at all! Common Lisp macros, when run, always expand into 100% ANSI
Common Lisp code! Using macros to become more productive is no
different from using function abstractions or class hierarchies to
become more productive. They all require that you, the programmer,
become familiar with them. Macros don't cause Common Lisp to fork
anymore than function or class abstractions do. They only alter the
readability of "program code" (usually for the better), just like
function or class abstractions do.

Saying that all hell will break loose in the Python community seems
rather unfounded and a bit knee-jerk. None of what you claim would
eventually happen within Python circles is currently happening within
the Common Lisp community. After years of macro use, ANSI Common Lisp
is till the same. Macros don't bypass ANSI committees anymore than
they would the Guidos of this world. On the contrary, they preclude
the need to bypass them in the first place, and all parties end up
getting what they need: on the one hand, a static base language, and
on the other, much greater expressiveness.

Speaking of expressiveness, someone asked on comp.lang.lisp. fr what
macros were good for, concretely, and what quantitative difference
they made in commercial applications (cf. "Macros: est-ce utile ?
(attn Marc)"). The responses (in French) were quite enlightening. It
boils down to using multiple macros, in multiple instances, thus
allowing to reduce total code size (of otherwise pure CL code) by VERY
significant margins. You can think of it as reuse (as per OOP) or as
code compression.

Macros do not have to be used all the time or at all. There are times
when a macro should not be used, e.g. when a function would do just
fine. But they are very powerful. As Paul Graham put it, macros allow
you to program up towards the problem at hand, as opposed to adapting
the problem to fit the language specification. They allow greater
expressiveness, when you need it. They allow you to "use" many lines
of code you no longer have to write. And the lines of code you don't
have to write are also the lines of code you don't have to debug (as
it were).

Cheers.

[Alex Martelli]

Re: What's better about Ruby than Python?

Kenny Tilton wrote:
...[color=blue]
> thread: Python is not trying to be everything. Fair enough. Let Python
> be Python, let Lisp be Lisp.
>
> ie, If someone wants macros, they probably would also like special
> variables and closures and lexical scope and multi-methods and they may
> as well get it over with and learn Lisp and stop trying make Python more
> than it wants to be.[/color]

Hear, hear! Or one you just can't stand the nested-parentheses idea,
then that's what Dylan was designed for: much the same semantics
and power as Lisp, including all of the features you mention!, but with
infix syntax.


Alex

[Alex Martelli]

Re: What's better about Ruby than Python?

Andrew Dalke wrote:
...[color=blue]
> I confess to being fond of the
>
> atom = Atom()
>
> idiom. I know it breaks down, eg, for a function which returns
> a newly created class, but it's too ingrained in me.[/color]

Back when I gave Eiffel a serious try, I easily slid into [the
equivalent of]:
itsAtom = Atom()
[for an instance member variable -- anAtom for a local,
theirAtom for a class-variable, etc -- Robert Martin's idea
to distinguish those lexically in languages which confuse
the scopes]. In other words, naming a basically-anonimous
"generic instance of class Atom" hardly requires a case
sensitive language, IMHO.


Alex

[Alex Martelli]

Re: What's better about Ruby than Python?

Andrew Dalke wrote:
...[color=blue]
> be that way. It's the inability to get into another's shoes -
> to understand view different than one's own - which annoys
> me the most. A deficiency sadly typical of all too many
> enthusiastic new language designers.[/color]

Just as prevalent is the wish to please EVERYone -- that's
how one gets, say, PL/I, or perl... by NOT deliberately refusing
to "get into other's shoes" and rejecting their "different views"
for purposes of inclusion into the new language. Even GvR
historically did some of that, leading to what are now his mild
regrets (lambda, map, filter, ...).


Alex

[Alex Martelli]

Re: What's better about Ruby than Python?

Andrew Dalke wrote:
...[color=blue]
> (Need to use the function instead of a class with __call__
> so that the method gets bound correctly. And I believe[/color]

You could use a class if its instances where descriptors, i.e.
supported __get__ appropriately -- that's basically what
functions do nowadays. See Raymond Hettinger's HOWTO
on descriptors -- a *wonderful* treatment of the subject.


Alex

[Alex Martelli]

Re: What's better about Ruby than Python?

Dave Benjamin wrote:
[color=blue]
> "Alex Martelli" <aleaxit@yahoo. com> wrote in message
> news:bht3bq02v9 p@enews3.newsgu y.com...[color=green]
>> Thus, the direct Python equivalent might be
>>
>> import __builtins__
>> __builtins__.le n = someotherfuncti on
>>
>> and THAT usage is very specifically warned against e.g. in
>> "Python in a Nutshell" -- you CAN do it but SHOULDN'T (again, one
>> can hope to eventually see it "officially " deprecated...!) .[/color]
>
> I agree with your position, more or less, but I am curious - how far do
> you think this deprecation should go? Just changing a function in
> __builtins__? Changing a function in any module? Or changing *anything*
> about a module from the outside?[/color]

Good question! I don't have any preset answers yet. We definitely do
want to impose those restrictions that have "multiple" benefits, i.e.
that both let speed increase (by allowing the compiler to 'inline' the
calls to built-in functions, once it does know they're built-ins) AND
encourage correctness -- but we don't want to cripple ordinary useful
usage, particularly not when the benefits are uncertain. Where the
line should consequently be drawn is not 100% obvious -- which is in
part why nothing about this ended up in Python 2.3, but rather it's all
scheduled for consideration in 2.4.


Alex

[Andrew Dalke]

Re: What's better about Ruby than Python?

Alex:[color=blue]
> Even GvR
> historically did some of that, leading to what are now his mild
> regrets (lambda, map, filter, ...).[/color]

and != vs. <>

Can we have a deprecation warning for that? I've never
seen it in any code I've reviewed.

Andrew
dalke@dalkescie ntific.com

[Andrew Dalke]

Re: What's better about Ruby than Python?

Alex:[color=blue]
> You could use a class if its instances where descriptors, i.e.
> supported __get__ appropriately ... See Raymond Hettinger's
> HOWTO on descriptors -- a *wonderful* treatment of the subject.[/color]

I'm slowing easing my way into this new stuff. I read it through
once, but it didn't all sink in. Could you post an example of how
to use it for my cache example?

Andrew
dalke@dalkescie ntific.com

[Alex Martelli]

Re: Brandon's abrasive style (was Re: What's better about Ruby than Python?)

Ramon Leon Fournier wrote:
[color=blue]
> Brandon J. Van Every <vanevery@3DPro grammer.com> wrote:[color=green]
>> - Python is not a good language for low-level 3D graphics problems. C++
>> is better.[/color]
>
> Well, not just for low-level 3D graphics. There are many other things
> you would not code in Python unless you are a complete fool. Your
> companies mail server, for instance. But you wouldn't do that in C#[/color]

I deeply disagree: Twisted, coded in Python, lets you do a GREAT job
coding such applications as mail servers -- highly scalable, etc etc.
And even without Twisted, Python is splendid for such I/O bound jobs.

[color=blue]
> Granted that my motivation to use Python is different from that of many
> others here. I have work to do, and to finish it as quickly as
> possible. I figured that Python is a great language for people like me,[/color]

I think that's the TYPICAL motivation for using Python: it lets you do
your job with great productivity.

[color=blue]
> BTW: What exactly has "Smell the Windows" to do with the current Ruby
> vs. Python debate? Are you actually serious about learning any of[/color]

I dunno: back when I checked carefully, Python was MUCH better integrated
with Windows, thanks to win32all etc etc, while Ruby perched precariously
on cygwin &c. A Windows-centric view would thus appear to favour Python
over Ruby (unless Ruby's Windows implementation has made great strides).


Alex