Switch to .ruby extension?

[David Garamond]

Yes it's a silly little thing. But ever since Y2K, I've been wary of
excessive abbreviation. Besides, it's the attention to the little
things that makes Ruby so appealing.

What things would explode if *.rb is not changed to *.ruby in 2038 or
3000?

I think we'll see .py -> .python first before we ever see .rb -> .ruby.

I vote -1.

 

[David Garamond]

The obsessive levels of abbreviation in the *nix world infuriate me.
Especially when it's so easy to make verbose and abbreviated commands
exist together, and do the same thing.

Of course you understand things like 'ls', 'pwd', 'cd', '/usr/bin', and
many other things in Unix are historical? They *did* need to abbreviate
things as memory was very very tiny back then.

I don't think Unix/Linux developers suffers from obsessive levels of
abbreviation right now. For example: Gnome programs are named very
verbosely: gnome-config, gnome-terminal, etc. Also see how Redhat,
Mandrake, Apple (OS X), etc. name their programs.

Of course, the filesystem layout will probably stay more or less the
same (or at least evolve very very slowly) because it's just too hard to
change paths and dirs in everything. There are efforts though, like
Gobolinux.

But I do find that many Perl programmers' tendency to abbreviate
everything is a little bit too much. $prog or $prg instead of $program,
$chg instead of $change, $txt instead of $text (please, it's just one
letter!), etc. This does infuriate me sometimes.

 

[David Garamond]

The current convention for Ruby source file names is to end them with
a .rb extension. This strikes me as too minimalistic. Why not .ruby?

What is your suggestion for .rbw (on Windows)? .rubyw? (Probably not,
since you _hate_ abbreviation . .rubywin? .rubywindows?

Also there might be .rbc (for compiled bytecode) or .rb2 in the future.
I'd hate to have too many letters as extension names.

I think there is also .rbx and a few others being used.

IMO, having a short "rb" prefix for all these is better than "ruby".

 

[David Garamond]

Actually, Unix editors aren't different - they're the same as every
other text editor was 20 years ago. That is to say, obsolete. (or should
I say obsol33t?)

Please, Unix editors like vi/vim and emacs _do_ evolve improve over time
(although I personally don't use vi & emacs). Tell that to Windows,
whose Notepad, last time I checked, hasn't even got a Replace
functionality. You said that Notepad has been superceded. Then Why
doesn't Microsoft include a better product (a text editor is certainly
as least as important as a web browser).

It's ironic you should sarcastically mention Chinese as being out of
date, because that's *exactly* how it's viewed in China. China has
always had a literacy problem because the Chinese language, the
characters specifically, were just too difficult to master. So, in
modern times, the Chinese government has pushed for it to be simplified
in an effort to improve literacy rates.

Taiwan still prefers the traditional instead of the simplified notation.

It's impossible to build a
technologically advanced populace when the primary barrier to entry
isn't higher education, it's mastering your own language.

Btw, there is a survey that Japanese/Chinese students score 3 IQ points
higher than American ones, and this is attributed to the character
system that the students use. Apparently, having to learn thousands of
different complex characters help developing the logical/spatial skills.

 

[David Garamond]

Hello Neil,



NS> What stops you from doing so now?

Some braindead lines in the ruby interpreter. You can't even "require" rbw files
without patching the hardcoded extensions names in eval.c

It's not braindead. It's _as designed_ The same for perl and python
(which will automatically add .pm or .py/.pyc/.pyo).

Do you expect ruby to check every possible extension?

 

[David Garamond]

It's not braindead. It's _as designed_ The same for perl and python
(which will automatically add .pm or .py/.pyc/.pyo).

Do you expect ruby to check every possible extension?

Forgot to add. I think .rbw is created specifically for Ruby scripts
that are to be called directly by the user (e.g. clicked from the
Explorer window). You are not supposed to name Ruby library files (that
are to be require-d from other scripts) as .rbw.

 

[Dick Davies]

Zach Dennis wrote:
Someone once told me to "RTFM" when I couldn't figure out how to work a
*nix text editor. I felt insulted, that he insinuated that *I* was the
one with the problem, not the text editor.

You wanted to know how to use a tool, and someone told you to read
the instructions, and you felt insulted?

There are hundreds of editors for *NIX, many are designed by people
who were used to a different OS or similar. You'd have to look
for them though, which I expect will enrage you

I know about those. They're the exceptions to the rule. I'm complaining
about the rules, not the exceptions.

Ah, I see, you know about the alternatives, but prefer to use a tool
you don't like and complain about it. God help you.

 

[Martin DeMello]

Someone once told me to "RTFM" when I couldn't figure out how to work a
*nix text editor. I felt insulted, that he insinuated that *I* was the
one with the problem, not the text editor. In fact, text editors are
dang near the oldest software technology we have. I've used dozens,
maybe even hundreds of them, and not once have I ever had to "RTFM"
before starting to use it, because they've all adopted the same
intuitive UI conventions that have worked well for a decade - Except for
*nix editors. They're 20 years out-of-date.

If you try to argue that typical *nix editors are in fact easy to use
(vi, et al), and it's "obvious" how to use them, as many *nix people do,
maybe you should step out of your geek-bubble and try learning something
completely new - maybe something that's also poorly designed and 20+
years out of date.

Just had to comment on this bit. vi isn't easy to *learn*; it's easy to
*use*. You can do a lot of very powerful stuff with surprising ease, far
more so than in the more userfriendly editors. emacs too, espcially if
you're an octopus There's a *reason* people still use them over more
standardised editors, and 'geek cred' isn't it.

martin

 

[James Britt]

David Garamond wrote:
...

Please, Unix editors like vi/vim and emacs _do_ evolve improve over time
(although I personally don't use vi & emacs). Tell that to Windows,
whose Notepad, last time I checked, hasn't even got a Replace
functionality.

Ctrl-H




James, happy gvim user on Windows and 'nix.

 

[Michael Campbell]

David Garamond wrote:
...


Ctrl-H



James, happy gvim user on Windows and 'nix.

"Bah! Ctrl-H for replace?! That's unintuitive and user-unfriendly.
Therefore, broken, behind the times, and personally infuriating."



<sorry, was just trying to get into the spirit of this thread.>

 

[Karl von Laudermann]

What stops you from doing so now?

Well, at home I have a Mac, so I will probably use .ruby from now on,
since I can just start each file with the line "#!/usr/local/bin/ruby"
to tell it how to run. However, I'll have to specify the full filename
when I use the require or load methods. But at work, where I use
Windows, I'd have to manually map the .ruby extension to ruby.exe on
every machine that the scripts have to run on. I will have to remember
to do this each time a new machine needs to run my Ruby scripts, when
I first install Ruby on it. So I'll probably stick to .rb at work.

I'm just proposing the following:

1) Ruby should be modified so that you don't have to specify the file
extension when using require or load, if the file ends with .ruby,
just like is already true with files that end with .rb.

2) The Windows installer should associate .ruby with ruby.exe, just
like it already does with .rb

