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 B. [email protected]:
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 B.
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/
