«

Hello:

I've been using Ruby on-and-off for about 4 weeks now and love it.
However, some of the naming consistencies really bug me. The ones that
bug me the most are the "print", "puts" and "putc".

I'd like to suggest that the functionality of the names "puts" and
"print" should be swapped so that "print" automatically sends a newline
character and "puts" doesn't. The reasons for this are as follows:

- "print" in other languages I've used (e.g. Basic) sends out a newline
character.

- "putc" doesn't send out a newline so why should "puts".

- The "puts" method sounds like a techier name so it shouldn't be doing
console style formatting and "print" sounds like the name you'd expect
to be using with terminal / printer based formatted output.

Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
etc... to keep their syntax consistent with the naming conventions used
with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
to "tos", etc... Either way, just make it consistent.

At a minimum I think the "put_c", "put_s", etc... should be implemented
and the "putc", "puts", etc... identified as obsolete syntax.

I realize these changes would effect every piece of Ruby code but the
language is still fairly young (at least with respect to it's version
number) and since it sounds like version 2.0 is going to break a few
things it might be a good time to adjust a few names and conventions.
I'm sure a little Ruby script using regular expressions could rename
everything quite easily. Alternately, new versions of Ruby could have a
command line switch to run the old syntax but by default would run the
new syntax.

I apologize in advance for irritating anyone... I'm still new to Ruby
and maybe I misunderstood some of the intentions behind the naming
conventions. It's because Ruby is so consistent/smart in many other
areas (I love the OO goodness) that this stuff (don't get me started on
Find.find() or Benchmark.bm()) bugs me. I love promoting Ruby with
co-workers but can't help but mention (or get asked) why some things
like this look kind of silly.

Just a thought, have a good day everyone!

Michael

Le samedi 24 mars 2007 15:40, Michael Brooks a =E9crit=A0:
> Hello:
>
> I've been using Ruby on-and-off for about 4 weeks now and love it.
> However, some of the naming consistencies really bug me. The ones that
> bug me the most are the "print", "puts" and "putc".
>
> I'd like to suggest that the functionality of the names "puts" and
> "print" should be swapped so that "print" automatically sends a newline
> character and "puts" doesn't.
> [...]
> Michael

The names of the methods puts and putc obviously come from the C language,=
=20
where they act in the same way than in Ruby. This explains their behavior.

As for the consistency, I'd like to quote Matz on this :
=AB Consistency does not come first in the Ruby's design. =BB

I think that a majority of developper expects puts and putc to behave like =
it=20
does now, making Ruby easier to learn, even if the initial naming in C is=20
debatable.

Regards,

=2D-=20
Olivier Renaud

The puts and putc methods are named after their C-equivalents, so I
see no real benefit in this change. Someone coming from C or C++
would be more comfortable with the current naming, whereas someone
like yourself (.e.g, coming from BASIC or Python or what have you)
would be more comfortable with your proposed naming. I think maybe
just keeping it the way it is will satisfy about the same amount of
people and keep all existing code in working order.

You have to learn a lot of new stuff when you learn Ruby, why not a
new output function?

--Jeremy

