I don’t have time for a full reply, but I definitely wanted to say some
Robert K. 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:
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
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
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
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
Thanks for playing devil’s advocate,