I don't have time for a full reply, but I definitely wanted to say some 
more 8)

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

Unfortunately, but only for now!

>> 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 my old gripe is that Ruby isn't Duck-Typed, it is explicitly 
No-Typed but implicitly Strong-Typed (except for method-missing).  But 
that makes no sense for a language since any method I write requires (at 
most) a certain set of functionality from the parameters.  So there are 
interface dependencies, just never declared or, in Ruby, declarable.

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

I will have to check out the book, though I'll try the homepage/FAQ to 
try to build my interest up for a whole book.

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

> Maybe you get yourself a textbook about computer languages and one on
> computational theory. :-)
> 
> http://en.wikipedia.org/wiki/Computational_theory

Yeah, I passed the senior-year language and computer theory classes... 
It may have been too long ago, but that didn't impart knowledge of all 
existing (and at that time, future) computer languages, nor give 
meaningful ways to compare them if I did have all that knowledge.  But 
as with many things our lives seem built upon, if no one else is going 
to do it maybe it is time someone competent did.  Or I could try.

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

Two different languages... not quite, but I'm unsure how else to 
differentiate it from the C to C++ transition.  Adding objects and 
abstractions created a superset for the original language, allowing more 
powerful concepts to be expressed directly rather than requiring 
everyone to create them every time they're needed.  Here I'm trying to 
verbalize how to better incorporate the tests and other implicit code 
requirements into explicit structures the (compiler/preprocessor) can 
utilize and the developers can understand.  I'm not changing the 
functionality of Ruby, nor limiting but rather trying to expand it's 
expressiveness...

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.

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?

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 ...? 
Eiffel/Ada/Prolog?  If there are transitioning scripts that make it a 
zero-time operation to upgrade, I would say: you've got the tool I've 
been looking for!  (Though having to learn completely new languages at 
each level sounds like a consultant's creation, not a developer's.) 
Otherwise I am still looking for those gradual transitions and 
flexibility as Agile, Extreme, and (all?) other programming paradigms 
promote.


> Kind regards
> 
>   robert

Thanks for playing devil's advocate,

-Chris
-- 
Posted via http://www.ruby-forum.com/.