On 3/24/07, Michael Brooks <> wrote:
> Hello:
>
> I've been using Ruby on-and-off for about 4 weeks now and love it.
> However, some of the naming consistencies really bug me. The ones that
> bug me the most are the "print", "puts" and "putc".
>
> I'd like to suggest that the functionality of the names "puts" and
> "print" should be swapped so that "print" automatically sends a newline
> character and "puts" doesn't. The reasons for this are as follows:
>
> - "print" in other languages I've used (e.g. Basic) sends out a newline
> character.
>
> - "putc" doesn't send out a newline so why should "puts".
>
> - The "puts" method sounds like a techier name so it shouldn't be doing
> console style formatting and "print" sounds like the name you'd expect
> to be using with terminal / printer based formatted output.
>
> Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
> etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
> etc... to keep their syntax consistent with the naming conventions used
> with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
> to "tos", etc... Either way, just make it consistent.
>
> At a minimum I think the "put_c", "put_s", etc... should be implemented
> and the "putc", "puts", etc... identified as obsolete syntax.
>
> I realize these changes would effect every piece of Ruby code but the
> language is still fairly young (at least with respect to it's version
> number) and since it sounds like version 2.0 is going to break a few
> things it might be a good time to adjust a few names and conventions.
> I'm sure a little Ruby script using regular expressions could rename
> everything quite easily. Alternately, new versions of Ruby could have a
> command line switch to run the old syntax but by default would run the
> new syntax.
>
> I apologize in advance for irritating anyone... I'm still new to Ruby
> and maybe I misunderstood some of the intentions behind the naming
> conventions. It's because Ruby is so consistent/smart in many other
> areas (I love the OO goodness) that this stuff (don't get me started on
> Find.find() or Benchmark.bm()) bugs me. I love promoting Ruby with
> co-workers but can't help but mention (or get asked) why some things
> like this look kind of silly.
>
> Just a thought, have a good day everyone!
>
> Michael
>
>


--
http://www.jeremymcanally.com/

My free Ruby e-book:
http://www.humblelittlerubybook.com/book/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael Brooks wrote:
> I've been using Ruby on-and-off for about 4 weeks now and love it.
> However, some of the naming consistencies really bug me. The ones that
> bug me the most are the "print", "puts" and "putc".

These are very subtle things, but you make some good points. I
think "print" would be much friendlier if swapped with "puts." Especially
since puts is so filthy and derogatory to yiddish folk. Perhaps a
"schvits" is in order.

_why

Here ya go:

alias put_s puts
alias puts print

Cheers,
Peter
__
http://www.rubyrailways.com :: Ruby and Web2.0 blog
http://scrubyt.org :: Ruby web scraping framework
http://rubykitchensink.ca/ :: The indexed archive of all things Ruby

Michael Brooks wrote:
> I'd like to suggest that the functionality of the names "puts" and
> "print" should be swapped so that "print" automatically sends a newline
> character and "puts" doesn't.

Hrm... That breaks the "Huffman-encoding" of the current scheme. #puts
is by far the more used method, and so it's shorter. Maybe call it #put
or #say, and then pick a longer name for the feedless version (maybe
stick with #print, though something that acknowledged its correlation
with #put would be nice).

alias put puts
alias put_on print # short for put_on_the_same_line
alias eminence_front put_on # look it up
undef puts; undef print
? **

Devin

* #p and #y are excused -- one-character names are illegibly short, so
they can be reserved for little debug functions where terseness
(tersion?) is of primary import.

** Not a serious proposition, you turd.

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael Brooks wrote:
> I've been using Ruby on-and-off for about 4 weeks now and love it.
> However, some of the naming consistencies really bug me. The ones that
> bug me the most are the "print", "puts" and "putc".
>
> I'd like to suggest that the functionality of the names "puts" and
> "print" should be swapped so that "print" automatically sends a newline
> character and "puts" doesn't. The reasons for this are as follows:
>
> - "print" in other languages I've used (e.g. Basic) sends out a newline
> character.

That's languages *you've* used.

"print" in perl doesn't add a newline. Ruby borrows a lot from perl - in my
own opinion a little too much. But for people who need to switch frequently
between the two (including me), it's a small plus point that 'print' behaves
the same in both.

C doesn't have "print" but it has "printf", and that doesn't add a newline
either.

It's a long time since I wrote anything in BASIC.

> - "putc" doesn't send out a newline so why should "puts".

Because that's how it is in the C language:

(From 'man puts')

puts() writes the string s and a trailing newline to stdout.

> Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
> etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
> etc... to keep their syntax consistent with the naming conventions used
> with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
> to "tos", etc... Either way, just make it consistent.
>
> At a minimum I think the "put_c", "put_s", etc... should be implemented
> and the "putc", "puts", etc... identified as obsolete syntax.

