From: matt <matt@...>
Date: 2006-12-31T03:07:44+09:00
Subject: Re: Little Things


Thanks for bringing these slides to my attention.  This one caught my
eye:
http://www.rubyist.net/~matz/slides/rc2006/mgp00027.html

"We need to Document Ruby (if Possible)." as part of the Design Game of
improving Ruby.

That kind of a statement is what could potentially kill the language.
We can have the best language on the Planet, but if the language
features are only accessible to those that are willing to go code-diving
for the answers, then the target audience is going to be slim.

The truth is that there are a lot of well intentioned programmers out
there, but they don't have the first clue (or inclination) to go digging
deep into the bowels of Ruby (or any language).

That is why some of the less elegant languages have succeeded, and have
such a large following.  It is (in large part) because of there
documentation. It is up-to-date, adequate, easy to search, and
well-defined.

I don't pretend that all share my view on documentation, but for the
Ruby leader/CEO to put documentation so far down on the list I think is
going to make it difficult for language to grab ahold of programming
share the way that Perl, Python and PHP have.

my .02

Matt






On Sun, 2006-12-31 at 02:27 +0900, Trans wrote:
> I was a bit surprised about Matz mention of the little things in his
> last <a
> href="http://www.rubyist.net/~matz/slides/rc2006/mgp00017.html">ketynote</a>.
> Little things can make all the difference! In fact, long time Rubyists
> have been waiting a long for some important "little" things. Here's
> some of the things on my little list....
> 
> * Binding.of_caller. Yes, it's easy to abuse, and should be avoided at
> nearly all costs. But there are few pennies worth when nothing else
> will do. Some very cool metatricks are made possible by being able to
> access the caller's binding --the breakpoint lib being the most well
> known.
> 
> * <code>object_class</code> instead of </code>class</code>. I get sick
> just looking at <code>self.class.foo</code>. And it prevents use of
> "class" for other variables/methods. (Hence the all too frequent use of
> "klass"). <code>object_class</code> on the other hand is nicely
> analogous to <code>object_id</code>.
> 
> * Allow a comma between the two <code>alias</code> arguments --getting
> an error on that is really annoying. Actually why is <code>alias</code>
> a keyword? Why have both <code>#alias_method</code> and
> <code>alias</code>? I have always been told that keywords were to be
> avoided.
> 
> * <code>String#resc</code> as an inversion of
> <code>Regexp.escape(string)</code> and <code>String#to_re</code> as an
> inversion of <code>Regexp.new(string)</code>.
> 
> * I'm dying here from remove_method hacks without
> <code>#instance_exec</code>. This has to rank in the top three "little
> things" that have been talked about forever, and it isn't that hard to
> implement. So what's holding it up?
> 
> * A block can't take a block, nor default arguments. What kind of
> <code>define_method</code> is this? I realize this a trickier issue.
> But at some point the trick has to be performed.
> 
> * Close the closures. Writing DSLs is great, but have you noticed they
> all share the same closure? Have a way to reset the closure with some
> sort of special block notation would shore-up this danger hole. Maybe:
> 
> <pre>
>   a = 1
>   dosomething do! |x|
>     p a  #=> error
>   end
> </pre>
> 
> * Another hassle when metaprogramming. <code>#send</code> should work
> for public methods only! There's a big issue with backward
> compatibility here. I have the solution: <code>#object_send</code>.
> It's a better name anyway b/c it stays out of the way (eg. my Email
> module would like to have a #send method, you dig?). And #send itself
> could be deprecated slowly. BTW <code>#funcall</code> for the alternate
> private-accessing send is a <b>terrible</b> name, try
> <code>#instance_send</code>. (And yes, I'm begging here!)
> 
> * This one's more of my own pet-peeve but nontheless, who wouldn't want
> a nice word alias for Class#===. In most cases I prefer to read what
> I'm doing rather then recall the interpretation of a symbol. There are
> of course some symbols that are rather obvious, either by indication of
> their form (eg. <<) or by their widespread use (eg. =), but Class#===
> is not one of them. I would much prefer to see:
> 
>   <pre>
>     MyClass.instance?(myobject)
>   </pre>
> 
> But I'm not picky about what word to use as long as it's readable.
> 
> * Oh, and lets not forget the forever arguable method name for (class
> << self; self; end). But please give us something concise.
> 
> No doubt there other little things left unmentioned, and obviously some
> are more important than others. But in any case, it's clearly striking
> that after hearing for so long about many such well-accepted "little
> things", that Ruby has yet to take them in. I have a silly theory about
> this actually --as odd as it may seem. The 1.9 version is the last on
> the chain before 2.0 b/c matz is against using double-digit minor
> numbers, eg 1.10. So we're is stuck with 1.9 as his test bed for 2.0.
> Since 1.8 can only increment by teeny, these "little things", being not
> little enough, can't make it in. Hence Ruby is being held back by a
> version number policy!!! I think Matz just needs to get on with it (hey
> look forward to 3.0!) or just lossen the version policy constraints.
> 
> T.
> 
> PS. [And, yes, I took my own advice. I removed this from my blog --"it
> is better to share than to own".]
> 
>