AFAIK, these are the only two things that would need to be done to
make .ruby as "supported" an extension as .rb is now.

But ideally, I'd also like to see a switch to .ruby as being the norm
in the Ruby community. That means that, for example, if a newbie is
reading a Ruby tutorial, the tutorial might say "Ruby scripts are
typically stored in files ending with .ruby", whereas right now such
existing tutorials would say .rb instead. Also, if said newbie is
downloading sample Ruby programs, he would see that the files
typically end in .ruby.

To the person who said that users will never see installed library
files, I must respectfully disagree. I know that I've poked through
the Ruby lib directory out of curiosity to see what's there. And when
I download a new library, I generally poke through the installer
directories before running the install. Heck, usually the library has
an install script called setup.rb at the top level of the installer
directory, so there's no way to avoid seeing that. So my point is, I
do often see files ending in .rb that I didn't write. The impression I
can't avoid getting is that .rb is the standard extension, and that
it's what I therefore should use myself.

To sum up, what I'm saying is, I'd like to see .ruby become supported
as a standard extension, just like .rb already is, by doing the 2
things mentioned above. In addition, I'd *ideally* like everyone to
agree with me and start treating .ruby as the standard extension, so
that newbies will get the impression that it's the standard extension
when they see everyone else's Ruby files. But I realize that different
people have different tastes, so I'm not holding my breath on the
latter. Simply having both extensions be supported is fine.

