«

Ben Giddings wrote:
> On Thursday 18 August 2005 17:07, Joe Van Dyk wrote:
>
>>Which is better, Python or Ruby?
>
>
> (checks the mailing list)
>
> Um... Ruby?
>
> But seriously, Python and Ruby are so similar that it will be really hard to
> make a really compelling argument. I'd go with a few things.
>
> 1) Are there people there that miss Perl, or have found Python not as well
> suited to what they're doing as Perl was? Ruby's Perl-like roots may come in
> handy. I think Ruby is a much more suitable language for certain tasks than
> Python because of its Perl roots.

I find this somewhat baffling. I'm aware that Matz was influenced by
certain aspects of Perl, but I really don't see any alleged "Perl roots"
when coding Ruby. (My biased take is that this is something Pythonitas
like to toss out about any language that allows more than one way to do
anything.) There are things common to both languages, but not unique to
the pair.

I used Perl for several years, and was fairly evangelistic about it with
others. I heard about Ruby, was initially put off, gave it another try,
and never regretted it.

I recently had to go poke through some Perl code, and it was truly
foreign. If there were any essential similarities with Ruby, they
eluded me.

I wouldn't try to lure Perl developers to Ruby with any suggestions that
they can go write Ruby code with a Perl mindset or style. That's asking
for trouble.



> Tasks like modifying a bunch of files in
> place, anything dealing with regular expressions, etc. Find the old Perl
> hackers and show them Ruby, see what they think.
>

That's not possible in Python? (Real question; my Python is vague.)


James

--

http://www.ruby-doc.org - The Ruby Documentation Site
http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

On 8/18/05, James Britt <> wrote:
> Ben Giddings wrote:
> > On Thursday 18 August 2005 17:07, Joe Van Dyk wrote:
> >
> >>Which is better, Python or Ruby?
> >
> >
> > (checks the mailing list)
> >
> > Um... Ruby?
> >
> > But seriously, Python and Ruby are so similar that it will be really ha=
rd to
> > make a really compelling argument. I'd go with a few things.
> >
> > 1) Are there people there that miss Perl, or have found Python not as w=
ell
> > suited to what they're doing as Perl was? Ruby's Perl-like roots may c=
ome in
> > handy. I think Ruby is a much more suitable language for certain tasks=
than
> > Python because of its Perl roots.
>=20
> I find this somewhat baffling. I'm aware that Matz was influenced by
> certain aspects of Perl, but I really don't see any alleged "Perl roots"
> when coding Ruby. (My biased take is that this is something Pythonitas
> like to toss out about any language that allows more than one way to do
> anything.) There are things common to both languages, but not unique to
> the pair.
>=20
> I used Perl for several years, and was fairly evangelistic about it with
> others. I heard about Ruby, was initially put off, gave it another try,
> and never regretted it.
>=20
> I recently had to go poke through some Perl code, and it was truly
> foreign. If there were any essential similarities with Ruby, they
> eluded me.
>=20
> I wouldn't try to lure Perl developers to Ruby with any suggestions that
> they can go write Ruby code with a Perl mindset or style. That's asking
> for trouble.

The style is different, sure, but a lot of the Perl shortcuts ($0, $$,
$<, etc) are there, along with ~=3D and those other godawful punctuation
soup operators.

>1) Simple to extend existing applications written in C with Ruby.
>2) Great syntax
>3) Blocks
>4) DRb
>5) Rails

Besides SWIG, py has several mature well-documented libraries for
extensions and inlining c/C++: CXX, boost, weave, pyrex:

http://cxx.sourceforge.net/
http://www.python.org/cgi-bin/moinmo...GettingStarted
http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
http://www.scipy.org/documentation/weave/

