Suggestion: swap name of "puts" and "print" and rename "puts

[michaelb]

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

[michaelb]

Le samedi 24 mars 2007 15:40, Michael B. a écrit :

Michael
The names of the methods puts and putc obviously come from the C
language,
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 :
« Consistency does not come first in the Ruby’s design. »

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

Regards,

[michaelb]

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 B. [email protected] wrote:

• “print” in other languages I’ve used (e.g. Basic) sends out a newline
  etc… to keep their syntax consistent with the naming conventions used
  I’m sure a little Ruby script using regular expressions could rename
  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:

Site not found · DreamHost

http://www.rubyinpractice.com/

[michaelb]

well, the methods are already syntax consistent, where you can use put

print == printf, and puts is “put string” (I think, someone correct me).

And one of the things I like most about ruby is that there are more than
one
way of using the same commands (e.g. the for loop sugar).

[michaelb]

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

[michaelb]

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael B. 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

[michaelb]

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

[michaelb]

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

[michaelb]

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael B. 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.

[michaelb]

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.

[michaelb]

Hi –

On 3/24/07, Michael B. [email protected] wrote:

• “print” in other languages I’ve used (e.g. Basic) sends out a newline
  etc… to keep their syntax consistent with the naming conventions used
  I’m sure a little Ruby script using regular expressions could rename
  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

[michaelb]

On 3/25/07, Brian C. [email protected] wrote:

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

Strongly disagree - method names are the user interface to your
language, and as such pretty important. Also, a bad decision gets
progressively harder to undo, so they’re worth taking some time and
trouble over.

martin

[michaelb]

Hi –

On 3/24/07, Brian C. [email protected] wrote:

