From: Robert Klemme <shortcutter@...>
Date: 2009-05-13T15:00:03+09:00
Subject: Re: Any current preprocessor/Ruby language add-ons?

On 12.05.2009 18:47, C. Dagnon wrote:
> However the 2 articles you list last are definitely interesting.  The 
> second one especially gives me several ideas to mull over.  Thank you!

You're welcome!

> Why not move to Eiffel?  Well if Eiffel is the only or best language 
> using contracts I should be trying it if only to learn it's limitations. 

I always keep recommending Bertrand Meyer's excellent book on OO in 
general and Eiffel in particular:

http://archive.eiffel.com/doc/oosc/page.html

> However I'd rather do incremental upgrades of all the existing 
> Ruby/Rails products I've made than switch to a completely new language 
> and web framework all at once.

Did you consider whether these upgrades will retain the functionality of 
those frameworks?  Chances are that they are highly dependent on Ruby's 
dynamics and won't play well together with the kinds of changes you want 
to do to the language.

> I've also never seen a job posting for Eiffel, but I 
> haven't explored much.

Economic success and technical quality are two orthogonal concepts with 
only loose coupling. :-)

> I also love the dynamic abilities of Ruby, and I want to keep them. 

But you do see a certain level of contradiction there, do you?

> 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.

I would assume that what can be checked at compile time is already 
checked then.  Eiffel has a quite elaborate type system with more 
options of inheritance than any other language I am aware of.  So that 
buys you quite a bit of added safety.

>  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?

... which brings us to the halting problem:

http://en.wikipedia.org/wiki/Halting_problem

> Which is partly why I was asking about other groups, meta-computer 
> language groups in particular because I'm pretty fed up with limitations 
> I've experienced in each of the existing languages I've tried.  But I'm 
> not experienced with the vernacular enough to know what the N-axis(es?) 
> are of possible language/environment features.  Wikipedia doesn't quite 
> help either - their comparison has several useful points, yet doesn't 
> quite compare their gestalts as I would like to.  Perhaps because they 
> want it to fit in thin tables? 
> http://en.wikipedia.org/wiki/Comparison_of_programming_languages

Maybe you get yourself a textbook about computer languages and one on 
computational theory. :-)

http://en.wikipedia.org/wiki/Computational_theory

> 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.

I am not so sure whether this works our.  Sure, in practice we often 
seen things that start out as mini applications and grow into large and 
complex things over time.  I am just not sure whether it is realistic to 
expect a single language to cover the whole range.  After all, the rule 
should be to pick the right tool for the job.  Put it differently: 
assuming all your extensions could be incorporated into Ruby then the 
Ruby you would use for small scale scripting and the Ruby you use for 
large applications would not have much in common, so you *are* 
effectively using two different languages.  The step towards something 
completely different does not seem to big.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/