Syntax: Mr. Fulton's Ruby Way, appendix B compares Ruby 1.6, python 2.2
(py 2.4's not materially different from 2.2, whereas rb 1.8 was a big
leap forward). Python's oft-criticized O-O
warts_or_philosophical_choices: no truly class-private declaration
("__methORattrib_name" is just a name-mangling procedure; "self" must
always 1st param in method defs; duplication between function and
method libs, e.g. for string processing. You could look at Codezoo, see
waht those folks have picked as well coded, documented, &tested ruby
and python components.

blocks: Guido's definitely paying attention, read the (accepted) PEP:
http://www.python.org/peps/pep-0343.html
+1 for ruby!

the python Drb analog would be pyro:
http://directory.google.com/Top/Comp...uted_Computing

rails analogs: Django, Subway i know nothing about. Rails kicks ass,
just like every intelligent person proclaims out loud at least 1x/hour!

On Thursday 18 August 2005 9:33 pm, James Britt wrote:

> > 1) Are there people there that miss Perl, or have found Python not as
> > well suited to what they're doing as Perl was? Ruby's Perl-like roots
> > may come in handy. I think Ruby is a much more suitable language for
> > certain tasks than Python because of its Perl roots.
>
> I find this somewhat baffling. I'm aware that Matz was influenced by
> certain aspects of Perl, but I really don't see any alleged "Perl roots"
> when coding Ruby. (My biased take is that this is something Pythonitas
> like to toss out about any language that allows more than one way to do
> anything.) There are things common to both languages, but not unique to
> the pair.
>
> I used Perl for several years, and was fairly evangelistic about it with
> others. I heard about Ruby, was initially put off, gave it another try,
> and never regretted it.
>
> I recently had to go poke through some Perl code, and it was truly
> foreign. If there were any essential similarities with Ruby, they
> eluded me.

I came to Ruby from many years of Perl zealotry, and one of the things that
made the switch very, very easy was that when it came to the methods
available on the core classes, they were generally named the same as the
keyword to do the same thing in Perl. So I didn't have to sit in the Pickaxe
class reference and lookup methods to do most of the common stuff. Most of
the time if I just use a method name the same as what the function was in
Perl, it worked.

So, once I adapted to blocks and to using a method call syntax on almost
everything, I was already productively writing Ruby code. The learning curve
between initially reading about Ruby and actually writing useful code was
quite shallow, coming from Perl.


Kirk Haines

On Friday 19 August 2005 04:04 am, Kirk Haines wrote:
> I came to Ruby from many years of Perl zealotry, and one of the things =
that
> made the switch very, very easy was that when it came to the methods
> available on the core classes, they were generally named the same as th=
e
> keyword to do the same thing in Perl. =A0So I didn't have to sit in the
> Pickaxe class reference and lookup methods to do most of the common stu=
ff.
> =A0Most of the time if I just use a method name the same as what the fu=
nction
> was in Perl, it worked.

Same here. After using Perl for a number of years I was trying to move t=
o a=20
language that would grow into larger programs more gracefully than Perl. =
I=20
tried to make the switch to Python three times, but found Python just=20
different enough that it was hard to use Python for the small, jobs that =
I=20
normally used Perl for. It was during my third attempt to pick up Python=
=20
that I saw a posting about Ruby by Dave Thomas. Since I had just finishe=
d=20
reading the Pragmatic Programmer book, I held Dave's opinion in high rega=
rd. =20
I downloaded and installed Ruby and was writing Ruby code within a day. =
I=20
have never used Perl for non-legacy code since the switch.

I'm not sure why switching to Ruby was so much easier than switching to=20
Python. Part of the reason is that I didn't have to keep looking things =
up=20
in Ruby ... things just worked the way I expected.

--=20
-- Jim Weirich http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,=20
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

On 19 ao=FBt 05, at 12:55, Jim Weirich wrote:

> I'm not sure why switching to Ruby was so much easier than =20
> switching to
> Python.

According to my experience, it's because Python is just insanely =20
inconsistent in every single way.

--=20
Luc Heinrich - - http://www.honk-honk.com

Bret Pettichord wrote:

> At 08:18 PM 8/18/2005, Jamey Cribbs wrote:
>
>> Hal convinced me to rewrite KirbyBase and allow the user to specify
>> query syntax using blocks. When I finally figured out how easy it
>> was to add this functionality and how much power it gave the user to
>> specify queries, I was sold.
>
>
> Could you show us an example of this? I'm sure i should be using
> blocks more myself and i'd like to see how others are doing it.

Ok, here is a somewhat simplified code example. Let's say you have a
table that holds information about WWII airplanes. You want to write a
query that selects all planes from the table that belonged to the US and
had a top speed greater than 350mph. First you would write the query,
using a block to specify the actual select condition:

results = plane_tbl.select { |r| r.country == 'USA' and r.speed > 350 }

Notice that Ruby allows you to easily pass around code that keeps it's
local context, you can simply write the query using Ruby, instead of
having to, say, write a string that KirbyBase would have to do an #eval
on to figure out what you want to do.

