Deutsches Rubyists
Friday, 21 July 2006
Posted by austin in: Ruby, comments closed
In the last ten days, I have met two charming German Rubyists: Hagen (whose surname I never learned) and Urban Hafner. I missed meeting Armin Roehrl because my travel schedule caused me to miss the München.rb meeting on the 15th and we were never able to connect otherwise (sorry, Armin; I really did want to meet you).
Hagen has been using Ruby in his degree program and his practicum study for the transformation of business model descriptions to web sites, etc. He lives in Potsdam, just outside of Berlin, and we met him on the evening of Thursday the 13th after we picked up our rental car (an Opel Zafira). He showed us around the Sans Souci palace park built by the Austro-Hungarian emperor Frederick II. Absolutely beautiful and a worthy trip. He was very knowledgeable of his town and obviously likes it a lot. We made it back to the car just before the rain came down on us (after what had been a very hot—35 °C—and humid day in the Berlin area) and stepped into a nice Italian restaurant just as the deluge began. After a wonderful dinner, we drove Hagen back to his apartment and went on our way to Dresden and ultimately family in Lohr am Main.
We went to München on Monday, the 17th, and met up with Urban on the evening of the 18th. Urban saved my iPod from being useless on this trip by bringing his charger. (It had fully discharged and would only charge through my laptop; the USB-based charger that I had brought did not provide enough power for the iPod.) We met Urban near the fish fountain on Marienplatz where he was wearing his Munich.rb t-shirt and went to a nice Bayernisch restaurant east of Marienplatz. During dinner we learned that Urban used Ruby to process his raw data for his bio-informatics degree (equivalent to a master’s), although he was not asked that in his thesis defence.
My traveling companions are just computer users (not programmers at all!) and have pleasantly been pleasantly surprised by how nice, friendly, and well-rounded the Rubyists they have met have been.
London Ruby Users Group
Monday, 10 July 2006
Posted by austin in: Ruby, comments closed
I spoke on a number of things tonight at the London Ruby Users Group, ranging from the Google Summer of Code, to the Toronto Ruby Users Group hackathon, to PDF::Writer. It was a much larger crowd than I expected (about 25 people!).
Beware First Impressions
Saturday, 1 July 2006
Posted by austin in: Ruby, comments closed
Adam Connor doesn’t like a few things about Ruby. He’s certainly correct that there are warts in the Ruby language, but much of what he’s described aren’t warts.
There’s more than one way to do it. If you like baroque languages like Perl, maybe this is a feature. Ruby has 3 ways of constructing regexps, innumerable ways of producing strings, if and unless and… well. You get the idea. Reading Ruby is an exciting adventure in learning new ways to do the same old thing! Don’t like the old method name? Alias it! After all, languages should enable free expression in whatever manner best suits the developer’s personal style. “`Twas brillig, and the slithy toves…” and all that. Moderation is a virtue.
This is a conflation of several issues. Let’s tackle them independently.
- Multiple constructors for regular expressions: I am presuming here that Adam is referring to
/re/,%r{re}, andRegexp.new("re"). Each one of these makes sense, but you only see two of them commonly present in most Ruby code. Most often, you’ll see the/re/format, like/[ab].[d-f]/. This works well until you need to match on a slash character, like/\d{4}\/\d{2}\/\d{2}/. The extended format is much more readable in this case:%r{\d{4}/\d{2}/\d{2}}. Note that Ruby doesn’t have problems with the braces because they match here. Ruby is smart that way. The third form exists because regular expressions — like everything else — are objects. One could construct a regular expression from a string you get externally in this case, likestr = "[ab].[d-f]"; Regexp.new(str). - Multiple constructors for strings: Like regular expressions, there are good reasons for this, mostly related to quote escaping. With Ruby’s string interpolation (
"foo#{bar}") it becomes useful to have a form of the string that does not interpolate:'foo#{bar}'. (It is a minor quibble that there is no clean way to later take that string and interpolate it without calling Kernel#eval.) This means that it is useful to have string forms that make it easy to have quotes:%Q{"foo#{bar}"}and%q{'foo#{bar}'}. Finally, there is the HEREDOC format, which allows multiline strings without having to have line continuations or C++’s autojoin functionality (which wouldn’t work in Ruby because each line is an expression to be evaluated). - Multiple method names for the same method: The biggest example of this is Enumerable#map and Enumerable#collect. These two methods do the same thing, but they are named such because Lisp-oriented developers understand #map implicitly; Smalltalk-oriented developers understand #collect. When I started with Ruby, I started with #collect; now I use #map. Other examples include Array#indexes and Array#indices. Grammatically speaking, #indices is correct, but #indexes is common, too. (The same applies to if/unless, although I only use unless as a modifier with a single test, most of the time.)
Perl-style two-character variables. Because dollar-sign-squiggle is such a mnemonic and meaningful name, and distinguishing $` from $’ is just a snap.
These are not used often; it is more common to see $LOAD_PATH instead of $: these days.
Other esoterica. The flip-flop operator [...]
This has been deprecated and I’ve never used it in any of my code.
Whitespace is significant. Didn’t this go out with JCL and punch cards? I guess Python has made it fashionable again. Anyhow, I can’t tell you how thrilled I am that
1 + 2 +<br /> 3
evaluates one way and
1 + 2<br /> + 3
evaluates another way.
The problem here is not Ruby. Ruby evaluates each line as an expression. This doesn’t mean that whitespace is significant in Ruby (it isn’t), but that the two examples given are two different expressions. What is a bug, and Matz has said will be fixed is a subtly different problem, is:
(1 + 2 + 3)
The parentheses should be sufficient indicator of an expression.
Constants aren’t. You can assign to a constant multiple times. At least it will generate a warning.
Variable/Method Ambiguity. That’s what the pickaxe book calls it, anyway… Ruby guesses whether a name is a variable or a function based on whether it has seen an assignment to that symbol before the point of call. I guess I’m naive; I thought that was so amazingly lame that I was surprised it wasn’t classified as a bug.
Both of these are fully understandable and well-explained elsewhere. The latter is a consequence of what is often called “poetry mode” where parentheses aren’t required for method calls. Ruby does resolve this very well.
The method to_i doesn’t return errors.
Use Kernel#Integer if you need this. Most of the time, I don’t.
Handling namespaces and mixins with modules. Since these concepts have no particular overlap, this just feels very kludgey to me. Apparently the Ruby community is OK with it, though.
Actually, it’s not just modules. It’s classes. I can do either:
class A; end class A::B; end module C; end class C::D; end
This, to me, is a lot more sane than yet another syntactical setup with no structure (package) or the way that C++ uses namespace.
Ultimately, I think that Ruby is what Lisp would be if it were a procedurally-oriented language. Nothing else certainly comes close.
