> 
> Looking closely in OOSE2. I don't see any mention of the relation of
> static typing to DBC. The thing I see is a statement that static
> typing is needed for stable, robust systems. There seems to be an
> implication that static typing has to come as a precondition to DBC.

DBC is not bound to static typing, and I think non static typed
languages can gain from them as Eiffel gains from them. It's just
interesting to see that Eiffel is nearly anytime mentioned because of
DBC. Just to give honor to whom it belongs it seems that Konrad Zuse
used a simular thing in what was called Plankalk?l (sorry I can't
translate it is is German). A book I read at the moment asked what
would have happened if Konrad Zuse had been able to work with
collegues and not a alone somewhere in the deepest forrests of Germany
;-)


Anyway if it's mentioned here and because I'm such a big fan for
DBC. The following software can be found on my machine. 
- Eiffel
- GEF (general exception facility for C, which included DBC for C too)
- another C package (sorry do not have the name at hand) for DBC
- dbc.lisp (an implementation of DBC for Common Lisp)


somewhere was mentioned that there is something simular available for
Java, but I don't know where I read this.

> 
> Any the experts are in comp.lang.eiffel, so I've forwarded it there.
          ^^^^^^^ not everyone in comp.lang.eiffel is an expert but
it's more probable to found some of them there. Just to introduce
myself : I'm one of those rare Eiffel programmers which use Eiffel even
for their work. I'm using Eiffel for more than 7 years know the last 2
1/2 half year for my "all-day-programming". 

We (a group of five) are using Eiffel to implement a new language
called Q. Because the two initiatators know Eiffel quite well, we
build this language around the DBC idea, so Q will be very simular too
Eiffel. We extend Q in a way that DBC is even stronger than in
Eiffel. At the moment in Eiffel DBC can introduce errors (seldom seen
but possible), if Queries or Functions with side-effects are used in
those contracts. Another enhancement is having functions as first
class objects. Q will use pure functions and will improve the
expressiveness of DBC buy those funtions. You will be able to state
with one line or so that e.g. in one collection just positive numbers
are contained. Now I think that is enought to introduce myself. 

Just too add: I encountered Ruby a year or so ago. I do not have done
any serious programming in it (as I havn't e.g in Python too) but I
guess I would prefer Ruby. It "tasts" a bit more Eiffel-ish. ;-)


Now back to this thrad:

The discussion I had regarding
the merits of Eiffel are hardly countable any more but I think that's
the same for all non mainstream languages. I've seen those kind of
discussion e.g in comp.lang.scheme, comp.lang.lisp,
comp.lang.functional. 

And 2 years or so ago in comp.lang.python. I guess those discussions
can hardly found in that group any longer. 

I've the impression from the discussions that Eiffel programmers
prefer Ruby over Python with just a comment. "If Ruby just has those
DBC". I do not have any numbers, but I guess that Eiffel and Ruby
share so much that learning one if you know the other is quite easy. 

Now it's a pitty that e.g Eiffel did not catch up some more shares,
but I guess that is just the way live goes. 7 years or so ago C++ was
nearly as unknown as Eiffel was, maybe Eiffel had it's chance to that
time. But C++ was there for free and it has the strong C background
which suggests that migration is easier for "hard core" C
programmers. Eiffel did cost around $10000 per licence to that
time. How many people were and are willing to spend such amounts of
money for a programming language if something simular can be gotten
for free?

I think Ruby is in a much more convenient position as Eiffel were to
that time. So I guess in a few years Ruby will be very popular all
over the world.

Now the last things I would like to mention: IMHO Ruby and Python are
very simular, so I'm sure that a Python programmer hardly will have
very much problems learning Python. The other way may be a bit harder,
because Ruby seems to be more consistent as Python.

But anyway this languages are very simular and I would put them under
a mixture of OOP and imperative Programming. Ruby seems to offer
slightyl more in regard to FP but in most of the examples those
features are not used.  I would think that knowing Python or Ruby or
Eiffel is good but better is knowing Python and a  functional language
, Ruby and a  functional language, Eiffel and a functional
language. So IMO programmers should best kow one typical language for
the different paradigms and/or learn a language which combines them.

I just have seen few languages which combine the "main-stream"
paradigms and one of this languages is among us for as long as FORTRAN,
Lisp. I have to admit since I discovered Common Lisp (in a way
that says I've really used it for doing some programming) really, I'm
quite impressed. And I have spend more and more time learning
programming the "Lisp" way. I guess Ruby programmers which know and
love this language feel quite simular to this. 

Before getting banned here because of all to lengthy postings, I'll
better stop. 

with best reagards
Friedrich