Re: New presentation on Ruby

As for any presentation, there are a lot of things that are said and that
are not written in the slides.


2007/4/2, Ilan Berci <[e-mail]>:


> >Slide 12) Doesn't illustrate duck typing at all as I can write the exact
> >same thing in Java.  You could have illustrated the point more
> >accurately by assigning the types to a temporary and then invoking the
> >method
> >class Duck; def quack; "quack"; end; end;
> >class Bird; def quack; "chirp"; end; end;
> >[Duck.new, Bird.new].each {|duck| duck.quack}


As stated in the slide, "The type of an object is defined by what that
object can do (and not by its class/interface)."

In the code snippet,
- I do not have to declare the type of a variable
a_duck = Duck.new
- I can request an object to walk and it will work if the object has the
corresponding method
a_duck.walk
As Duck defines a walk method, the above request will succeed and there is
no need for having a type defining the walk capability.
This is quite relevant regarding duck typing.


>Slide 13) Doesn't add anything that wasn't already mentioned in slide 12


From the Ruby side, there is nothing new.
The point here is to indicate that there is no need to have an interface
concept like in Java for having different implementations.


>Slide 14) You are implying that Java's containers do not support
> >heterogeneous types which it does and since JDK 1.5 and the insertion of
> >generics,  your point about downcasting is also moot.

>Slide 15) All wrong, please see comments for slide 14


As stated in slide 15 :
- I just said that Java untyped collections or generic collections for type
Object DO support heterogeneous types.
But the drawback is that you NEED to downcast a retrieved element.
- Conversely, if you use a generic collection for a type X (e.g.
TalkingAnimal) different than Object, you can put only objects of type X.
You cannot put an object that is not of type X (e.g Rabbit2)
You avoid most downcasts for retrieved elements. Thus you can retrieve a
TalkingAnimal and call talk.
But if you put an object of type Y that extends the capability of X
(e.gDuck2) and you want to call a method of Y (
e.g. walk), then you need to downcast to Y.

Tell me what is wrong about that ?


>Slide 16) Your comments also apply to static languages, the need for
> >testing is equal to both types of languages.  There has been no
> >quantitive study on the reduction of bugs due to static language's
> >compile type checks (and has been discussed to death on this list).  I
> >believe you are misleading your intended audience here


Exactly. I just want to mean that the important thing here is testing and
not type checking whether static or dynamic.


>Slide 17) What does talking about  Erlang have anything remotely to do
> >with Ruby especially in the context of which it's being posed:
> >dynasism(spelling).  So what if I can build a fault tolerant system in
> >Erlang, can I do it in Ruby????  Erlang and Ruby couldn't be more
> >different in their approach and implementation.  The only thing they
> >share is "some" aspects from functional language sets.  Comparing the 2
> >is like comparing apples and farmers


I just want to mean here that they are both dynamic languages but good ones.



> >Slide 19) I don't have to make a custom class to convert a type or
> >modify some behaviour, I can simply open up the class and mess with it
> >(as you yourself mentione later in the slide show).  Secondly, it
> >"doesn't have to make sense" and I can do it regardless of my level of
> >sanity as I do most things.


You're right. "Custom class" is too restrictive.

In my example, I use the to_str coercion method. This is an easy
illustration of type conversion to a String.
But my Complex class cannot be used like a String in all cases.
"if it really makes sense" is just a caution. to_str is definitively
different than to_s.


>Slide 22) If "top level functions" are "private" methods of class
> >Object, there would be no way to call them without a receiver which is
> >simply not the case



They are private methods of Object.


>Slide 23) Although I would intend to agree with you here, James Britt
> >certainly won't.  This is an argument that has gone back to the 70's and
> >both sides are in war escalation mode right now.
> >Anyways, if you are going to mention buzzwords, you should mention
> >polymorphism below encapsulation and mention inheritance at the bottom
> >as it's the view of Peter Coad and many others that inheritance violates
> >efforts at encapsulation and therefore usually aggregation is the better
> >choice.


These are only two of the main features of OO that are particularly well
captured in Ruby.


>Slide 24) Point about attributes only allowed to be defined within their
> >class definition is wrong.  In ruby I can define one almost anywhere
> >with Object::instance_variable_set or Module::module_eval.


The normal way is encapsulation. But you can break encapsulation as stated
in slide 37.


>Slide 26) Who are you to say what "private" means.  Each class has their
> >own definition and either could be viewed as the truth.
>

In C++ and Java, an instance of a given class can access the private members
of another instance of the same class.
In the real life, this is not the case. We're both Human or instances of
class Human, but I don't want you to access my private data.

Related with slide 23, Ruby encapsulation reflects better the real life.


>Slide 27) How is C++ multiple inheritance complex?  It may be complex
> >for a compiler but I am not a compiler.. :) If you are referring to
> >diamond ambiguity, then I would agree with you but you don't explain
> >yourself here.   Stating that java's single inheritance is "annoying"
> >won't win you any friends but will invite flames your way.  Is there any
> >way you could state it differently?


The diamond ambiguity is one point. The other point is virtual inheritance
when you want to have only one instance of a base class that is inherited
multiple times.
Regarding Java, it is just a fact.


>Slide 28) Your statement under benefits makes absolutely no sense.


I don't know how to say it differently.


>Slide 32) Again you bring up Erlang and concurrency but Ruby is not
> >Erlang and can obviously have side effects from method invocation.  In
> >fact, if it didn't, we couldn't change the state of any object!  Are you
> >trying to sell Ruby or Erlang here?  In Erlang, I can't change the
> >variable once it's instantiated.. <-- see that doesn't have anything to
> >do with anything either!


Slide 31 and 32 are principles of Functional Programming as stated in the
title.
In slide 32, I just give examples of "functional style" code in Ruby.

I never say that Ruby is a pure Functional Programming language. See slide
33.


>Slide 34) Subjective analysis again.  Anonymous Java classes are not
> >very difficult at all and there are indeed issues with closures that are
> >being addressed for ruby 2.0


Anonymous Java classes are not difficult but you have to write a lot of
code.
Ruby Blocks are thus easier to write. This is an objective fact.

>Slide 47) Will anger many readers as it's subjective again.  Please play
> nice!


Unlike defining a function, defining a method in Python requires self as the
first parameter.
There is a lack of uniformity of definition between a function and a method.
What is subjective ?

If you find that I made errors, please correct me.
But I always try to be fair.


>Slide 53) Subjective to the point of insanity..


What I want to mean here are :
- Java has introduced a lot of features simplifying the work of programmer
(garbage collector to simplify memory allocation...)
- Ruby adds another level of simplification (dynamic typing, block/closure
...)
This is the reason why Groovy has been created.

I've programmed both in Java and C++ and I'm firmly convinced that we have
to integrate technologies.
See the title of this slide.


>I like the style and presentation but some of your comments have to be
> >corrected and you should make an effort not to irritate python, php,
> >java, and c++ developers..


Great. I hope that my answers will make you like it more :-)

>let us know how it was received..


Very well.
This has already been presented. There were Java, Python and PHP
programmers.
What the audience liked was the "pragmatic approach" constituted by the
comparison of features with things they already know in Java, Python and
PHP.


Again, there are a lot of things I said and that are not written in the
slides.
This is why I will develop these slides with some future posts in my blog.


Chauk-Mean.
http://selfreflexion.free.fr/