Can you please help to make decision?

ruby-talk
21

James Edward Gray II wrote:

···

On Sep 30, 2007, at 8:47 AM, 7stud -- wrote:

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.

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.

Please, sit down and really try learning regular expression before adding to the fear factor surrounding them. I promise, it's time well spent.

James Edward Gray II

+1

BTW ... I *still* hate them, but I use them. :wink:

22

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.

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

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!

···

--
Phlip
Test Driven Ajax (on Rails) [Book]
^ assert_xpath

23

>In article <1191143544.1498.1.camel@viola.izb.knu.ac.kr>,
>
>>Fist of all, sorry for poor English, I am not professional English
>>speaker. I have some plan to do study computer language for my
>>work. But
>>still I do not make decision what to do study between Ruby and
>>Python. I
>>never have experience to use any computer language. I think Ruby's
>>design is clean, whereas it does not have many libraries to use
>>somebody.
>>
>>Can you please help to make decision?
>
>I don't think Python has ever gained the traction that Ruby has,
>especially with the advent of RoR.
>
>My opinion, go with Ruby.
>
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.

···

On Mon, Oct 01, 2007 at 11:29:28PM +0900, John Joyce wrote:

On Oct 1, 2007, at 12:20 AM, David Orriss Jr wrote:
> Byung-Hee HWANG <bh@izb.knu.ac.kr> wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Kent Beck: "I always knew that one day Smalltalk would replace Java. I
just didn't know it would be called Ruby."

24

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

···

On Mon, Oct 01, 2007 at 02:10:04AM +0900, William James wrote:

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

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Isaac Asimov: "Part of the inhumanity of the computer is that, once it is
completely programmed and working smoothly, it is completely honest."

25

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

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.

···

On Mon, Oct 01, 2007 at 11:16:58PM +0900, James Edward Gray II wrote:

On Sep 30, 2007, at 8:47 AM, 7stud -- wrote:

Please, sit down and really try learning regular expression before
adding to the fear factor surrounding them. I promise, it's time
well spent.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."

26

<snip>

Try both.

This indeed might be time well spent, nice idea :slight_smile:

You can't go wrong with either one.

Well, hopefully

Robert

···

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

27

In article <E1BAAF56-07ED-47DD-AF8C-C21B00144173@gmail.com>,

···

John Joyce <dangerwillrobinsondanger@gmail.com> wrote:

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

Yea I knew I'd invoke some ire by saying that.

I'm sorry.. I know that Python shipped with a lot of systems.. but
whether you call it "buzz".. "traction".. "adoption".. whatever.. Python
didn't see as much of it as Ruby did.. that's all.

And again.. just my opinion/observation...

28

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
--
Posted via http://www.ruby-forum.com/.

29

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

···

On Oct 1, 9:50 am, Phlip <phlip2...@gmail.com> wrote:

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

30

E:\Ruby>irb --prompt xmp
colors = ["red", "blue", "green"]
    ==>["red", "blue", "green"]
puts colors
red
blue
green

···

On Sep 30, 1:25 pm, 7stud -- <dol...@excite.com> wrote:

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

31

William James wrote:

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

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!

···

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath

32

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.

···

On Mon, Oct 01, 2007 at 03:25:37AM +0900, 7stud -- wrote:

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

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

33

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

If I ever create a language, the word "for" shall not appear as an
interation construct in it.

···

On 10/1/07, Chad Perrin <perrin@apotheon.com> wrote:

On Mon, Oct 01, 2007 at 03:25:37AM +0900, 7stud -- wrote:
--
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?

34

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

···

On Oct 1, 2007, at 2:58 PM, Chad Perrin wrote:

On Mon, Oct 01, 2007 at 03:25:37AM +0900, 7stud -- wrote:

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?

35

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

···

On Tue, Oct 02, 2007 at 04:58:10AM +0900, Chad Perrin wrote:

On Mon, Oct 01, 2007 at 03:25:37AM +0900, 7stud -- wrote:
> 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 ]
Patrick J. LoPresti: "Emacs has been replaced by a shell script which 1)
Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk
quota by 100K; and 3) RUNS ED!!!!!!"

36

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:
FOR Definition & Usage Examples | Dictionary.com
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"

37

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

···

On 10/6/07, John W. Kennedy <jwkenne@attglobal.net> 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:
> FOR Definition & Usage Examples | Dictionary.com
> If I ever create a language, the word "for" shall not appear as an
> interation construct in it.

Where it /came/ from is ALGOL: