Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Can you please help to make decision?

Reply
Thread Tools

Can you please help to make decision?

 
 
Robert Dober
Guest
Posts: n/a
 
      10-02-2007
<snip>
> Try both.

This indeed might be time well spent, nice idea

> You can't go wrong with either one.

Well, hopefully
>
>

Robert

--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/

 
Reply With Quote
 
 
 
 
Chad Perrin
Guest
Posts: n/a
 
      10-02-2007
On Sun, Sep 30, 2007 at 10:47:42PM +0900, 7stud -- wrote:
> I would choose python.
>
> 1)
> >a clean (probably one of the cleanest) object oriented design, example:

> <snip>
>
> Convert the number 12 to a string:
>
> ruby: my_str = 12.to_s
>
> python: my_str = str(12)
>
> I have a hard time understanding how either method has an advantage over
> the other. It's totally irrelevant in my opinion. Personally, I think
> using a number to call a method looks ugly. But I can adapt pretty
> easily.


Technically, you're using "to_s" to call a method -- but you're sending
the "to_s" message to the "12" object. From an object-oriented
perspective, the 12.to_s syntax is more consistent than the str(12)
syntax -- which is probably the point the previous comment meant to make.


>
> 2)
> - a simpler (not simple by any means, but simpler) Inheritance Model
>
> I have never studied a simple inheritance model. I don't have enough
> experience with Ruby's inheritance model yet to know which is simpler.
> Once again, I think trying to decide which is simpler is totally
> irrelevant--especially for a beginner who has never programmed in any
> language before.


I think a simpler inheritance model could be of great value to someone
who has never done OOP before -- because a simpler inheritance model
should translate into a shallower learning curve. That's usually the
case with simpler things.

On the other hand, I'm not familiar enough with Python's inheritance
model to be able to make any personal judgment about which is simpler.
For all I know, I may have just made a case for learning Python first,
even though I don't much like the language.


>
> 3)
> - a little bit less esotheric (syntax and metraprogramming) thus what
> you learn about Ruby will be more usable for other languages e.g.
> Smalltalk
>
> I think ruby's syntax looks like chicken scratchings, and I have a C++
> background. C++ has the most difficult syntax I have seen--except maybe
> perl's. In my opinion, python's syntax is much more human readable than
> ruby's. I guess if you are coming from perl, then ruby's syntax would
> seem incredibly clear. Of course, if you know a language well, it's
> easy to read. I think the test is whether someone who doesn't know a
> language well can make heads or tails out of what is going on in some
> basic code. I don't think ruby is ever going to be readable in that way.


I disagree quite a lot. I find Ruby's syntax marginally cleaner than
Python's, and Perl's only marginally less clean than Python's. I also
find that for me, personally, Python's syntax is eye-stabbingly
disconcerting and somewhat obtuse at times (e.g., excessive requirements
for explicit references to self), though I realize that's in large part a
result of personal preference. Even leaving the personal preference
aside, however, I still think Ruby's syntax is just a touch cleaner,
except perhaps in areas where "cleaner" translates to "missing
something".

I found Ruby much easier to reason through without having to already know
the language than Python, back when I knew neither -- despite the fact
that Python is full of function(arg) to mix in with the object.method,
while Ruby is more consistently object.method, and I was nowhere near as
familiar with object.method syntax as I was with function(arg) syntax at
the time. Your mileage obviously varies.

In fact, in many ways, I think Python's syntax is more Perl-like than
Ruby's. Leading sigils on variable names are not the only signs of
similar syntactic design, y'know -- and, in fact, are among the most
superficial and easily ignored of those signs.


>
> Ruby also relies heavily on regex's, and regex's are never going to be
> easy to read for anyone. regex's are not beginner friendly, and that
> might be a big barrier for a beginner trying to learn ruby. There are
> lots of people who just can't learn regex's.


Uh . . . what?

1. I find regexen very easy to read. I guess I must not be part of
"anyone".

2. Ruby doesn't "rel[y] heavily" on regexen. It provides regex
capabilities with a very simple, easy-to-use syntax that doesn't
require obtuse library calls the way Python does, thus making regex use
less painful. As a result, people probably make use of the power of
the regex more often in Ruby than in Python -- not because writing Ruby
somehow magically requires you to use regexen more often, but because
there's less reason to avoid them since they're easier to use.

I have yet to see anything that would lead me to believe that one must
use regexen more often in Ruby than in Python. I just see more hurdles
in the way of using them in Python than in Ruby, when they're appropriate
for use.


