Can you please help to make decision?

P

Phlip

Please, sit down and really try learning regular expression before
adding to the fear factor surrounding them.

Then test them, clean them up, use /m on their ends so you can group
their contents with blanks, and hide them behind self-documenting
interfaces.

Next, I thought any language which supports Regexp would have this
problem. No language "relies on" Regexps for its core behaviors, so do
commit the Regexp abuse that some _programmers_ indulge in, and we'll
get along fine!
 
W

William James

Then test them, clean them up, use /m on their ends so you can group
their contents with blanks,

Incorrect. /m makes . match a newline. /x lets you put extra
whitespace
and comments in the regular expression.
 
P

Phlip

William said:
Incorrect. /m makes . match a newline. /x lets you put extra
whitespace
and comments in the regular expression.

I upgraded one of my assertions to write that post. I added blanks,
and it failed. Then I added /m, and it failed, so I added /x, and it
passed.

Then I came here and wrote /m.

Test-first posting works!
 
C

Chad Perrin

Here's a simple test for the op. Which of the following do you think is
easier to understand? Can you guess what each program does?

language1:
--------

colors = ["red", "blue", "green"]

colors.each {|color| puts color}


language2:
---------
colors = ["red", "green", "blue"]

for color in colors:
print color

In the case of someone who has never programmed before, I rather think
"colors.each {|color| puts color}" might be less confusing than "for
color in colors:\n print color". I have never in my life seen anything
in plain English that even began to look like "for color in colors", and
the meaning of that clause is non-obvious. Meanwhile, "colors.each" at
least looks like it's saying something about each of something, with the
"each" attached obviously to the "colors", suggesting that it's saying
"for each element of the colors array".

The only way the Python one looks anything like "more intuitive" to
someone who has never encountered Ruby or Python before, as far as I can
tell, is if that person is familiar with C.
 
L

Logan Capaldo

Here's a simple test for the op. Which of the following do you think is
easier to understand? Can you guess what each program does?

language1:
--------

colors = ["red", "blue", "green"]

colors.each {|color| puts color}


language2:
---------
colors = ["red", "green", "blue"]

for color in colors:
print color

In the case of someone who has never programmed before, I rather think
"colors.each {|color| puts color}" might be less confusing than "for
color in colors:\n print color". I have never in my life seen anything
in plain English that even began to look like "for color in colors", and
the meaning of that clause is non-obvious. Meanwhile, "colors.each" at
least looks like it's saying something about each of something, with the
"each" attached obviously to the "colors", suggesting that it's saying
"for each element of the colors array".

The only way the Python one looks anything like "more intuitive" to
someone who has never encountered Ruby or Python before, as far as I can
tell, is if that person is familiar with C.
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.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make lemonade.
I always wonder -- isn't the lemonade going to suck if life doesn't give
you any sugar?
 
J

John Joyce

Here's a simple test for the op. Which of the following do you
think is
easier to understand? Can you guess what each program does?

language1:
--------

colors = ["red", "blue", "green"]

colors.each {|color| puts color}


language2:
---------
colors = ["red", "green", "blue"]

for color in colors:
print color

In the case of someone who has never programmed before, I rather think
"colors.each {|color| puts color}" might be less confusing than "for
color in colors:\n print color". I have never in my life seen
anything
in plain English that even began to look like "for color in
colors", and
the meaning of that clause is non-obvious. Meanwhile,
"colors.each" at
least looks like it's saying something about each of something,
with the
"each" attached obviously to the "colors", suggesting that it's saying
"for each element of the colors array".

The only way the Python one looks anything like "more intuitive" to
someone who has never encountered Ruby or Python before, as far as
I can
tell, is if that person is familiar with C.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
They always say that when life gives you lemons you should make
lemonade.
I always wonder -- isn't the lemonade going to suck if life doesn't
give
you any sugar?
But you forget, Ruby can also do
colors = Array.new # Or Hash.new, etc...

for color in colors
puts color
end

