From: Robert Klemme <shortcutter@...>
Date: 2009-05-15T05:50:04+09:00
Subject: Re: Any current preprocessor/Ruby language add-ons?

On 13.05.2009 22:51, C. Dagnon wrote:
> I don't have time for a full reply, but I definitely wanted to say some 
> more 8)

Oha, what might a full reply have looked like? :-)

> Robert Klemme wrote:
>> Economic success and technical quality are two orthogonal concepts with
>> only loose coupling. :-)
> 
> Unfortunately, but only for now!

Note, that I did not state that quality products cannot be successful! 
But I don't see how the loose coupling is going to change anytime soon.

>>> 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?
> 
> Nope, I don't 8)  Partially I would say I am not looking for a 
> compile-time (singly-) statically-typed language.  I want it to be 
> adaptable and further, *useful* by others without requiring source-code 
> changes in existing libraries.

But as long as those changes aren't done, you won't benefit from the 
additional safety.  You would then likely have to live with a hybrid 
situation and I am not sure whether that is less safe because people's 
expectations might go into the wrong direction.

>> ... which brings us to the halting problem:
>>
>> http://en.wikipedia.org/wiki/Halting_problem
> 
> I'm not convinced yet that it does, but I'm also not yet concerned that 
> it does bring up the halting problem.

I am not sure I understand that sentence properly.  Your wording seemed 
pretty ambitious:

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

> I would love to see it work out, but it may be too hopeful for our 
> current world.  Hmm, the more I try describing this it does sound more 
> and more like a different use case for utilizing Ruby, and I am 
> certainly talking about adding syntax (even if within comments) so 
> depending on how much is necessary it could be/become an adjunct 
> language.

Maybe you start by writing up what your requirements are, i.e. what 
kinds of checks you want to see.  That might serve as a good basis for 
discussion and will help you clarify your ideas.

> But can you tell me that a Ruby script and a large app are going to be 
> created in the same way?  Don't they already have differing use cases?

Exactly!

> And it is fine to pick the right tool for the job, but you can't be 
> serious that I should do my draft in Ruby and Rails, intermediate 
> requirements in Java, then do all production work in ...? 

Why not?  If it works better?

> Thanks for playing devil's advocate,

Playing?  Who's playing?

:-)

Cheers

	robert

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