>
>
> 4)
> - simpler, Python got very, very powerful but at the cost of advanced
> techniques, the Ruby learning curve will be much flatter.
>
> I doubt that Ruby's learning curve is flatter. I think python and ruby
> are close neighbors as far as languages go. In fact, there are some
> similarities that it will make you wonder who copied who with regard to
> certain features. However, I would guess that python's learning curve
> is easier for beginners because the subject of classes doesn't come up
> until about the middle of a python book. python is a language that can
> be used effectively without classes if the concept of classes is too
> difficult for a beginner to grasp.


You had me until you started talking about classes. Ruby can be very
easily used in a superficially imperative/procedural style, same as
Python. Just create global methods and use them as if they were plain
ol' procedural functions. I don't see where you get the impression that
one must necessarily jump right into defining classes, unless you've just
seen that most Ruby books tackle classes early.

Of course, the reason most Ruby books tackle classes early is that for
languages like Ruby and Python it's usually *better* to do proper OO
programming than to pick up the scalpel and try to use it to hammer
nails. I think it's a *good* thing to tackle classes sooner rather than
later in either Ruby or Python, as long as it's handled reasonably well,
because neither language really comes into its own without using object
oriented programming techniques *well*.

Why teach someone to write BASIC using Python or Ruby?


>
> Overall, I think python's online documentation is pretty poor, but I
> think ruby's is worse. In my opinion, only php got it right. They
> opened up the online documentation to user comments, and now every
> single issue that has ever been encountered with any function is
> discussed in the comments to the documentation. That is incredibly
> valuable information. If ruby wanted to take a significant step forward
> in its online documentation relative to python, I think they should copy
> the php model. One solution to the poor online docs for both ruby and
> python is to buy a good book.


Oh, gawd, no. I agree that both Python and Ruby documentation
desperately needs some help, and I agree that having (separate, but
associated) user comment documentation is a great idea, but much of what
I've seen for PHP documentation is crap. The "official" documentation
tends to be of better quality in Ruby and Python than in PHP and, while
the user comment documentation is an important addition to the official
documentation, it's also a little bit more *needed*.

I haven't used online Python documentation enough to have an opinion
about how it compares to online Ruby documentation, I'm afraid. You may
very well be right that Python's is better, in general. On the other
hand, Perl's online documentation puts both of them to shame, by a wide
enough margin that it has time left to make the documentation of a bunch
of other languages look crappy by comparison at the same time, all while
having a nice leisurely cup of tea.

Maybe both Ruby and Python could learn from Perl's documentation as well.


>
> There is also more information about python available on the web since
> the python community is much larger.


I rather suspect the gap in community sizes is shrinking, and while I
don't know personally whether your estimation of the quantity of Python
information online compared with that of Ruby is accurate, I do know that
I've never felt like there wasn't *enough* information about Ruby.
There's a *lot* of information about Ruby online, and past a certain
point it doesn't matter much which has a few hundred extra documents
available online.


>
> 5)
> - and this is my favorite: "Code Blocks", learning to use code blocks
> is probably the single greatest benefit from learning Ruby, Python
> just will not give this to you.
>
> I don't know what "code blocks" are and the subject isn't in the
> appendix of ruby's bible: pickaxe2, so I can't comment on that.


Try looking for "block" in the index. That'd probably help. The syntax
of a (code) block in Ruby tends to look like one of the following two
examples:

1. object.method { |var| var.method }

2. object.method do |var|
var.method
end


>
> 6) I find tracking down errors is more difficult in ruby than python.
> python has better error messages. For instance, in ruby if you forget
> one 'end' in your code somewhere('end' is used to terminate a section of
> code), the error message will say that there is an error on the last
> line of your program. As a result, you have to go hunting through your
> whole program to figure out where you forgot an 'end'. That's
> aggravating.


I have seen errors just as annoying for Python indentation mistakes.
I've seen, for instance, code that offers no errors at all and simply
executes in an unintended manner thanks to indentation mistakes. I don't
think either language really "wins" in terms of loop termination errors
and the like.


>
> 7) There are some really nice little touches that python implements,
> which make programming less aggravating. I'll highlight one.


<snip some stuff about puts vs. print in Ruby vs. Python>

This looks like a wash, to me -- with the most common cases making Ruby a
little easier. Space-separated collections of output from separate
variables are much, much less common than newline-separated, in my
experience, though if you deal with space characters as delimiters I can
see how you might find Ruby's behavior slightly annoying. I find it more
convenient.

