From: Brian Candler Date: 2007-03-25T05:29:52+09:00 Subject: Re: Suggestion: swap name of "puts" and "print" and rename "puts" to "put_s" 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.