"My minimum demands are: ..."

One of the benefits I have found from using Ruby is that it actively
encourages you to chill out. Accept things as they are. Sure, it's not lean
and pure and orthogonal (if you want that, write in LISP, or Smalltalk).
Sure it doesn't do any static compile time checking - or even check that you
typed your variable names correctly. So write decent unit tests, which you
should be doing anyway, and kill two birds with one stone. Just relax and
code

> I realize these changes would effect every piece of Ruby code but the
> language is still fairly young (at least with respect to it's version
> number)

?!

I believe the language is coming up for 15 years old. And what have version
numbers to do with anything? If it was called Ruby 9.0 instead of Ruby 1.9,
would that affect your opinion?

> and since it sounds like version 2.0 is going to break a few
> things it might be a good time to adjust a few names and conventions.

Absolutely there may be an opportunity for things like this. But whilst
there is clarity in the unclouded eye of the newcomer, there's also validity
in the thoughts of those who have immersed themselves more in the language
and applied it to a variety of real world applications.

> I'm sure a little Ruby script using regular expressions could rename
> everything quite easily.

That statement demonstrates that you haven't gotten very far into Ruby at
all

Firstly, the Ruby language is a complete pain to parse correctly. This is
one of its wrinkles. There's no formal grammar for it as far as I know, and
the C parser has lots of little rules and exceptions which means that things
like the position of a single white space can affect how a line is parsed.
This is all done so that the language "does the right thing" in as many ways
as possible, and generally works well. But it's hard to understand, and it's
hard to re-implement a parser from scratch which behaves the same as the
supplied one.

Secondly, the language is *totally* dynamic. If you see "puts foo" then this
could mean pretty much anything at runtime; classes can be loaded and
methods redefined a long time after the program starts *running*. Method
dispatch is dynamic, and you can call a method without even referring to it
by name. So you can't just parse the source code and make a
search-and-replace substitution and expect your program to be "fixed".

> I love promoting Ruby with
> co-workers but can't help but mention (or get asked) why some things
> like this look kind of silly.

You'll get to build your own personal list of wrinkles, believe me. But
there's reasoning behind all of them, and I'll think you'll find all the
benefits outweigh the overhead of stamp-collecting.

Regards,

Brian.

Brian Candler wrote:

> C doesn't have "print" but it has "printf", and that doesn't add a newline
> either.

Ruby has printf, though, which doesn't add a newline, too.

Looks like Ruby is making it easy for those Rubyists who are coming from
another language, or are switching to and from another one, too.

--
Phillip "CynicalRyan" Gawlowski

Rules of Open-Source Programming:

22. Backward compatiblity is your worst enemy.

23. Backward compatiblity is your users' best friend.

Hi --

On 3/24/07, Michael Brooks <> wrote:
> Hello:
>
> I've been using Ruby on-and-off for about 4 weeks now and love it.
> However, some of the naming consistencies really bug me. The ones that
> bug me the most are the "print", "puts" and "putc".
>
> I'd like to suggest that the functionality of the names "puts" and
> "print" should be swapped so that "print" automatically sends a newline
> character and "puts" doesn't. The reasons for this are as follows:
>
> - "print" in other languages I've used (e.g. Basic) sends out a newline
> character.
>
> - "putc" doesn't send out a newline so why should "puts".
>
> - The "puts" method sounds like a techier name so it shouldn't be doing
> console style formatting and "print" sounds like the name you'd expect
> to be using with terminal / printer based formatted output.
>
> Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
> etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
> etc... to keep their syntax consistent with the naming conventions used
> with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
> to "tos", etc... Either way, just make it consistent.
>
> At a minimum I think the "put_c", "put_s", etc... should be implemented
> and the "putc", "puts", etc... identified as obsolete syntax.
>
> I realize these changes would effect every piece of Ruby code but the
> language is still fairly young (at least with respect to it's version
> number) and since it sounds like version 2.0 is going to break a few
> things it might be a good time to adjust a few names and conventions.
> I'm sure a little Ruby script using regular expressions could rename
> everything quite easily. Alternately, new versions of Ruby could have a
> command line switch to run the old syntax but by default would run the
> new syntax.
>
> I apologize in advance for irritating anyone... I'm still new to Ruby
> and maybe I misunderstood some of the intentions behind the naming
> conventions. It's because Ruby is so consistent/smart in many other
> areas (I love the OO goodness) that this stuff (don't get me started on
> Find.find() or Benchmark.bm()) bugs me. I love promoting Ruby with
> co-workers but can't help but mention (or get asked) why some things
> like this look kind of silly.

