Is Ruby slow?

SpookyET

jesusphreak: http://www.codeigniter.com/forums/viewthread/78/ about models

lech

While I can't say I'm wholey impressed with CodeIgniter, I'll have to say that it does look like a promising perspective on where the php dev team can go with future versions of php. Given it already has a framework of it's own with pear and pecl, this seems like a promising way to go. I can't say I'm a huge fan of the crazy folder structure some of these frameworks spit out though and being forced to work within them seems like a small pain, the trade-off is pretty good if you want something quick and easy. Although the most depressing portion of CI is the fact that it's still mostly php and you're still mostly writing your own loops and other repetative and annoying bits and pieces to complete it all. Not to mention, you're still writing quite a bit of code to get it all done, where with ruby, it's like 3 lines and you already have a pretty finished product.

Minisweeper

Will someone hurry up and teach me ruby already?!

giginger

OK, here goes:

class HelloWorld def initialize puts "Hello, world" end end # we can instantiate the class in the same script outside the class # definition hw = HelloWorld.new

Save as hello.rb and then run it with

$ ruby hello_class.rb

Here endeth the first lesson.

_{PS: I know now what I do because I copy and paste from here.}

Bergamot

**slaps giginger for not indenting inside his class.

sean lancaster

i just bought "how to program" from the pragmatic programmer website by chris something or other. i am on page 70 and his writing is making much sense to me. the last time i "programmed" was with BASIC and that wasn't *really* programming, so that should tell you how well the book is working. oh, the reason i mention it is that the language used in the book is Ruby. i use Bluehost for my online hosting company and they have Ruby on Rails already installed and configured and all that. I just have to learn to build the apps. so far, it's coming along. Ruby just makes sense so far.

jesusphreak

Sean, I got that book, too, and I wrote an e-mail to the author when I finished. He was kind enough to give me a page-long reply!

Here's his reply to me (I don't think he'd care that I posted it here, he actually probably appreciates the exposure), and it includes bits and pieces of my own e-mail to him.

> * Honestly the whole "Blocks and Procs" section confused the hell out
> of me. Perhaps I'd find it useful one day, but I was having a hard
> time imagining the immediate benefits I'd get from it.

Yep... I tried to make it as clear as it is, but it's pretty advances
stuff; most mainstream languages don't have anything like it.

First: Closures are super-cool, and once you "get" them, you'll love
them. But it's hard to "get" them without writing larger programs,
because they help make larger programs easier (*much* easier) to
write.

Second: The reason I included them was because I wanted someone
reading my book to then be able to move on to the Pickaxe. But the
Pickaxe covers blocks and procs so briefly... if you aren't familiar
with them, they are hard to pick up. So I did my best to introduce
them in a way that made a little more (though still maybe not much)
sense.


> My mind is also still infatuated with the concept of
> everything in Ruby being an object, and "operators" such as +, -, etc,
> are really just methods, and its really simple to extend or edit
> "built-in" classes such as Array, String, etc. That's just really
> cool!

I know, I love this stuff! But closures are still the feature I
miss most when using other languages. Seriously. Because I don't
*need* to extend the String class all that often, but I always need
closures.

Here's just one real-world example: We have been working on our
website recently. It's mostly a picture-organizing website. Some
pictures are public, and some are private. (Originals, when we
cropped or lightened the public version, near duplicates when we
weren't *really* sure which we liked best... what were *you* thinking
I meant!?)

To do something to all the pictures, I use code similar to this:

Picture.find_all do |picture|

end

Now, sometimes I want to go over only public pictures, so I might do
something like this at first:

Picture.find_all do |picture|
if picture.private?
next
end


end

(or, because I love TIMTOWTDI)

Picture.find_all do |picture|
next if picture.private?


end

And I can do something similar for private pictures with "next if
!picture.private?". In a small program, this is enough. But if I
write this code over and over again (because sometimes I want to show
the pictures, but sometimes I want to see who is in them, or just find
out the dates for the pictures, or the places...), I start to think
"Could I make this better?" In Ruby, yes I can:

Picture.find_private do |picture|

end

And it's so easy! Is it a big improvement? Not if you do it once...
but when you start using them a lot, large sections of code that would
otherwise be full of "program logic" start to look like english
sentences. This is *really nice*.

We also have locations attached to our pictures. Some locations (like
"Oslo") are parts of other locations (like "Norway", which is part of
"Europe"), so they form a big tree. It sure is nice to be able to say

some_place.each_child do |place|

end

as well as "some_place.each_descendent" and "some_place.each_ancestor"
and "some_place.each_picture" and
"some_place.each_descendent_picture"...

