Talk Like A Duck

Mum's the word (for IRB)

Posted by Rick DeNatale Mon, 12 Mar 2007 14:53:00 GMT

Ara T. Howard posted a nice little IRB hack to ruby-talk about 10 days ago.

I finally got around to incorporating it into my .irbrc file. Here’s my code:

module IRB
  def self.result_format
     conf[:PROMPT][conf[:PROMPT_MODE]][:RETURN]
  end

  def self.result_format=(str)
     result_format.replace(str)
  end

  def self.show_results
     self.result_format = "=> %s\n"
  end

  def self.hide_results
     self.result_format = ''
  end
end

Put this into your .irbc file and you can do this:

rick@frodo:~$ irb
irb(main):001:0> 1+2
=> 3
irb(main):002:0> IRB.result_format
=> "=> %s\n"
irb(main):003:0> IRB.hide_results
irb(main):004:0> 1+2
irb(main):005:0> IRB.show_results
=> "=> %s\n"
irb(main):006:0> 1+2
=> 3

Maybe there are some better names, but it seems to work.

Posted in ruby | Tags hacks, irb | no comments

Whose Breakfast is it, Anyway?

Posted by Rick DeNatale Thu, 28 Dec 2006 13:12:00 GMT

I just ran across this article, via O’Reilly Ruby.

Ohloh is a web site which analyses open source projects by monitoring commits. The article is making a case that PHP is somehow better than Ruby (and Rails), is “eating Rails for breakfast,” because:

1. About 18% of all new code added to open source projects in 2006, or at least those monitoried by Ohloh) is written in PHP, compared to something like 2% in Ruby. The trend is upward for both PHP and Ruby although PHP’s slope is steeper
2. About 10% of open source developers contributed code in PHP, vs. Ruby contributors who accounted for about 2.5%. The trend here is downward for PHP. It peaked at around 14% in 2004. Python and Perl are slightly below PHP and are in decline as well. Ruby rose gradually in 2004 and has been level in this metric since then.
3. 5% of open-source projects started in 2006 are being written in PHP. This is about the same as Python. Perl struggles here at about 1%. All three languages saw a decline in project starts since 2002, although PHP and Python have increased gradually over the past two years.

This last set of statistics is one hint that Ohtoh’s analysis might be slightly flawed. In contrast to PHP (and the others), 16% of new open source projects in 2006 are being written in Ruby, and the number has been growing since the start of their charts in 2001.

Which begs the question of whether these numbers really show that fewer developers are getting more done in Ruby with fewer lines of code than in PHP. If this is indeed the case, I’d say that it’s really PHP, not Ruby and Rails which is in the cereal bowl.

Lines of code has always been a lousy measure of code, and often it correlates negatively with quality. Ruby programmers pride themselves on keeping their code DRY, avoiding unnecessary duplication of code. I’ve always gotten great satisfaction working on refactoring phases of projects which resulted in a net reduction in the total number of lines of code.

In any event, such arguments are far from convincing. Despite the question of how the data has been gathered, processed, and interpreted, there’s the larger question of the validity of arguments based on populariey.

Posted in ruby | Tags languagewars | no comments | no trackbacks

Stage Fright, or more on Performance Anxiety

Posted by Rick DeNatale Fri, 22 Dec 2006 17:19:00 GMT

Hmmmmm

I’ve been thinking a bit about the ramifications of the C++ vs. Python vs. Ruby benchmarking fud I wrote about in an earlier post

I’ve been looking at this from the point of view of how Ruby implements Arrays, digging deeply in to array.c, but I just stepped back and I noticed something which might or might not be important.

Besides using an Array rather than a linked list, the Baus Ruby benchmark doesn’t even do the same thing as the C++ one. In C++ the list is being used as a stack, items are added to the head of the list and removed from the head.

In the case of the Ruby benchmark, elements are inserted at the front of the Array using insert(0, obj), but removed using pop, which actually removes the last element. So instead of a stack we have a queue.

The Python code has a variation on the same problem, it uses append which adds to the end of the list, but del(0) which removes the first element.

Now I know that in benchmarking only performance matters, so I guess the old adage Make it work right before you make it work fast doesn’t necessarily apply.

Posted in ruby | Tags benchmarking, performance | 2 comments | no trackbacks

Enumeration Improvement in Ruby 1.9

Posted by Rick DeNatale Sun, 15 Oct 2006 23:02:00 GMT

If no block is given to the methods in Enumerable (and those in Array, Dir, Hash, IO, Range, String or Struct that serve the same purposes), an Enumerator will be generated.

One of the things which annoyed me about Enumerable is that all of the nice methods like, map, inject, etc. are defined in terms of the each method. But what if I want to do something like sum up the values in a hash?

Posted in ruby | Tags ruby1.9 | 5 comments | no trackbacks

Boolean Implementations, Ruby, Smalltalk and self

Posted by Rick DeNatale Tue, 10 Oct 2006 16:43:00 GMT

The topic of defining a new ruby class which could have instances that, like false and nil were seen as a boolean which was not true, just came up on ruby-talk.

