CSC302 2011S Programming Languages

Reading: Ruby (1)

Reading: Tate, Sections 2.4 (Serious Change) and 2.5 (Wrapping Up Ruby).

Please submit a question by 9 p.m. on Sunday, 30 January 2011.


On page 57, Tate mentions that ruby has limited scalability, what are the sources of this problem? "As Tate pointed out, Ruby has problem with concurrency, and that seems to be the reason why we still haven't seen a lot of asynchronous ruby web apps (chat room, real-time collaborative editing, video chat, etc) in the market. So is there a language that can solve the concurrency problem better? And is it as clean and readable as Ruby? Does it have a large community?

" "Tate mentions that concurrency is a big problem in OOP. He continues to say that the rails team is addressing this concern. How exactly would you go about resolving this problem?

" I'm not convinced that the cvs example is better suited to metaprogramming with modules than inheritance. I'm not entirely sure on how the code on pg.38 does anything that useful. It says that it's writing a program to write a program, which I guess is technically true, but the program written doesn't seem to provide any advantages over just writing it yourself. So could you elaborate on this a bit? Would it be smart to write a method_missing if this would produce some unexpected behavior in debugging if you were to invoke it accidentally? "1. Do Ruby's facilities for metaprogramming provide any functionality for which Python doesn't really have an equivalent? I expect to use Ruby a lot in CSC397, so I'm wondering if I'll end up using it for personal tasks when I would have used Python in the past...

2. The author says that you can do awesome things by overriding method_missing, but the Roman numeral example he uses is ridiculously unsafe, so he concludes with ""Consider the cost, though. ... Still, it's another scalpel for the tool bag. Use it wisely."" He doesn't actually give us an example where overriding method_missing is both more elegant than not and typesafe. Is overriding method_missing inherently unsafe or did he just not give a good example? If the latter, can you give a typesafe example?" On page 51 when Tate explains how to use method_missing to deal with roman numerals. Wouldn't using method_missing in this way defeat its purpose? If method missing is being used in this way it can't be used to debug missing methods. The ActsAsCsv module seems needlessly complex to me. Some of the modules appear to merely call other modules, without doing anything on their own. Can we go over how the various modules interact in class, and why this design is useful? I didn't understand macros in Ruby. Could you please talk about it? Tate says, "the scalability of Ruby is limited in some ways" -- how so? "I am confused by the idea of overriding the method_missing method. Why is it so useful to do? Why would we ever want to override the method instead of writing our own method with a different name?

I do not quite follow what the author is thinking in the subsection titled ""Modules""? How is the programming technique introduced in this subsection beneficial?" Detractors of Rails often cite its inability to scale well, and Tate touches on this as well. I can't really picture how growth could cause problems that were insurmountable within a language. What are the specific issues that tend be the cause of this? "I'm a bit confused by why Tate thinks Ruby metaprogramming is so fancy. To me it looks almost crude. It seems like a straightforward case of ""mixing in"" an interface along with some implementation. In the example on page 54 I don't quite see why the first third or so of the code is needed. Why not just define a ""trait"" with this functionality and use syntax like ""with ActsAsCsv"" in the class definition? Is there a higher level of metaprogramming where the Ruby syntax becomes elegant?

In the wrapup Tate comments that Ruby's use of duck typing makes it difficult to develop an IDE debugger for the language. Why exactly is this? My intuition is a bit conflicted on the matter. It appears that if you fed an entire Ruby program into a debugger the type relations would be easily inferred, but it also seems that it would be easy to run into a step that isn't guaranteed to halt. Could you elaborate on the issue?

Why doesn't Ruby provide more support for syntactic sugar using ""method_missing""? One flaw pointed out is that the usual method isn't available when there is an actual missing method. Would it not be straightforward to allow an overridden method_missing to call the default implementation?

How dangerous are open classes in practice? It seems very easy to cause a lot of damage by triggering incompatibilities in large projects. For example what would happen if Numeric was, in different places, extended to support two unit systems with overlapping definitions. How would code that had both in scope interact? "

What would be the point of using a macro when you can use the module approach described on page 54. e.g. I guess I'm confused about the pros and cons of macros. The idea put forward of overwriting method_missing seems rather risky. Are there any situations where the slight increase in readability is worth the cost to debugging? If not, why bother mentioning the possibility in the book?

Can we go over the use of "<" as shown on pg 52? I know that double less than signs is a method (from Fixnum for example) but what's going on here?

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Mon Feb 7 08:49:14 2011.
The source to the document was last modified on Mon Feb 7 08:48:55 2011.
This document may be found at http://www.cs.grinnell.edu/~rebelsky/Courses/CSC302/2011S/Readings/ruby-3.html.

You may wish to validate this document's HTML ; Valid CSS! ; Creative Commons License

Samuel A. Rebelsky, rebelsky@grinnell.edu