This format makes more sense to some people in some cases. Seems
pretty clear. For some it is more clear than the .each version with
its do-end or {}
Of course, if they don't get used to do-end and {} they'll have a
hard time with Ruby...
 
C

Chad Perrin

Huh? Python's got lots of traction! Just not the buzz.
Python is widely used and shipped with systems.

True. Perl, Python, and Ruby are all quite widely used. For instance,
Perl was used to create Debian's APT, Python was used to create Gentoo's
portage, and Ruby was used for FreeBSD's portupgrade. It's difficult to
get more of an indication of traction than that.

Try both.
Go with the one that suits you best!
You have many things to consider. Browse the books and sites for all
languages you're considering.
A bad book can be a big turn-off to a good language.

You can't go wrong with either one.

Agreed, pretty much. Personal preferences play heavily into the choice
between Ruby and Python (and Perl, for that matter). It's not like any
of the three are QBASIC or COBOL, avoided for the sake of sanity.
They're all excellent, flexible, powerful, high-level languages. If
there's a major influence on which is the "best" choice for a first
language aside from personal preference, it's which has the best absolute
beginner tutorial materials -- and from what I've seen, that's a toss-up
between Ruby and Perl, depending in large part on whether you're looking
for online tutorials (Ruby wins there, I think) or hardcopy, published
books (while there's some excellent material for Ruby, like Chris Pine's
Learn to Program, Perl's camelid books provide a smoother and more
complete path from rank newbie to competent programmer, in my opinion).

Of course, community is quite important, too. Between ruby-talk and
Perlmonks, it's kind of a toss-up between the two. I like the
Pythonistas in my area, but I'm not a fan of the Python community at
large, in general.
 
C

Chad Perrin

Apparently, Ruby gives the programmer more power here.
Just as Awk has OFS (output-field-separator) and ORS
(output-record-separator), Ruby has $, and $\.

I should have read this before I responded and brought up the idea of
global variables.
 
C

Chad Perrin

I'm staying out of the Ruby vs. Python debate, but the above is just
plain wrong and I wish people would stop saying things like this.

For some reason, regular expressions are surrounded in this aura of
mystery. Perhaps their syntax heavy nature makes them seem odd to
people unfamiliar with them at first glance, but for some reason
many, many people believe things like the comment posted about.
That's a real shame.

Regular expression is a simple pattern language anyone can learn
quite easily. I once taught them to my wife in the space of evening,
to help with a work project. She's an above average skill-level
computer user, but definitely not a programmer. She had no trouble
grasping the concepts and still uses regular expression to this day.

Agreed. If an emacs user can learn to use a regex, anyone can.

/me ducks and hides.
 
C

Chad Perrin

Here's a simple test for the op. Which of the following do you think is
easier to understand? Can you guess what each program does?

language1:
--------

colors = ["red", "blue", "green"]

colors.each {|color| puts color}


language2:
---------
colors = ["red", "green", "blue"]

for color in colors:
print color

In the case of someone who has never programmed before, I rather think
"colors.each {|color| puts color}" might be less confusing than "for
color in colors:\n print color". I have never in my life seen anything
in plain English that even began to look like "for color in colors", and
the meaning of that clause is non-obvious. Meanwhile, "colors.each" at
least looks like it's saying something about each of something, with the
"each" attached obviously to the "colors", suggesting that it's saying
"for each element of the colors array".

The only way the Python one looks anything like "more intuitive" to
someone who has never encountered Ruby or Python before, as far as I can
tell, is if that person is familiar with C.

. . and while I'm at it, I think this might be even more easily
understood (ignoring for a moment the variable sigils):

@colors = ("red", "blue", "green")

print foreach @colors;

On the other hand, I doubt you want to advocate Perl -- particularly if
you're a Pythonista. Also, as others have pointed out, the Ruby iterator
could just be replaced with `puts colors`.
 
C

Chad Perrin

I would choose python.

1)
<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?

8) 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.
 
J

John W. Kennedy

Logan said:
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"
 
L

Logan Capaldo

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top