(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/

Ha – talk about nostalgic – when you wrote “Ruby borrows a lot from
perl - in my own opinion a little too much” in your previous post, my
first thought was, “I wonder if that means he’s reconciled to the
anchors thing.” (I guess not

David

[michaelb]

On Sun, Mar 25, 2007 at 06:48:02AM +0900, David A. Black wrote:

Ha – talk about nostalgic – when you wrote “Ruby borrows a lot from
perl - in my own opinion a little too much” in your previous post, my
first thought was, “I wonder if that means he’s reconciled to the
anchors thing.” (I guess not

Well, I think I am, more or less. It’s just an example of the kind of
language difference which is more significant than just the name of a
method. It’s still fresh in my mind though

“Borrows a little too much from Perl”: I was thinking of the global $_
variable, and Kernel#print / Kernel#gets which implicitly use it.

There’s one time I use this construct, and that’s when running Perl from
the
command line to extract values from lines:

$ perl -ne ‘print “$1\n” if /foo=(.*)/’

I still automatically use Perl for this. I had in my head that the
equivalent Ruby would be something like:

$ ruby -ne ‘puts $1 if /foo=(.*)/ =~ $_’

Given that $_ is invoked explicitly there, you might as well write

$ ruby -ne ‘puts $1 if /foo=(.*)/ =~ gets’

and not have the implicit $_ operation at all.

But checking this out, it looks like Ruby has special-cased this:

irb(main):006:0> $_ = “abcdef”
=> “abcdef”
irb(main):007:0> puts “xxx” if /abc/
(irb):7: warning: regex literal in condition
xxx
=> nil
irb(main):008:0> puts “xxx” if /ghi/
(irb):8: warning: regex literal in condition
=> nil

Ugh. So the rule which says “anything which is not ‘nil’ or ‘false’ is
true”
is broken in this construct, and this is just to make ruby more perlish.

I also find it a bit of a pain that gets follows Perl by reading from
all
files listed in ARGV. This means that when you really do want to read
from
stdin, and your program uses ARGV for other things, then you have to
write
“$stdin.gets”

Regards,

Brian.

[michaelb]

Hi –

On 3/25/07, Brian C. [email protected] wrote:

Ugh. So the rule which says “anything which is not ‘nil’ or ‘false’ is true”
is broken in this construct, and this is just to make ruby more perlish.

Hmm. Thinking about this a bit more: since this applies only to regexp
literals,

do_something if /foo/

would not be of any use if it were semantically equivalent to

do_something if true

When I first saw this:

irb(main):001:0> puts “yes” if a = 1
(irb):1: warning: found = in conditional, should be ==

I found it annoyingly micromanaging – until I saw that it only
happened with literals, and then I realized that it was being very
shrewd. It’s interesting, then, that this non-construct can be used
to do the $_ thing. I wonder whether other cases, like if a = 1, are
going to pressed into service I hope not; I think the fact that
the regex one warns you and then goes ahead and does something other
than what it’s warning you against suggests it could get pretty ugly.

If that’s true, the construct clearly has to use $_ to fulfil its purpose

I’d love to see some of the Perl stuff disappear, and it’s perenially
in the Ruby TODO file. I can hardly think of a case where I’ve seen
anyone use $_ in Ruby.

David

[michaelb]

On Mar 25, 2007, at 5:31 PM, David A. Black wrote:

But then I realised: perhaps this is all just a marketing scam.
its purpose

I’d love to see some of the Perl stuff disappear, and it’s perenially
in the Ruby TODO file. I can hardly think of a case where I’ve seen
anyone use $_ in Ruby.

I came to Ruby from Perl, and the $_ et al. definitely hooked me. But
I quickly drank the Kool-Aid and I haven’t used the $_ in years.

–be

[michaelb]

Ugh. So the rule which says “anything which is not ‘nil’ or ‘false’ is true”
is broken in this construct, and this is just to make ruby more perlish.

Hmm. Thinking about this a bit more: since this applies only to regexp
literals,

do_something if /foo/

would not be of any use if it were semantically equivalent to

do_something if true

So I started thinking along the lines of: instead of using global
variable
$_ as a kind of temporary register to pass data between methods, how
could
this construct be made more Rubyish? For example, like a case statement,
“if /foo/” could translate to “if /foo/ === self” ?

But then I realised: perhaps this is all just a marketing scam. Maybe $_
and
friends exist in the language, not because they have any real use, but
just
to sucker in Perl programmers. They see them there, and think “great,
this
is like Perl, I’ll give Ruby a try”. Once they’re hooked, they won’t use
them any more than the rest of us do.

If that’s true, the construct clearly has to use $_ to fulfil its
purpose

Regards,

Brian.

[michaelb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mar 24, 2007, at 4:30 PM, Brian C. wrote:

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/

?

I don’t follow…

irb(main):006:0> a=“abc”
=> “abc”
irb(main):007:0> a =~ /^abc$/
=> 0
irb(main):008:0> a=“abcd”
=> “abcd”
irb(main):009:0> a =~ /^abc$/
=> nil
irb(main):010:0> a=“aabc”
=> “aabc”
irb(main):011:0> a =~ /^abc$/
=> nil
irb(main):012:0> a = “something else with abc in it”
=> “something else with abc in it”
irb(main):013:0> a =~ /^abc$/
=> nil

David M.
Maia Mailguard http://www.maiamailguard.com
[email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGBvx8Uy30ODPkzl0RAjSSAKC1/YbgHml5r9qzhKqpnsuJXQAqqACfUcOv
W0BpRw0M+laAr9IT7cRFhGU=
=q0k0
-----END PGP SIGNATURE-----

[michaelb]

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.

Note that Ruby is written in C and that C’s “puts” does return
carriage while its “printf” does not. Also note that POLS (principle
of least surprise) precisely taken is POLS2YM (principle of least
surprise to Yukikiro Matsumoto). Your suggestion seems to violate
this principle.

But now that you bring up the subject: What about adding a consistent
definition of write and write_ln? This would only change very little
and - which IMHO is important - does not unbearable introduce version
incompatibility. Changing the name of the basic output functions
would surely break literally every Ruby program. In other words: The
cost of changing them is much larger than the cost of living with
this kind of Altlast (“legacy” is one possible translation for this
word but it has quite a lot of other meanings as well, see
dict.leo.org or similar).

Josef ‘Jupp’ Schugt

[michaelb]

On Mon, Mar 26, 2007 at 07:49:38AM +0900, David M. wrote:

irb(main):006:0> a=“abc”
=> nil
irb(main):012:0> a = “something else with abc in it”
=> “something else with abc in it”
irb(main):013:0> a =~ /^abc$/
=> nil

irb(main):001:0> a = “rm -rf /\nabc\nreboot"
=> "rm -rf /\nabc\nreboot”
irb(main):002:0> a =~ /^abc$/
=> 10