CSC302 2011S Programming Languages

Reading: Ruby (1)

Reading: Tate, Sections 2.1 (Quick History) and 2.2 (Finding a Nanny).

Please submit a question by 9 p.m. on Tuesday, 25 January 2011.

Does Ruby support interpolation of variables inside strings via sigils or something like them a la Perl and UNIX shells?

Yes. We'll cover that in the next reading.

Ruby returns everything, therefore in some cases we don't even need to put "return" at the end of a function. Is it a bad programming practice if we don't use return?

I think it's fine not to use return, except for the cases in which you want to exit from a function early.

What is the implementation of duck typing like? Before actually calling the method is there a step to check if the call will succeed, or does it just break if it doesn't work?

I'm not sure what the difference is. But yes, essentially, Ruby looks for a coercion function and calls it if it exists. If it doesn't exist, the program goes boom (or invokes an exception handler).

Can you define your own type coercion relationships in Ruby? How difficult is it to do so?

In many cases, it's easy. When dealing with primitive types (e.g., integers), You just add the appropriate coercion method to the object or class.

In the interview with Matz he mentions that if he were to do it all over he would remove threads and add either actors or some other more advanced concurrency features. What would those features be?

Matz also says that blocks are one of his favorite things about Ruby. To me they seem like a crude substitute for proper higher order programming. They aren't objects and seem unnecessarily hackish as a result. Why not just make functions objects?

How is puts implemented? Is it a standard function used with some syntactic sugar or is it a core control structure?

If Ruby was implemented in machine code instead of C would there be significant performance improvements?

Just about everything in Ruby is an object, down to each individual number. -- What components in Ruby aren't objects?

The author contrasts the Ruby approach of making pretty much every single component an object with Java's approach where primitive types and fixed values are not objects. This comparison brought up the following question: What is the rationale for (and the pros and/or cons of) designing a language such that deviations from a specific paradigm are minimized?

Since Ruby is a dynamically typed language, does this increase the amount of type checking we should do to maintain execution safety? (since variables arnt checked until run-time we are more likely not to notice syntax/type errors)

Is it more acceptable stylistically to use block coding or one line coding for testing conditionals? Tate only says that he prefers the one line format.

Ruby is described as a language which should not be relied upon for its efficiency. However, it also supports parallelism, and its creator regrets not having better features for this, such as actors rather than threads. This seems contradictory.

On pg27, Matz uses the acronym "DSL". What does he mean by it?

At the start of the section, Tate claims that Ruby exchanges efficiency in execution speed for readability. Is this inefficiency mainly due to the fact that Ruby always returns something? (The command "properties.each {|property| puts "Ruby is #{property}."}" also returns the properties array, which seems like it would slow down execution.) Are there other, or more important, reasons to account for this slowness?

Matz said he would change threads into something else (like actors) if he could go back in time. What advantage do actors have over threads and if it's advantageous, why wouldn't he just add them now anyway (without necessarily removing threads for backwards-compatibility issues)?

Why did Matsumoto decide to make 0 evaluate as true rather than false? While I understand the overall philosophy of challenging your thought process through differences in programming languages, this particular difference seems to do more to trip up C/C++ programmers than it does to meaningfully introduce a new approach to problem solving.

In a footnote on page 25, Tate explains that syntactic sugar is a feature that makes code easier to read and write, though there are alternative ways to express the same code. Could you give an example from Ruby or other languages of such a feature? Are one-line forms of simple conditionals in Ruby syntactic sugar?

There are two statements in the book that puzzle me when I consider them both at the same time. On page 28, Tate says that Ruby is almost always interpreted. On page 33, Tate says that Ruby performs type checking at run time and not at compile time. Does it even make sense to talk about compile time considering that Ruby is interpreted? Could you explain how interpretation of Ruby works?"

Unlike languages I know, Ruby allows both "if" and "unless" in conditional statements and both "while" and "until" in loops. This is nice and their redundancy doesn't seem to pose an obvious problem, so what are the drawbacks of having these options in a language and why have previous languages avoided it?

For an interpreted language like Ruby, what does "Ruby makes these checks at run time, not compile time" (in subsection "Duck Typing") mean? Is there any real distinction between compile and run time here?

Why did Ruby's creator choose for it to be interpreted?

Hm, this explanation of duck typing may be eluding my understanding. For the given example on page 34, Tate says "The same code converts each to an integer via to_i". Couldn't one do the same in Java by defining to_i methods in the String and Float classes? Would the problem with that be that you can't make an array of differently typed objects? So does duck typing reduce to the ability to do that?

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:13 2011.
The source to the document was last modified on Mon Feb 7 08:48:35 2011.
This document may be found at

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

Samuel A. Rebelsky,