Yukihiro Matsumoto, the creator of the Ruby programming language, talks with Bill Venners about morphing interfaces, using mix-ins, and the productivity benefits of being concise in Ruby.

Read this Artima.com interview with the creator of Ruby:

http://www.artima.com/intv/tuesday.html

What do you think of Matz's comments?

Some interesting points. One I think he got right but for the wrong reason is where he picks up the point about Perl users going in for the sample code solution and Ruby users only needing a library method. Principally he's right. But a new user to Ruby wouldn't necessarily know about the library method and hence might not know to use it. I think the documentation is much more important. So that the new user can quickly find either the sample code or the method. If the programmer can find the sample code much faster than the library method, then this will be the faster solution. If, however, the documentation is very well structured and the programmer can easily find the library method, then this is faster. To me, one of Java's greatest strengths is the documentation. It is very easy to learn to find your way around it. I think many people underestimate just how imporant a part of Java its documentation is.
Just my 2¢ :)
C

I agree partly. Documentation is really important.
Ruby had been awful at this in the past, but it's getting better.

Ruby offers 2 important tools for this: RDoc for documenting api, just like javadoc, and ri for quick search in the builtins.
ri is really cool, and it may bring you what you need incredibly fast.
i.e. if Joe User wants to sort a collection:

$ri sort
The method named `sort' is not unique among Ruby's classes and modules:
Array#sort, Enumerable#sort, Hash#sort

ri Enumerable.sort
(this shows syntax and points you to sort_by)

But I have a thought that seem important to me. Possibly it is just a too much subjective impression, but it seem to me that in ruby most of the time you write something and , well, it just works.

After 3 years of java I still need to look at the javadoc API very often.
In ruby, you just need to look at the RDoc api when you start to use a new library and suddenly you may discover that it just works as you expect it to work.

In my (biased) opinion it's much easier to find a method in Ruby as it is in Java (or Perl), at least for the standard libraries (which are essential, as used all the time).

You don't even need a web-browser or documentation at all. Just start you interactive Ruby interpreter (irb), then press TAB after entering "anObject.", which then immediatly provides you with all methods this object responds to. Alternatively type e.g. Array.methods to list all methods an object of class Array responds to.

The advantage against Java is, that you can test the method on-the-fly (interactivly, with actual values, and intermediate results) without the need for opening an editor, compiling and running, then starting the debugger or inserting trace code to locate the position where it's not working. At least this is very valuable (and time-saving) for prototyping e.g. a new algorithm or whatever else.

Lots of possible errors can be found this way, before actually writing the program, just by testing these little code-snippets interactively.

I agree partly. Documentation is really important.
Ruby had been awful at this in the past, but it's getting better

A good place to find Ruby documentation is http://www.ruby-doc.org. It has a dcoumentation bundle with various FAQs, tutorials, and API docs, as well as numerous online information, videos, and translations.

I found this quote enlightening: "And because there are so many dynamic checks in dynamic languages, in most cases something very terrible usually does not happen." Seems like he readily admits there are some areas left for other languages.

It's a refreshing change from the usual my-language-can-do-everything-better-faster-safer-prettier-than-yours attitude.

> The advantage against Java is, that you can test the
> method on-the-fly (interactivly, with actual values, and
> intermediate results) without the need for opening an
> editor, compiling and running, then starting the debugger
> or inserting trace code to locate the position where it's
> not working. At least this is very valuable (and
> time-saving) for prototyping e.g. a new algorithm or
> whatever else.
>
> Lots of possible errors can be found this way, before
> actually writing the program, just by testing these little
> code-snippets interactively.

I continue to use the KAWA IDE for java (many years discontinued) specifically because it provides an extremely fast compile and run cycle. I have tried many other IDEs (you can't find much of anything that doesn't have the sheer weight of J2EE hanging over it any more), and have yet to find something as simple and effecient for me to use as KAWA. I have been working on a replacement written in Java that is a shameless copy of the UI.

I think that one of the new things in java, that perhaps very few people are using is the java.util.logging package. I find it extremely convenient to just do

    Logger log = Logger.getLogger( getClass().getName() );

in the class definition. I can then turn on and off logging in each class and at various levels. I am planning on putting a logging pane into the my IDE that will use annotations (jdk1.5) to find the logging setup in each class, and provide a mechanism to let me dynamically reconfigure logging while I am developing.

With Jini services, I think that I'll use annotation to point out that there is a "LoggingAdmin" implementation visible in the service, and let the IDE find the ServiceUI for that, and display it in the IDE while I am developing. This would make it possible to change the logging while the program is running and thus have a pretty interactive debugging facility.

>
> I think that one of the new things in java, that perhaps
> very few people are using is the java.util.logging
> package. I find it extremely convenient to just do
>
>

> Logger log = Logger.getLogger( getClass().getName()
> e() );
> 

>
> in the class definition. I can then turn on and off
> logging in each class and at various levels.

well, in ruby you can safely create a module with the logging stuff, based on logger.rb (standard distribution)
and plug them at runtime, having them fully out of the class definition.

This is someway like a little part of AOP, I suppose..


>I am
> planning on putting a logging pane into the my IDE that
> will use annotations (jdk1.5) to find the logging setup in
> each class, and provide a mechanism to let me dynamically
> reconfigure logging while I am developing.

still, I think this is much more easy to do in ruby than it is in java :) but I'll like to see your editor when it comes out..

" To add behavior to the button in other languages, you create a subclass of Button and override the click method. But in Ruby, if you want, you can directly replace the click method in class Button. "

If I want to add behavior to a JButton then I must override the click method? I guess that's one way but most of us add an implementation of ActionListener to the button.

Taylor

I think this example may be misleading. The point is that, in many languages, you don't need a subclass to change a button's callback method.

I think you should try to extract the concept from this sentence.
When, in most languages, you have to subclass, in ruby you can just change an instance to behave that way. For example, if you have something like

pay(aPerson)

that uses a method like aPerson.current_salary()
you don't need to create a subclass of Person like ChiefExecutiveOfficerPerson to change current_salary() you may just add a singleton method to Person.

Or you can just add a method to an object that is not even
aware of that, like a to_xml() or persistence-related stuf like save()/update()/retrieve()

BTW, I rarely used something like this for common Objects.

The point is that in ruby everything is an Object, and thus you can change the behaviour (or add a new one ) of a Class or of a whole Class hierarchy.

For example, the YAML.rb module, adds methods to the whole ruby world to dump objects as YAML and to retrieve them,

And, class methods are actually singleton methods of Class objects.

It is quite impressive how ruby is based on a few concepts, applied smartly, and singletons are one of those