And rolling-your-own iterators is just one of the things people use
closures for (but probably one of the more popular ones). But the
point is that they allow you to mutate the language to be more what
you need it to be (and that's different for every program).

Mutating the language is the ultimate expression of TIMTOWTDI.

jesusphreak

Continued >>>

> That being said...I'm not sure I'm suited to be a Rubyist. Ruby is
> neat, but the whole Tim Toady thing is just a big problem for me. I'd
> almost prefer having a single set way to do things.

Ruby favors "freedom of expression". But, as with the single-line
"if" above, it often makes the code *more* readable. (Well, I guess
that's open to opinion.) The fact is, you don't *need* to use more
than one way to do something, but I think you'll find that you want
to, at least in time.

Human languages have a great deal of redundancy. A lot of repetition.
Many different ways of saying the same thing. Plenty of options when
you want to express something... But they aren't all *exactly*
the same, are they? Each one has a different flavor. To a much
smaller extent, Ruby feels the same way to me. It feels like a much
more *living* language.


> Perhaps that's why
> I'm looking at Python - at least on the surface Ruby and Python seem
> very similar, yet Python is the opposite of Tim Toady..."there's only
> one way to do it."

It certainly is. And many people seem to find this appealing. I can
see the appeal, too, to a beginner. (I mean, I *did* try to show only
one way to do things in the book, for the most part.) But it seems
very limiting in the long run.

Also, I think the whole thing is a false dichotomy. Only at the most
basic language level do you have "only one way to do something" in
Python. If there was seriously only one way to do something, the
language would be so limiting that there would often be *no* way to do
something. Programming is still a creative act, which means different
people will use different algorithms to solve different problems.

I think (just my opinion here) that the real goal of Python was to
have everyone's code be as readable as possible to everyone else.
Which is a great goal, of course. But them someone thought, "Oh, that
means that everyone's code should look as *similar* as possible!"

WRONG!

I ask you, what's more readable? This:

Picture.find_all do |picture|
if picture.private?
next
end


end

Or this:

Picture.find_private do |picture|

end

If there was only one way to do that, it would be the first way
(because it's more general).

Basically, I don't think "one way to do it" gives programmers enough credit.


> Speaking of which, I have a quick question about that. You stated that
> procs are known in other languages as "closures"? Would this be the
> same thing as "lexical closures"?

Yep.


> I've heard that Python does not have
> these...do you have any clue if that is true?

Yeah... I've heard that they sort of do, but they can't contain
statements (only expressions... basically only small bits of code) and
they can only be on one line.

So they are quite crippled compared to what Ruby offers.

Python has some nice points, in all fairness. List comprehensions are
cool (though with "map" and "filter" and real closures, you don't need
them in Ruby... still, they are cool). And Python can be compiled, so
that's cool. I guess. (Though I never miss compiling Ruby,
honestly.)

And honestly, they are probably both pretty good languages. The Ruby
community is nicer and more helpful/friendly, but the Python community
is quite a bit larger. For the most part, both languages attract a
lot of people from C/C++ and Java and Perl... but very few people move
from Python to Ruby or vice-versa. So that tells me they are both
pretty good, but just appeal to different sorts of people.

But, if you'll excuse the bragging, I don't think there's any
equivalent to my book for Python!


> Anyway, I just wanted to say thanks a lot for your book. I felt like
> in some way a lot of you was put into it.

Just my heart, soul, and three years of my life! In teaching
people in person, making a connection is the most important step. So
I was really trying to reach through the pages and make that
connection. I wanted to "be there" as much as possible.

Take care,

Chris

sean lancaster

hey, thanx for that follow up. it's really nice to see the guy write the book and then have the enthusiasm to address your questions and concerns on an individual basis. very cool.

SpookyET

The closure syntax in ruby is abysmal.

jesusphreak

What are closures exactly? I can't seem to figure that out. Maybe a better question is...what is comparable in Python to Ruby's closures?

SpookyET

closures are blocks of code that act like functions that you can pass around.

def foo():
     myClosure = def(message as string):
           print message
     return myClosure()

def bar():
     myClosure = foo()
     myClosure('Hello, World!")

That's BOO, not Python.

lech

the above reminds me of vb & basic in some of its advanced forms.

Bergamot

Did someone just use "VB" and "advanced" in the same sentence?

EDIT: And I don't believe VB has ever had closures of any kind. I do see them used in Javascript a bunch though.

jesusphreak

Are they lamdas? Anyway, passing around functions inside Python is a very natural thing.

Kosmo

Passing gas is a very natural thing too.

a_magical_me

Python example:

def foo(): def myClosure(message): print message return myClosure def bar(): myClosure = foo() myClosure("Hello, world!")

The author of that book seems to be under the impression that lambdas are the only way to pass functions around in python.

jesusphreak

Yeah, since def statements are really just assigning a function to a name, you can use a function really anywhere you would any other variable in Python. Its very powerful and easy to use. I don't remember if Ruby is the same way.

Kosmo

Ruby has blocks which are very very nice.

SpookyET

I said Boo (boo.codehaus.org), not python. That said, you are passing functions around. Code blocks are anonymous functions generated for you.