From: Ilan Berci Date: 2007-04-03T06:20:43+09:00 Subject: 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/.