Now, how is this query we wrote above handled? Here is a greatly
simplified version of KirbyBase's select method:

def select(&select_cond)
result = []
@db.engine.get_recs(self).each do |rec|
result << rec if select_cond.call(rec)
end
return result
end

Notice that the query block is passed in and assigned to the variable
select_cond. Then, KirbyBase loops through all the records in the
table. For each record it executes the block, passing in the values of
the current record to the block. If the return value from the block is
true, then the record is added to the result set. After all records
have been looped through, the result set is returned to user.

Before I re-wrote KirbyBase to use blocks, I had written an earlier
version where the user specifed their query by putting it inside a
string. The select method then parsed the string and built up the query
itself. It was tedious ugly code, parsing the string, trying to make
sure I covered all the ways the user might specify the query string.
Additionally, the user was very limited in the kinds of comparisons they
could do in the query string. Basically, if I the parsing code in the
select method could not handle it, they couldn't do it.

Then, when I switched KirbyBase to handle blocks, that totally changed.
Now, the user has total freedom to write their query the way they want,
because, as long as their query is valid Ruby code, it will work! Even
better, if Matz adds new classes or methods to Ruby, I don't need to
change a line of code of KirbyBase to accomodate it, because, when
KirbyBase executes a query, it is actually Ruby that is doing all the
heavy lifting, since the query is simply Ruby code itself.

This totally sold me on blocks.

Jamey

Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.

On Friday 19 August 2005 9:14 am, Jamey Cribbs wrote:

> Ok, here is a somewhat simplified code example. Let's say you have a
> table that holds information about WWII airplanes. You want to write a
> query that selects all planes from the table that belonged to the US and
> had a top speed greater than 350mph. First you would write the query,
> using a block to specify the actual select condition:
>
> results = plane_tbl.select { |r| r.country == 'USA' and r.speed > 350 }

I *heart* that sort of query syntax. You'll see much the same thing in the
Kansas ORM:

results = ksdbh.select(lanes) {|r| (r.country == 'USA') & (r.speed > 350)}

In this case, method_missing magic is mixed into that in such a way that the
Ruby code becomes a SQL statement for querying a relational database.

It's a great way of interacting with data. Neat to see that KirbyBase is
doing that.


Kirk Haines

James Britt wrote on 8/18/2005 11:33 PM:
> (My biased take is that this is something Pythonitas
> like to toss out about any language that allows more than one way to do
> anything.)

imho, this completely alienates newbies from the language.

when i first learned perl ten years ago or so i did something like this:

$_=$text # do something with $text
if ($text eq "test)
{
print "matched"
}

and it worked. nobody called me names. said i was doing it wrong, etc.

after i learned more perl that kind of thing changed a few steps and i
ended up writing it this way:

$_=$text # do something with $text
print "matched" if /test/i

if i 'tossed out' any language that allowed tim toadie and did it
Python Approved way i would have to learn all the intracasies of
python before being able to write Proper Python Code.

as it turns out NONE of my python code did followed the 'there's only
one way to do it' mantra . i solved that problem though. i stopped
using python

with ruby, i'm SURE that using yield more will give me shorter and
more efficient code. in the mean time i can Get Things Done by writing
ruby code that works for me and so far seems to be a perfectly
acceptable tim toadie...


--
http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

Kirk Haines wrote:
> On Friday 19 August 2005 9:14 am, Jamey Cribbs wrote:
>
> > Ok, here is a somewhat simplified code example. Let's say you have a
> > table that holds information about WWII airplanes. You want to write a
> > query that selects all planes from the table that belonged to the US and
> > had a top speed greater than 350mph. First you would write the query,
> > using a block to specify the actual select condition:
> >
> > results = plane_tbl.select { |r| r.country == 'USA' and r.speed > 350 }
>
> I *heart* that sort of query syntax. You'll see much the same thing in the
> Kansas ORM:
>
> results = ksdbh.select(lanes) {|r| (r.country == 'USA') & (r.speed > 350)}

Good ole Smalltalk

'select' even wormed it's way into OCL v1.1 (p16)
http://www.google.com/url?sa=t&ct=re...BpyQsQGAqO2qDQ


> In this case, method_missing magic is mixed into that in such a way that the
> Ruby code becomes a SQL statement for querying a relational database.
>
> It's a great way of interacting with data. Neat to see that KirbyBase is
> doing that.
>
>
> Kirk Haines