Python vs Ruby!

[Devin Mullins]

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

Sorry, can't help it, it's like a tic. YMMV.

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

results = ksdbh.selectPlanes) {|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.

That is awesome, and my hat is off to you.

Devin

 

[James Britt]

James Britt wrote on 8/18/2005 11:33 PM:



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.

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

 

[Jeff Wood]

or=20

regexp =3D Regexp.new( "test", Regexp::IGNORECASE )
print "matched" if regexp.match( text )

Ruby tends towards one-two line solutions that are still readable...=20

... 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.

=20
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.
=20
James
=20
--
=20
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
=20
=20

--=20
"So long, and thanks for all the fish"

Jeff Wood

 

[Chris Game]

...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?

 

[Kero]

...typically the goal is to get code to run, and run right, and

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.

+--- Kero ------------------------- kero@chello@nl ---+
| all the meaningless and empty words I spoke |
| Promises -- The Cranberries |
+--- M38c --- http://members.chello.nl/k.vangelder ---+

 

[Jamey Cribbs]

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.

Jamey

 

[Kirk Haines]

Is that what they teach in schools these days? What happened to
software engineering?

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

 

[Devin Mullins]

James Britt wrote:


Is that what they teach in schools these days? What happened to
software engineering?

They taught software practice when you went to school? I learned from
Google.

He's talking about XP. Get with the times, man.

Beauty is a secondary consideration to pragmatisism and efficiency.

It's not necessarily any different. http://www.paulgraham.com/taste.html

Devin

 

[Kirk Haines]

It's not necessarily any different. http://www.paulgraham.com/taste.html

I didn't say it was. But the consideration of beauty is secondary. Sometimes
beauty coincides with getting the code working, but sometimes it doesn't. As
is seen on this list every time someone presents a problem to solve, there
are usually many ways to solve the problem, and the first respondents often
don't present the most beautiful solution.

Without the luxury of time, software engineering often means finding the first
solution that works, using it, and then moving on. After project goals are
met, some of the "it works, but it's ugly" pieces can be revisited and can
get a little beauty applied to them.

As a recent example, look at the request by Brock Weaver the other day for an
elegant Ruby way to iterate over files in a directory, flipping .mp3
and .temp file suffixes. His solution worked, but there were more elegant
solutions, and as the thread progressed, there was a trend towards shorter,
more elegant solutions being submitted to the thread. "It works" was solved
well before "it works, and is elegant".


Kirk Haines

 

[James Britt]

James Britt wrote:




Is that what they teach in schools these days? What happened to
software engineering?

Well, school never taught me to refactor, period. But "software
engineering" is an interesting misnomer.

http://rubyurl.com/6aI

AKA

http://alistair.cockburn.us/crystal/articles/teoseatsoecg/theendofsoftwareengineering.htm


also http://www.itconversations.com/shows/detail175.html

"In this insightful interview with IT Conversations' producer Doug Kaye,
Alistair explains how he uses games as a model for software projects,
and how he discovered that the term "software engineering" was created
on a whim in 1968. He also discusses the American and European aversion
to copying: the not-invented-here (NIH) syndrome. "If you want to become
a senior designer, you don't get there by finding all the components
that are free on the web" even though "that's very cost effective, the
customer likes it, the boss likes that, but you didn't get promoted." [
Hear clip: [http://rubyurl.com/DeN] ]."


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

 

[James Britt]

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".

And "run right" can mean all sorts of things depending on the
requirements. So one may have to consider memory consumption, disk
usage, start-up times, and all the other little details aside from
simply running without errors.

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

 

[Adrian Howard]

On 19 Aug 2005, at 04:33, James Britt wrote:
[snip]

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.

That's been my experience anyway.

Adrian

 

[Corey Lawson]

Well, in "hardware engineering", the first thing is probably a
prototype or proof-of-concept. It's a hack. Some of them can be quite
ugly (sheet steel, bar stock, etc) and inelegant. But once the idea is
seen to work (or be workable), then things start to be optimized a
little bit, because now the engineers start figuring out what needs to
be done to make X thousand at Y price point. Even during the
production run, changes get made to the design (supply V's price
changes, quality of supply W isn't as good, etc), product is currently
too expensive so make it cheaper, etc...

Why should we think that software "engineering" should be perfect from
the getgo, when other production engineering disciplines clearly are
not so in the Real World (i.e, the world where things have to get
done, out the door, and just more or less work)?

About the only engineering disciplines that seem to need to be Right
at the getgo are civil, aeronautical and biomedical engineering. There
tend to be people's lives (or they're singular entities...) on the
line in those disciplines, which skews the fudge factor greatly.

-cl

 

[baalbek]

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!)

Baalbek

 

[baalbek]

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'!

My bad (it's late).

Baalbek

 

[Alexandru Popescu]

#: Kirk Haines changed the world a bit at a time by saying on 8/20/2005 4:06 PM :#

On Saturday 20 August 2005 3:36 am, Chris Game wrote:

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.

Yep, and from the pov of the business writting ugly (bad) code is good as after a time you can sell
the 2nd version (just kidding).

:alex |.::the_mindstorm::.|

 

[Alexandru Popescu]

#: 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).

:alex |.::the_mindstorm::.|

 

[Jamey Cribbs]

#: Jamey Cribbs changed the world a bit at a time by saying on
8/19/2005 3:18 AM :#


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.

Jamey

 

[Alexandru Popescu]

#: Jamey Cribbs changed the world a bit at a time by saying on 8/21/2005 4:48 AM :#

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

 

[Jamey Cribbs]

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".

Jamey