Chauk-Mean P wrote:
Now that the licensing issue is cleared and the used font is more
readable,
I would appreciate some feedback on the content.
Indeed, I intend to develop some of the described facets of Ruby more
deeply
(article form rather than slide form) in the future.
Sure thing, I am totally burnt from bug fixing so I will comment on your
slides
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}
Slide 13) Doesn’t add anything that wasn’t already mentioned in slide 12
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
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
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
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.
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
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.
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.
Slide 26) Who are you to say what “private” means. Each class has their
own definition and either could be viewed as the truth. Given that, I
can still access private methods in a class by going through send() so
your statement is not correct
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?
Slide 28) Your statement under benefits makes absolutely no sense.
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 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
Slide 47) Will anger many readers as it’s subjective again. Please play
nice!
Slide 48) Why does the omission of class methods make a language less
object oriented. Seems to me that class level scope is akin to global
scope but is wrapped in a cute namespace. Variables exposed at class
level keeps developers up to 3:00 am debugging their little servers…
Secondly, who cares if the library is procedural, I invite you to take a
look at ruby’s c IO libraries.
Slide 53) Subjective to the point of insanity…
slide 54) I usually know when a book ends even if it’s doesn’t say “the
end”.
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…
let us know how it was received…
ilan
