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.
As somebody who used/uses Perl a great deal I found Ruby felt very natural.
Most of the things I liked in Perl (unless, postfix conditionals, closures, procs, map, can write in procedural/function/OO styles, etc.) are in Ruby, and most of the things I hate (clumsy OO syntax, clumsy exception syntax, object/non-object divide, etc.) are absent.
Of course Ruby isn't just Perl++. It has a whole bunch if interesting and useful differences in approach. However, when it comes to the way they treat the developer Perl and Ruby (and Lisp come to that) seem to sit on one side of a divide with languages like Java and Python on the other.
[snip]
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.
I think the issue may be that there isn't /a/ Perl mindset or style. Sure the Perl folk who enjoy writing obfuscated line noise are not going to enjoy Ruby. The Perl folk who are happily writing reliable, maintainable code love it too death.
course, things like the indentation thing; Ruby feeling more like object-orientated stuff was baked in rather than added on; Python being a little faster, etc.
You must be kidding! It is Python that has had the object oriented stuff baked in. Ruby was designed from ground up to be object oriented (every thing, even a number, even nil, is an object!)
OOPS, when you wrote 'baked in' I read 'slapped on'!
#: Jamey Cribbs changed the world a bit at a time by saying on 8/19/2005 3:18 AM :#
Now, you can still do closures in Python by actually passing a named function, but using blocks is just so much more elegant.
What about lambdas? (afaik python has lambdas and a notion called maps - but about the 2nd I am not pretty sure).
I think I mentioned Python's lambda a paragraph or two above the one you quoted (I don't have my original post in front of me so I can't say for sure). You can definitely do closures with Python's lambda, but it is not as powerful as Ruby's block because a Python lambda can only have one statement in it and it cannot be an assignment. You might think that this is not that important. Well, being able to do assignment(s) in a block allows me to program KirbyBase to handle this:
plane_tbl.update { |r| r.name == 'P-51' }.set do |r|
r.speed = 405
r.range = 1210
end
This says, for the record where name equals P-51, change the speed to 405mph and the range to 1,210 miles. I couldn't do this with a lambda in Python.
Same here. After using Perl for a number of years I was trying to move to a
language that would grow into larger programs more gracefully than Perl. I
tried to make the switch to Python three times, but found Python just
different enough that it was hard to use Python for the small, jobs that I
normally used Perl for. It was during my third attempt to pick up Python
that I saw a posting about Ruby by Dave Thomas. Since I had just finished
reading the Pragmatic Programmer book, I held Dave's opinion in high regard.
I downloaded and installed Ruby and was writing Ruby code within a day. I
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
Python. Part of the reason is that I didn't have to keep looking things up
in Ruby ... things just worked the way I expected.
···
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 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.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
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
···
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:
(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
Absolutely. Over time, one hopes to acquire good taste in coding style and temperament, but typically the goal is to get code to run, and run right, and then refactor to beauty.
#: Jamey Cribbs changed the world a bit at a time by saying on 8/21/2005 4:48 AM :#
Alexandru Popescu wrote:
#: Jamey Cribbs changed the world a bit at a time by saying on 8/19/2005 3:18 AM :#
Now, you can still do closures in Python by actually passing a named function, but using blocks is just so much more elegant.
What about lambdas? (afaik python has lambdas and a notion called maps - but about the 2nd I am not pretty sure).
I think I mentioned Python's lambda a paragraph or two above the one you quoted (I don't have my original post in front of me so I can't say for sure). You can definitely do closures with Python's lambda, but it is not as powerful as Ruby's block because a Python lambda can only have one statement in it and it cannot be an assignment.
Thanks Jamey. Wasn't aware of this limitation.
:alex |.::the_mindstorm::.|
ps: sorry I have completely missed that part (it's 6am :-s). sorry again
You might think
···
that this is not that important. Well, being able to do assignment(s) in a block allows me to program KirbyBase to handle this:
plane_tbl.update { |r| r.name == 'P-51' }.set do |r|
r.speed = 405
r.range = 1210
end
This says, for the record where name equals P-51, change the speed to 405mph and the range to 1,210 miles. I couldn't do this with a lambda in Python.
I think I mentioned Python's lambda a paragraph or two above the one you quoted (I don't have my original post in front of me so I can't say for sure). You can definitely do closures with Python's lambda, but it is not as powerful as Ruby's block because a Python lambda can only have one statement in it and it cannot be an assignment. You might think that this is not that important. Well, being able to do assignment(s) in a block allows me to program KirbyBase to handle this:
Oops! I should have said, "because a Python lambda can only have an expression, not a statement...". Here's a quote from the Python Tutorial: "They are syntactically restricted to a single expression". And here's a quote from Python's Language Reference: "Note that functions created with lambda forms cannot contain statements".
> 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:
regexp = Regexp.new( "test", Regexp::IGNORECASE )
print "matched" if regexp.match( text )
Ruby tends towards one-two line solutions that are still readable...
... ok, the rest of this is preaching to the choir, but I figured it
was worth noting.
I don't know how many people caught it when they looked at the
computer language shootout ... but if you slide to the bottom of the
language vs language page it will show you the summed scores for each
language as to how many tests it had won in each category of scoring (
memory usage, cpu time, etc ). The most interesting statistics that
the shootout provides is the comparisons of lines of code ... ( at
least this is important to me )
To be able to have the expressiveness that Ruby has and be able to get
as much done in as few lines of READABLE code and do that more often
than other programming languages ... that's really cool. That's how I
sell Ruby to those that ask "Why Ruby?" ... Because I get more done,
faster.
With Python I was ALWAYS digging back through the reference materials
or calling dir( blah ) and doc( blah.crud ) ... just to figure out how
to call things and what to call, things don't always make sense in
Python ...
Ruby was go from day one ... and has been go ever since.
Anyways, 'nuf said. Thanks Matz.
j.
···
On 8/19/05, James Britt <james_b@neurogami.com> wrote:
tony summerfelt wrote:
> 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
>
Absolutely. Over time, one hopes to acquire good taste in coding style
and temperament, but typically the goal is to get code to run, and run
right, and then refactor to beauty.
Absolutely. Over time, one hopes to acquire good taste in coding style and temperament, but typically the goal is to get code to run, and run right, and then refactor to beauty.
Oops! I should have said, "because a Python lambda can only have an expression, not a statement...". Here's a quote from the Python Tutorial: "They are syntactically restricted to a single expression". And here's a quote from Python's Language Reference: "Note that functions created with lambda forms cannot contain statements".
[snip]
Of course Python might not have lambda's much longer. See <The fate of reduce() in Python 3000; for Guido's comments on why lambda, reduce and friends may soon meet their demise in Python.
...typically the goal is to get code to run, and run right, and
then refactor to beauty.
Is that what they teach in schools these days? What happened to
software engineering?
He makes a prototype, good engineering practice.
It runs Right, no? So there must be some spec somewhere. I believe a
bunch of unit tests does take care of that.
He then refactors it to become "better".
Given a decent prototype (thank you, Ruby), that's not so bad as it may
sound.
def select(&select_cond)
result = @db.engine.get_recs(self).each do |rec|
result << rec if select_cond.call(rec) end
return result
end
Why not:
def select
result = @db.engine.get_recs(self).each { |rec| result << rec if yield rec }
result
end
Or if get_recs returns an Enumerable:
def select(&select_cond) @db.engine.get_recs(self).select(&select_cond)
end
Or if not:
def select(&select_cond) #this is probably not very performant @db.engine.get_recs(self).extend(Enumerable).select(&select_cond)
end
Well, it's like I said in my original post, this was an example of a *greatly* simplified #select method in KirbyBase. In the actual method, there's a *lot* more going on.
That is software engineering when one has a list of business requirements, and
a timeframe in which to deliver a solution to those requirements.
Beauty is a secondary consideration to pragmatisism and efficiency. Sometimes
one will get both at the same time, but when there is a deadline to meet, if
something has to be sacraficed, it is beauty.
The customer rarely cares if the implementation is elegant so long as the
implementation does what the customer asks for, and is delivered when the
customer wants it, So that is software engineering.
Kirk Haines
···
On Saturday 20 August 2005 3:36 am, Chris Game wrote:
James Britt wrote:
> ...typically the goal is to get code to run, and run right, and
> then refactor to beauty.
Is that what they teach in schools these days? What happened to
software engineering?
