From: "Jörg W Mittag" <JoergWMittag+Usenet@...>
Date: 2009-05-16T08:20:02+09:00
Subject: Re: Any current preprocessor/Ruby language add-ons?

C. Dagnon wrote:
> I also love the dynamic abilities of Ruby, and I want to keep them. 
> However I want to be sure the code does what I want it to without 
> needing me to exercise all the code separately.  From the last article 
> you gave, it sounds like Eiffel doesn't provide that feature - that the 
> contracts are only enforced when the code is run, which would not meet 
> my needs.  It seems like if the contracts are defined the 
> compiler/preprocessor should be able to guarantee all (at least 
> small-scale) code interactions without writing any tests.  Effectively 
> swat all Unit and Functional tests without writing external, dependent 
> code needing triggered updates.  Except if that could be done, someone 
> would have already done it, right?

AFAIK, Eiffel only enforces contracts at runtime. But Micosoft
Research has a very powerful static analysis tool (Boogie), based on
an *insanely* powerful theorem prover (Z3, wins pretty much every
benchmark), both built as part of the Spec# project, which was a
superset of C# 2.0 with contracts and null-tracking. Spec# is now
defunct, but the team is now building the Code Contracts.NET library,
which is part of .NET 4.0. The bad part about Code Contracts being a
library: no nice syntax for contracts. The good part: because it is
"just a library", it works with *any* .NET language. And it just so
happens, that Ruby *is* a .NET language!

Code Contracts/Spec#/Boogie/Z3 can do some pretty amazing static
analysis. You can still have your contracts enforced at runtime, but
if Z3 can prove statically that the contract can never be violated,
the check can be omitted and when it can prove that the contract can
never be fulfilled, then your project won't even compile to begin
with. Also, there is a Visual Studio Plugin that is tightly integrated
with Code Contracts and can analyze your program at design time,
giving you things like squiggly lines for unfulfilled contracts or
displaying the contracts of a method in the code completion popup
window.

> Lastly, I would love to see the assurance flexibility within the Ruby 
> platform.  Sometimes you need a script (easy with any Ruby), sometimes 
> you need a 20+ person team working on a complex application (I don't see 
> this as possible without major, strict development practices).  The 
> ability to tighten up an application from free-form script to 
> (Eiffel-ness?) seems like a great growth vector for my usage patterns. 
> We get both the immediate usefulness and the long-term maintainability.

You will be very pleased to hear that this kind of scalability is one
of the major design goals for Ruby 2.0. Scalability in problem size,
project size, team size, program size, from a single developer coding
up a 3 line script in a couple of seconds to a 100 person team
developing a 100 million line financial trading system over the course
of years.

Please note that Ruby 2.0 is still very far into the future, and so no
actual features have been set in stone to actually achieve these
goals. Some that have been talked about are selector namespaces,
method combinators/aspects, traits, static typing and contracts.

(Other types of scalability that are also in the sights are community
size and machine size (in both directions(!), i.e. modularizing the
language for embedded systems, but also adding better concurrency
support for massively parallel many-core systems).)

jwm