Why the framework uses ruby instead of perl?[转]

During the development of the framework, the one recurring question that the
Metasploit staff was continually asked was why Ruby was selected as
the programming language. To avoid having to answer this question on
an individual
basis, the authors have opted for explaining their reasons in this document.
The Ruby programming language was selected over other choices, such as python,
perl, and C++ for quite a few reasons. The first (and primary) reason that Ruby
was selected was because it was a language that the Metasploit staff enjoyed
writing in. After spending time analyzing other languages and factoring in past
experiences, the Ruby programming language was found to offer both a simple
and powerful approach to an interpreted language. The degree of introspection
and the object-oriented aspects provided by Ruby were something that fit very
nicely with some of the requirements of the framework. The framework's need
for automated class construction for code re-use was a key factor in
the decision
making process, and it was one of the things that perl was not very well suited
to offer. On top of this, the syntax is incredibly simplistic and provides the
same level of language features that other more accepted languages have, like
perl.

The second reason Ruby was selected was because of its platform independent
support for threading. While a number of limitations have been encountered
during the development of the framework under this model, the Metasploit
staff has observed a marked performance and usability improvement over the
2.x branch. Future versions of Ruby (the 1.9 series) will back the existing
threading API with native threads for the operating system the interpreter is
compiled against which will solve a number of existing issues with the current
implementation (such as permitting the use of blocking operations). In the
meantime, the existing threading model has been found to be far superior when
compared to a conventional forking model, especially on platforms that lack a
native fork implementation like Windows.
Another reason that Ruby was selected was because of the supported existence
of a native interpreter for the Windows platform. While perl has a cygwin
version and an ActiveState version, both are plagued by usability problems.
The fact that the Ruby interpreter can be compiled and executed natively on
Windows drastically improves performance. Furthermore, the interpreter is also
very small and can be easily modified in the event that there is a bug.
The Python programming language was also a language candidate. The reason
the Metasploit staff opted for Ruby instead of python was for a few different
reasons. The primary reason is a general distaste for some of the syntactical
annoyances forced by python, such as block-indention. While many would argue
the benefits of such an approach, some members of the Metasploit staff
find it to
be an unnecessary restriction. Other issues with Python center around
limitations
in parent class method calling and backward compatibility of interpreters.
The C/C++ programming languages were also very seriously considered, but in
the end it was obvious that attempting to deploy a portable and usable framework
in a non-interpreted language was something that would not be feasible.

Furthermore, the development time-line for this language selection would most
likely be much longer.
Even though the 2.x branch of the framework has been quite successful, the
Metasploit staff encountered a number of limitations and annoyances with perl's
object-oriented programming model, or lack thereof. The fact that the perl
interpreter is part of the default install on many distributions is
not something
that the Metasploit staff felt was worth detouring the language
selection. In the
end, it all came down to selecting a language that was enjoyed by the people
who contribute the most to the framework, and that language ended up being
Ruby.