This reminds me of the "old days" when so many people in the West
reacted to Ruby by saying, "I love this language, and by the way,
here's what should be changed to make it more attractive to
[Perl/Java/C[++]/...] programmers." My reaction was always: what
about Ruby programmers?

Very nostalgic It always struck me as a strange mix of an
inferiority complex (Ruby exists to serve the needs of people who
mainly use other, somehow more "real" languages) and ambition (Ruby
should strive to be perfect [whatever that may mean]). The truth is
neither. Ruby is just Ruby. It's being worked on constantly, but
it's not a candidate language or an apprentice language or even a new
language.

If your co-workers are going to have a pea-under-the-mattress reaction
to seeing anything they don't think is perfect in Ruby, they're
holding Ruby to an unrealistically high standard -- in fact, not even
high; just unrealistic. It's like pushing a lump around under a
carpet: if puts and print get exchanged, then someone else will think
things are worse; and if they get changed back, you'll think it's
worse, and so on. The way out of the loop is to do what Ruby in fact
does: it's designed by Matz, who listens extremely carefully to a lot
of advice but ultimately makes the decisions himself.

In fact... you should check out the various venues for discussing
changes in the language (here, ruby-core, RCRchive). We do it all the
time. If you want to suggest something, you don't have to package it
in meta-rationalizations about what Ruby should be -- you can just
suggest it.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

> > At a minimum I think the "put_c", "put_s", etc... should be implemented
> > and the "putc", "puts", etc... identified as obsolete syntax.
>
> "My minimum demands are: ..."
>
> One of the benefits I have found from using Ruby is that it actively
> encourages you to chill out. Accept things as they are. Sure, it's not lean
> and pure and orthogonal (if you want that, write in LISP, or Smalltalk).
> Sure it doesn't do any static compile time checking - or even check that you
> typed your variable names correctly. So write decent unit tests, which you
> should be doing anyway, and kill two birds with one stone. Just relax and
> code

Addendum: I also think if you're going to discuss changes to the language,
it's more interesting if they are *significant* changes.

Methods names are, well, just names. The methods work the same whatever you
call them. You can argue that one is more obvious than the other, or easier
to guess or to remember, but that will very much depend on the background
you are coming from. For someone who is a non-English speaker, they will all
be equally opaque. Most of us should be grateful that Ruby doesn't use SJIS
squiggles for its method names

I consider significant points to be *semantic*. These include:

(1) Semantic inconsistencies within the language. For example, there are
about 7 different ways to create a 'function' object (i.e. a block or proc),
and the semantics of calling them are subtly different, and indeed change
between versions of Ruby. I can recognise the different syntaxes, but I'd be
hard pressed to tell you from the top of my head how they differ
semantically.

(2) Semantic differences between ruby and apparently similar constructions
in other languages. Regexps provide an example; on the surface they look
very similar to perl, but underneath there are some important differences
you may not discover until it's too late.

For instance: in Perl, /^abc$/ matches only the string "abc". This is not
true in Ruby (although it *is* a valid regexp). To get the same behaviour in
Ruby, you need to write /\Aabc\z/

Regards,

Brian.