Robert Klemme wrote: > On 12.05.2009 18:47, C. Dagnon wrote: >> 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 would say it depends on where you are. While certainly far from being anything even close to "mainstream", Eiffel is much more popular in Western Europe than say in America or Asia. Bertrand Meyer is in charge of the entire programming education at ETH Zich both for CS students and others, and, naturally, he uses Eiffel. He also runs his University department in a very industry-focused manner, teaching classes to programmers, collaborating with industry partners on projects and so on. >> 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. Actually, AFAIK, Eiffel does *not* do any static analysis based on contracts. The only contract systems I know of that do that, are Microsoft Research's Spec# and its productized successor Code Contracts.NET. I think you are actually mixing up three different things there: Eiffel's elaborate type system, the flexible object system and contracts. Eiffel *does* have a very powerful type system that can catch a lot of errors that other, more "C++-ish" type systems can't. Eiffel also has a very powerful and flexible notion of inheritance, including actual working multiple inheritance without all the stupidity from C++. And thirdly, contracts. Those are tightly integrated with the object system and inheritance, but not, AFAIK, with the type system. (Interestingly, there is a paper that proves that every contract can also be expressed as a type, but that paper says nothing about the practicality of such types. In particular, the types that correspond to even pretty simple contracts are *ginormous* and require an insanely complex type system that makes Haskell and Scala look like BASIC in comparison. OTOH, some type system can easily express restrictions for which you would need very complicated or even infinitely large contracts.) >> 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 Yes, this is indeed a problem. More specifically, Rice's Theorem which is based on the Halting Problem, which basically says that proving any interesting static propertiy about a program is in general equivalent to solving the Halting Problem. This is one of the reasons why Spec#/Code Contracts can only check some contracts at compile time. That being said ... Spec# *does* do exactly that! >> 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 When it comes to programming languages and programming paradigms you certainly can't go wrong with Concepts, Techniques, and Models of Computer Programming Peter van Roy and Seif Haridi ISBN: 978-0262220699 <http://MITPress.MIT.Edu/0262220695/> <http://Info.UCL.Ac.Be/~pvr/book> <http://CodePoetics.Com/wiki/> or Programming Languages: Application and Interpretation Shriram Krishnamurthi <http://WWW.PLAI.Org/> jwm