Re: New presentation on Ruby

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 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.

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





-- 
Posted via http://www.ruby-forum.com/.