This has come up before, and it turns out that in Ruby being untrue is reserved to these two specific instances.

#define Qnil   ((VALUE)4)
#define RTEST(v) (((VALUE)(v) & ~Qnil) != 0)

Which means that any object whose reference VALUE has any bit set other than the 3rd LSB is true.

In ruby, the control flow statements like ‘if’ aren’t messages, but are ‘compiled’ into a direct test and conditional branch.

    booleanValue ifTrue:[Transcript show:'true'] ifFalse: [Transcript show:'false']

Posted in ruby, smalltalk | Tags implementation, performance, self | 2 comments | no trackbacks

A Subtle Change to Mixin Semantics in Ruby 1.9

Posted by Rick DeNatale Mon, 09 Oct 2006 20:07:00 GMT

I’ve been working on a little tool to peek behind the curtain and see a bit of what’s going on behind the scenes in the standard Ruby implementation (i.e ‘ruby’ as opposed to ‘Ruby’)

While doing this I was looking at the code which ruby runs when you include a module in a class or another module. I noticed that ruby 1.8 was going to some pains not to move the proxy for an included module in the inheritance chain.

To verify what my eyes seemed to be telling me, I wrote a silly little test program which created a module with one method, and several classes.

This test verified my reading of the 1.8 code. I then tried the same test using the latest ruby 1.9 and found that module mixin semantics have changed.

Read on

Posted in ruby | Tags changesinruby1.9, inheritance, mixins, semantics | 1 comment | no trackbacks

Danger Will Robinson

Posted by Rick DeNatale Thu, 05 Oct 2006 15:23:00 GMT

Ruby has a nifty method in kernel called open. It’s quite powerful in the way it interprets its first argument, a string telling it what to open. It can open a file, or it can open a pipe to a sub-process it creates to run a command in that string. It takes quite a bit of open function has a similar interpretation of it’s first argument. Again it takes quite a bit of documentation to describe.

Which is a cause for concern. Most things that powerful can be misused.

I use an application called Awstats to get statistics on my websites. Awstats is a very popular application which is written in perl.

But I long ago disallowed access to Awstats from the outsite world after I found that my system had been compromised by a bad guy exploiting perl’s open function.

Posted in ruby | Tags bestpractice, perl, security | no comments | no trackbacks

Performance Anxiety

Posted by Rick DeNatale Tue, 26 Sep 2006 19:17:00 GMT

I've been meaning to write about Ruby performance for a while, and a recent blog post by an old friend and colleague, got me off my proverbial.

The old friend is John Duimovich, who wrote about the relative performance of C++ and Smalltalk and what that could mean for ruby.

John's message is important for those who bemoan the performance of Ruby, and I plan to expand on that message in this and later posts to this blog, but first a few words about Mr. Duimovich.

Posted in ruby, smalltalk | Tags implementation, performance, ruby, self, smalltalk | 10 comments | no trackbacks

Schrödinger's Duck

Posted by Rick DeNatale Thu, 21 Sep 2006 15:27:00 GMT

Once again there’s been a recent furore about the meaning of Ducktyping on the ruby-lang mailing list.

A nice young man from Sweden, by the name of Ola Bini, announced “ductator” a ruby-gem which allows type validation of ruby variables. Now I think that Ola is young based on the photo on his blog site, and I know that he’s nice because only nice people inhabit ruby-lang.

The real question is just what kind of a type system ductator represents. I’ve taken a brief look at it and it seems to allow one to describe, via a hash, a list of rules which are applied to a variable’s value at run-time. These rules are things like a list of methods the value must have, a class which the value must be an instance of, or an instance of a subclass of etc.

The Cat is Dead, Long Live the Cat

Posted in ruby | Tags ducks, types | 4 comments | no trackbacks

On Variables, Values, and Objects

Posted by Rick DeNatale Wed, 13 Sep 2006 19:47:00 GMT

I’ve recently observed some posts to ruby-talk which evidence some confusion on the part of the posters about the relationship between variables and objects in Ruby. One currently active thread concerns several participants who are upset that instances of the Matrix class in the Ruby standard library can’t be changed once created.

In Ruby, like in other uniformly object-oriented languages, the relationship between variables and their values is subtly different than in other languages, and this is a crucial paradigm shift, which must be crossed in order to understand Ruby.

In many languages a variable names an area in memory which holds a “bag-of-bits” representing the value of the variable. The size of that area depends on the type of the variable. A variable holding an integer might be 4-bytes long, while one holding a particular structure might be 325 (or whatever) bytes.

In a uniformly object-oriented language, all variables reference objects, and any variable can reference any object, or different objects over time. My good friend at IBM, the late David N. Smith, used to say that in such a language, “all variables are the same size,” when he wrote about or taught Smalltalk.

This distinction can trip up the unwary. Let’s try to clear some of the stumbling blocks out of the way.

Posted in ruby, smalltalk | Tags implementation, nubies, objectidentity, objects, semantics, variables | no comments | no trackbacks