Now if you'll excuse me, I'm going to go to the Perl newsgroup and
propose that they change the standard extension from .pl to something
more Perl-like, such as .$`_

 

[James Britt]

...

But I do find that many Perl programmers' tendency to abbreviate
everything is a little bit too much. $prog or $prg instead of $program,
$chg instead of $change, $txt instead of $text (please, it's just one
letter!), etc. This does infuriate me sometimes.

The May issue of The Believer [0], a literary mag published in the USA,
has an article by David Ng ostensibly about the literature of software
development.

He discusses what he sees as geek pride and bravado in using languages
that lend themselves toward complex and/or terse code. In his view,
hardcore geeks disparage Visual Basic in favor of Java because VB is too
easy to learn and read; perl gets extra high points for executable line
noise and the barrier to comprehension (at least for outsiders). He's
somewhat right, at least to the extent that there exists a juvenile
coder subculture that values obfuscation. (I suspect that these are the
same people who write 'windoze', or knock the use of variable names
longer that 3 characters.)

Ng misses the real point, which is that the better hackers prefer
languages that enable expressiveness. Often, the easy-to-learn,
easy-to-use language is also "dumbed down" in some way to impede any
real code eloquence. But hackers aren't looking for complexity for its
own sake (though it may come as a side effect).

It's the job market and management that pushes them toward Java; it's
the thought-to-code ratio that draws them to Lisp, Ruby, and so on.


James

[0] http://www.believermag.com/

 

[David Garamond]

He discusses what he sees as geek pride and bravado in using languages
that lend themselves toward complex and/or terse code. In his view,
hardcore geeks disparage Visual Basic in favor of Java because VB is too
easy to learn and read; perl gets extra high points for executable line
noise and the barrier to comprehension (at least for outsiders). He's

I used to think Perl is a pretty good line noise until I see this:

http://www.kx.com/a/k/examples/xhtml.k

I swear that when I first saw it, I thought my browser was displaying
garbage (like when the browser is viewing a gzip-encoded webpage verbatim).

 

[Lothar Scholz]

Hello David,

DG> I used to think Perl is a pretty good line noise until I see this:

DG> http://www.kx.com/a/k/examples/xhtml.k

DG> I swear that when I first saw it, I thought my browser was displaying
DG> garbage (like when the browser is viewing a gzip-encoded webpage verbatim).

Cool. And this code does contain comments

 

[Mike Hall]

My beef is with *nix people who think user-friendliness is a bad thing -
A threat to their way of thinking. It's utter nonsense.

You're right, of course. However, I'd suggest you take the time to read
"The Art of UNIX Programming" by Eric S. Raymond, which helps explain
why things are the way they are. Not to defend the status quo, but to see
the history and choices made along the way, to see the alternatives which
didn't last.

For example, some OSes have a very long-winded command line,
and thus never developed the utility of UNIX's shell.

 

[Neil Stevens]

Well, at home I have a Mac, so I will probably use .ruby from now on,
since I can just start each file with the line "#!/usr/local/bin/ruby"
to tell it how to run. However, I'll have to specify the full filename
when I use the require or load methods. But at work, where I use
Windows, I'd have to manually map the .ruby extension to ruby.exe on
every machine that the scripts have to run on. I will have to remember
to do this each time a new machine needs to run my Ruby scripts, when
I first install Ruby on it. So I'll probably stick to .rb at work.

I don't understand why it matters what the file names are for libraries.
What are you going to do if/when ruby starts getting some preprocessing
like Python gets? If you're hard-coding the full file names that'll break
your scripts, won't it?

The only user-visible file names are the script names, so those seem to be
the only ones that should matter.

Yes, make sure to do /usr/bin/env ruby, not /usr/local/bin/ruby. The former
will work work for more people (like those who have to put ruby in
$(HOME)/bin).

 

[Tyler Zesiger]

Tyler Zesiger wrote:




You're right, of course. However, I'd suggest you take the time to read
"The Art of UNIX Programming" by Eric S. Raymond, which helps explain
why things are the way they are. Not to defend the status quo, but to see
the history and choices made along the way, to see the alternatives which
didn't last.

For example, some OSes have a very long-winded command line,
and thus never developed the utility of UNIX's shell.

I think Unix is my OS of choice for this very reason. I do most
everything I need through the command line.

 

[Zach Dennis]

Dick,

Zach Dennis wrote:
Someone once told me to "RTFM" when I couldn't figure out how to work a
*nix text editor. I felt insulted, that he insinuated that *I* was the
one with the problem, not the text editor.

I didn't write that line, Tyler did.

Just to clear things up.

Zach

 

[Tyler Zesiger]

I take credit for all the tom-foolery in this thread.

 

[Karl von Laudermann]

I don't understand why it matters what the file names are for libraries.
What are you going to do if/when ruby starts getting some preprocessing
like Python gets? If you're hard-coding the full file names that'll break
your scripts, won't it?

I'm talking about my own multi-file Ruby programs, not libraries. If
my main script uses require or load to access the other scripts in the
same directory, I either have to name those other scripts with .rb, or
include the extension in the require/load command.

Or am I the only one who splits my larger Ruby programs into several
files for managability? Maybe it's just a habit I've carried over from
Java.