Re: Any current preprocessor/Ruby language add-ons?

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