On the other hand, you could always do something with an iterator block
in Ruby, perhaps defining a method if you have to output a *lot* of
space-separated collections of output from variables in a given program.

I suspect there may be a built-in global variable in Ruby you can set to
get your desired behavior, too -- but I'm not sure, and wouldn't know
what it is if so (since it's not behavior I tend to desire). Does anyone
out there know for sure whether there is such a beast?


>
> Then there are the well documented major shortcomings of Ruby---it is
> slow. Rubyists will say, "Who cares?! I'm in no rush to get the
> results of my programs." That's well and good, but it's nice to have
> more speed if you need it. Rubyists will counter, "If I need the speed,
> I'll program in C." That's great if you know C, but what if you only
> know ruby? python executes much faster than ruby, and just like ruby,
> you can program the slow parts in C if you need even more speed.


Slow:

1. Sometimes, it's slower than Python. Others, it's faster, as
demonstrated with a simple string concatenation exercise in a recent
thread right here in ruby-talk. It went something like this:

#!/usr/bin/env ruby
i = 0
string_var = ''
while input = gets
i += 1
string_var << input
puts(i) if i % 1000 == 0
end

#!/usr/bin/env python
i = 0
string_var = ''
for input in sys.stdin:
i += 1
string_var += input
if i % 1000 == 0: print i

In case it's not clear, Ruby won that little performance. (Disclaimer:
I did that from memory, and may have misremembered some specifics of
the example code.)

2. Sometimes, code execution speed doesn't matter that much.

3. Ruby 1.9 is reportedly much, *much* faster than Ruby 1.8.x, so you
may very quickly find your statements about how slowly Ruby executes
"obsolete".

4. There's a small enough difference between Ruby and Python that I
really don't understand why anyone would give that much of a damn about
which of the two is faster anyway. If you really want to compare
execution speed, put your language of choice up against OCaml, C, or
even assembly language.

Others may have opinions that differ from mine, of course.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of others
we should be glad of an Opportunity to serve others by any Invention of
ours, and this we should do freely and generously."

 
Reply With Quote
 
 
 
 
John W. Kennedy
Guest
Posts: n/a
 
      10-06-2007
Logan Capaldo wrote:
> You bring up an excellent point. Where the hell did "for" come from
> anyway? Only thing I can think of is "for all x in X" kinds of
> statements from math, but thinking about it now, "for" seems like
> such a weird word. I just looked it up, man is this word overloaded:
> http://dictionary.reference.com/browse/for
> If I ever create a language, the word "for" shall not appear as an
> interation construct in it.


Where it /came/ from is ALGOL:

*for* i := 1 *step* 1 *until* 10 *do*
*begin*
*comment* Write i to sysout and skip to next line;
outinteger(1, i); sysact(1, 14, 1)
*end*

--
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
....you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"
 
Reply With Quote
 
Logan Capaldo
Guest
Posts: n/a
 
      10-07-2007
On 10/6/07, John W. Kennedy <(E-Mail Removed)> wrote:
> Logan Capaldo wrote:
> > You bring up an excellent point. Where the hell did "for" come from
> > anyway? Only thing I can think of is "for all x in X" kinds of
> > statements from math, but thinking about it now, "for" seems like
> > such a weird word. I just looked it up, man is this word overloaded:
> > http://dictionary.reference.com/browse/for
> > If I ever create a language, the word "for" shall not appear as an
> > interation construct in it.

>
> Where it /came/ from is ALGOL:
>

<snip snippet>

Doesn't look especially clear there either. I was more asking about
what the rationale behind the choice of the word "for" in any
programming language was for looping, not the first programming
language that did so. But thanks for the history

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
make pls don't work , i help you make web ,help you do business onthe internet xiaobb03@gmail.com Digital Photography 0 03-13-2008 11:28 AM
Can you spare 10 minutes to do a survey? You can be a valuable help to university researchers! daniel DVD Video 0 03-02-2007 02:19 AM
Stupid question. Please, only stupid responders. If you're not sureif you're stupid, you probably aren't. =?ISO-8859-1?Q?R=F4g=EAr?= Computer Support 6 07-18-2005 05:11 AM
HELP! HELP! PLEASE, PLEASE, PLEASE tpg comcntr Computer Support 11 02-15-2004 06:22 PM
please help... ...me learn C++ please please please :) KK C++ 2 10-14-2003 02:08 PM



Advertisments