Slashdot Mirror

Both are coding problems.

In the Adriane they assigned a 16bit value to a 32bit variable, or was it a 32bit to 64bit, does not matter. Which lead to an overflow. Ah, it was opposite around, here is a link: https://archive.eiffel.com/doc...

The Mars lander had to convert one unit into an other, but did not. That is obviously an oversight, not language related.

My point is: errors don't show up early necessarily. OpenSSL was buggy for a decade or longer until someone realized it. And the fact that we have such errors have nothing to dow with "is the programmer competent", or "is the programmer lazy".

However they made a bad impact analysis. Bottom line programmers simply rely still much to much on build in data types and their automatic conversion. C++ and operator overloading, cornering in what can be assigned to what, would have had zero overhead and completely made it impossible to assign incompatible types to each other. Both in the Ariane case as in the Mars lander case.

One of my most rewarding jobs, in terms of fun and money, was writing code in Eiffel. Your mileage may vary...

Both Objective-C and C++ have object oriented concepts graphed on as an after-thought.

Your best bet for a classic compiled object language is either SmartEiffel or EiffelStudio.

If you are going to demand using a C-like language then your best bet is D.

I'm tired about hobbyists trying to brag with their half knowledge: https://archive.eiffel.com/doc...
That is just an introduction. It is pretty difficult to write manual memory management code that is as fast as "the optimal" gc.
Perhaps you like to read the "arguments for" and "arguments against" GC in this article: http://www.berenddeboer.net/ei... (note: the arguments "against" get debunked or put in bettter light at least ;D)
Or perhaps you like to read something from an expert: http://www.cs.kent.ac.uk/peopl...
Or simply google/search for the old Eiffel versus C benchmarks of Bertram Meyer. He compared about 30 Eiffel programs with their corresponding C programs. The "specialized" Eiffel GCs where nearly always faster than the manual crafted C code, and half of the C programs had bugs regarding memory management.

Interesting article you linked, but many mistakes. And not really related to the core question or core statements :D

Which makes me wonder, what do all these language-design people have against contravariance?

It depends on which of the two we're talking about: variance of method argument and return types, or variance of generics.

For generics, the logic goes roughly like this:

1. Generics are mostly used for collections.
2. Intuitively, people expect a collection of objects of derived class to be substitutable for a collecton of objects of base class, even if it is not sound.
3. In practice, most uses of collections per #2 are sound (i.e. only use the covariant methods, not contravariant ones).
4. So, just default to covariant to make things mostly "just work", at the expense of late error reporting when the use is actually incorrect.

For contravariance of method arguments, the only argument I've seen about the lack of it is that it is very rarely useful in practice (unlike contravariance for generics), so it's simply not worth implementing. I think that it should still be there as a matter of consistency, but it is a valid argument, especially when resources are always limited in practice. As Eric Lippert (of C# fame) once put it, "whenever someone asks me why C# doesn't have feature X, I ask him why C# should have feature X rather than Y, Z or any other that are on the ever-growing backlog".

For Eiffel specifically, which uses covariance, it is because it lets you write stuff such as:

class Foo
  feature equals(other: like Current)
end

which Meyer believes is more correct from OOD point of view than:

class Foo
  feature equals(other: Foo)
end

Because you really want "equals" to be of the same type - it's part of the contract of the type. He goes into more detail on his reasoning here (search for "Unfortunately, the combination of static typing with other requirements of the object-oriented method makes the issues more difficult than they appear at first").

The introduction has this gem:

Gosu supports a simplified version of generics. Generics are a way to abstract the behavior of a class to work with different types of objects, but to still retain type safety. There are no wildcards, and generic types are covariant, like Java arrays, which is usually what you want.

And here's how to make the type system bite the dust with this flaw:

uses java.util.*;
var xs : List<Object> = null;
var ys = new ArrayList<String>();
xs = ys; // type system allows this blatant LSP violation
xs.add(123); // we just added an integer to a list of strings - great
print(xs.get(0)); // yeah, this prints 123 - just to be sure
ys.get(0).length(); // finally, a ClassCastException which should've happened 3 lines earlier

What's funny is that Eiffel has already fallen into the very same trap, and is still trying to dig itself out of it.

Since when does the line xs=ys; not generate a warning?

The introduction has this gem:

Gosu supports a simplified version of generics. Generics are a way to abstract the behavior of a class to work with different types of objects, but to still retain type safety. There are no wildcards, and generic types are covariant, like Java arrays, which is usually what you want.

And here's how to make the type system bite the dust with this flaw:

uses java.util.*;
var xs : List<Object> = null;
var ys = new ArrayList<String>();
xs = ys; // type system allows this blatant LSP violation
xs.add(123); // we just added an integer to a list of strings - great
print(xs.get(0)); // yeah, this prints 123 - just to be sure
ys.get(0).length(); // finally, a ClassCastException which should've happened 3 lines earlier

What's funny is that Eiffel has already fallen into the very same trap, and is still trying to dig itself out of it.

I suspect it would go down better today now people are used to writing object-oriented code, which is a much better match to the message-passing idea than the C code that was more common at the time.

Indeed, it isn't that hard to take the OO paradigm and simply say that a method call is a message being passed from the caller object to the object for which the the method is being applied. Add some niceties to define which objects can be executed in parallel and method preconditions as wait conditions and you have a fairly simply way to program in object-oriented fashion and have the compiler do the work to make it multithreaded. See SCOOP for the basic ideas. Sadly, since it was proposed for Eiffel rather than C++ (and no-one in the C++ world bothers to look at what other languages are doing), I doubt it will actually get any traction and catch on.

It was indeed a reuse error. It wasn't, however, an unavoidable reuse error. Had the code included proper specification, rather than the specification being buried in a vast paper document, then reuse would have worked out fine.

You're right! It would be better to get a technology designed for multi-threaded programming. But then you go on to push Java? I'm confused.

Now, granted, Java does provide builtin support for concurrency. Although that support is an implementation of the 30-year old monitor concurrency primitive, which even one of its principal inventors (Tony Hoare) long ago abandoned in favor of better things. Not to mention that Java's implementation of monitors is known to be broken (or at least was - maybe they've fixed it now?).

Doug Lea's util.concurrent package (now part of Java 1.5) certainly helps things on the Java front, but it's hardly a panacaea. Depending on the application, you may want to take a look at JCSP instead - it provides for an almost direct translation of ideas from Tony Hoare's CSP into Java. For languages with good concurrency support out of the box, you might try Erlang, Ada, Mozart/Oz, E, or Eiffel.

.. in this post they reported on a project supposedly aiming at breaking down single threads into multiple threads so as to better utilize core utilization beyond the fourth core.

In the Eiffel programming language, they've proposed a concurrency algorithm that doesn't use "traditional" threads.

The idea is, you sprinkle the "separate" keyword onto various objects that it makes sense for. The compiler or runtime then does a dependency analysis and breaks out your program into different threads or processes. Automatically. As many different threads as is optimal for your system.

That's it. No locking, no threading, no synchronisation. Just the one damn keyword.

OK, so the above is a simplification. But it's not a huge one. You can read up on it at the Eiffel site or in your local copy of OOSC.

The "problem" is, Eiffel is already a niche language, and this is even more niche. In fact, I don't think anyone's even implemented this concurrency scheme in production code. Also, from what I've read, it's formally proven to work, but this was some time ago so someone might have poked (theoretical or practical) holes in the scheme.

* If you wish to earn a commercial benefit from your application and not release its source code, you must purchase the number of licenses you need for your development from Eiffel Software. After you purchase licenses, you are free to use and distribute your application the way you want.

* If you select the Open Source license, you must release your development under an Open Source license for the benefit of the community at large.

Source: http://www.eiffel.com/licensing/licensing.html

So, either the Eiffel folks don't understand the GPL, or there's a GPL'd runtime module that that has to be linked into your executable code.

Either way, this is more restrictive than, say, the licence for gcc.

Are we sure that this is being released under the GPL? I don't see any mention of the GPL on the press release or the product page. According to the licensing page (http://www.eiffel.com/licensing/licensing.html) it is only free if you agree to release all software written using it under a free license. If you intend to develop any commercial software, you still have to buy the commercial version. That doesn't sounds at all like the GPL to me. GCC certainly doesn't have that restriction. Moreover the GPL doesn't allow adding additional restrictions to the license either, so I don't think he has any ground to say that you can only distribute it under the GPL if you only use it to write free software.

Not that I am opposed to the guy who wrote the software choosing whatever licensing model he sees fit, but let's not be misleading about this announcement, shall we?

I happed to take a course that taught among other things how to program in Eiffel, and the contract principle is in fact very nice. When you write a contract, you define exactly what you want want to pass to a feature.. err... function and exactly what you want to get from it. I know, every good programmer has to write down specification anyway, may be even in clever mathematical form. Still, contracting scheme helps to avoid lots of stupid errors, and when you are sure you're done, just turn off contract checking in the compiler. After some time, I started thinking in terms of contracts, and it would be great feature in next revision of C++. I'm writing this because there are many features that I do not like in eiffel, and in EiffelStudio (you can download free version for most of the platforms). In general, the language is very restrictive, and allows no freedom whatsoever - you can use classes, only classes and nothing but classes and you will use them exactly the way it's creators want you to, e.g. No break statements. Also it is slow - when developing applications - eiffel code is translated to C, then C code is compiled. So on average you'd get 80 Mbyte project for every 500K of code. And finally Eiffel has arcane Pascale-like syntax, it could've been much simpler. Adding insult to injury, EiffelStudio, the IDE if you ever try to program in eifffel(I know, RTFA), is very annoying, if you made a mistake in the code and attempted to save it, studio will make a pop up window informing you about it, if you try to look inside anther class while having an error inside the current one, the studio will abruptly return you to the line where you made a mistake, even if you need to switch to a different class to fix the error. It, also, doesn't have context menu, the right mouse button is used for other purposes, e.g. view single function from other viewer inside the studio in a debug mode (don't ask me why), or moving around the code - double right click on class declaration will move you to the class definition, this actually is really nice, except, why makers of eiffel never thought about middle mouse button?! Though, debugger is nice. I think Eiffel is 1984 of programming languages, and an attempt to popularize it would not help, anyhow free version of EiffelStudio has been around a while, and it is not like anyone would suddenly begin to develop many applications using it.

From the product web site http://www.eiffel.com/products/studio/, it looks like Eiffel targets .NET. I know in the past Eiffel could emit C code which was them compiled. I'm not sure if the .NET "integration" is only in Windows or if it uses Mono on linux for that. I'm not able to determine this from a cursury glance at their web site.

In any event, I welcome this move. I'm definitely adding Eiffel to my list of languages to learn. It is a neat language that has a lot of advantages. In fact at one time HP was using it for developing printer firmware since it was less error-prone and increased their productivity dramatically over using just C. Certainly as our apps increase in complexity we need tools that allow things like design-by-contract in order to save us from the inevidable bugs.

The link for the project page goes to a wiki page with not too much information. Not to sound too much like a slashvertisement, I'm sure they would want you to also link to this page, containing more information:

http://www.eiffel.com/products/studio/

Also there should be a PDF warning on the ECMA standards link, just a thought.

To be sure that our object-oriented software will perform properly, we need a systematic approach to specifying and implementing object-oriented software elements and their relations in a software system. This article introduces such a method, known as Design by Contract. Under the Design by Contract theory, a software system is viewed as a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations -- contracts.

The benefits of Design by Contract include the following:

• A better understanding of the object-oriented method and, more generally, of software construction.
• A systematic approach to building bug-free object-oriented systems.
• An effective framework for debugging, testing and, more generally, quality assurance.
• A method for documenting software components.
• Better understanding and control of the inheritance mechanism.
• A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.

You have to realize that, for the vast majority of programmers, that the structure is necessary. Those programmers working in dynamically-typed languages fail; they produce spaghetti. Sure, you *can* maintain structure in a dynamically typed language such as Smalltalk or Ruby. But programming is a constant struggle to keep the code from descending into chaos.

What gets me though, is that people will make these sorts of comments all the time, and yet when you suggest that it's quite easy to take the same idea just a little further it all of a sudden becomes completely unpalatable and "too much work". Never mind that that's the same argument the dynamic type people use against static types. Never mind that for the extra work of contracts or specifying a little more than just type signatures you can get static checking gains and improvements in maintainability on par with what you get from using static types over dynamic types.

If you really believe that specifying static types really does help reduce bugs and improve maintainability (and it certainly can) then check out the options for doing a little better again.

Jedidiah.

Sounds like they've re-invented Eiffel. :-/

This is just a research OS written in C#.

No, it's written in Sing# which is an extension of Spec# which is an extension of C#. People really ought to pay more attention to Spec# - it's a nice extension of C# that allows for more formality if and when you require it. It's in the same class of language as SPARK which is an extension of Ada, JML which extends Java with specification semantics, BitC, Extended ML, HasCASL, and I guess to a lesser extent things like Eiffel and D.

Think of it this way: static types and type signatures for functions allow you to specify things about the software that the compiler can statically check and make sure there aren't any silly errors. The languages listed above (to varying degrees) allow for more exacting specification about the software, and hence you can (with the right tools) do far more comprehensive static checking and ensure various properties of the software. The difference is that, with most of these languages, the amount of specification is optional - you can be as exacting as you want where you need it, and not bother where you don't. It's like a dynamically typed language that lets you declare and use static types (and check them)just for those areas of code where it matters (except you start with static types and can provide more exacting specification where it matters). It's well worth checking out.

Jedidiah.

Millions of lost revenue from faulty speed cameras
Bertrand Meyer
Sat, 01 May 2004 14:44:42 +0200

Given the attention this story has been commanding in Australia, I was surprised to find no record in RISKS. The country is proud of its strictness in enforcing speed rules, sometimes fining motorists for driving one kilometer above the posted limit (however absurd that sounds). The state of Victoria has numerous speed cameras. Last year their accuracy was questioned after reports that a truck with a maximum speed of 140 km/h was caught traveling at 164 km/h, and other similar incidents. After the first such report the Assistant Commissioner said (Melbourne Age, 11 Nov 2003):

"There's no evidence to support that any of the other cameras are malfunctioning [...] in any other way,"

"It's embarrassing for everybody... Technology is technology and I think we have had indications where it doesn't say the right thing."

almost six months after the State Government suspended the issuing of fines from Victoria's fixed speed cameras, problems with the cameras are still unresolved [...] A State Government spokesman confirmed yesterday that the 47 fixed cameras were still under review. He was unable to say when the issue would be resolved.

For details:

http://theage.com.au/articles/2004/04/29/108322451 6563.html (30 Apr 2004)

http://theage.com.au/articles/2004/04/28/108310355 1024.html (29 Apr 2004)

http://www.theage.com.au/articles/2003/11/10/10683 29487082.html?from=storyrhs (11 Nov 2003)

Bertrand Meyer
ETH Zurich / Eiffel Software
http://www.se.inf.ethz.ch/ -- http://www.eiffel.com/

I read the Eiffel book, but I've never been in a position to actually write code in it. But I love the concept of programming by contract.

I just use assertions to do preconditions, postconditions, and checks. Invariants are a nice idea, but in practice seem to be a big performance hit. I just do invariant-like assertions as needed.

I assert the heck out of my code. You can see some of it here.

I don't see too many assertions in other people's code. Then again, I don't see too much that looks like planning or insight in other people's code most of the time, so why should I be surprised. I can't believe how sloppy we are as a profession. Like my coffee cup says...if builders build buildings the way programmers write programs, then the first woodpeckers that came along would destroy civilization.

I read the Eiffel book, but I've never been in a position to actually write code in it. But I love the concept of programming by contract.

I just use assertions to do preconditions, postconditions, and checks. Invariants are a nice idea, but in practice seem to be a big performance hit. I just do invariant-like assertions as needed.

I assert the heck out of my code. You can see some of it here.

I don't see too many assertions in other people's code. Then again, I don't see too much that looks like planning or insight in other people's code most of the time, so why should I be surprised. I can't believe how sloppy we are as a profession. Like my coffee cup says...if builders build buildings the way programmers write programs, then the first woodpeckers that came along would destroy civilization.

You can avoid whole classes of bugs by having proper language support, and programmer time can be reduced considerably.

Very true. So the question is why are you choosing a language that doesn't support nice features like Design by Contract (which helps avoid whole classes of bugs, makes debugging far simpler, and thus reduces programmer time considerably), or (a new one to me) CSP style programming (which makes writing multithreaded programs a breeze, meaning you can just do things multithreaded from the outset, obviously reducing programmer time considerably)?

Yes C# and OO languages have nice language features that aid in development. That's not the be all and end all however. Both ideas I just mentioned are very old (DbC is decades old, CSP about 20 years old), yet we haven't gotten around to using them, mostly because people simply don't know what they are, what they can do, and how much simpler they can make things.

Jedidiah.

Java and .NET compiles to bytecode.
Not sure if you can compile Java to machine language as well.
I would think there are compilers out there that can do that GCJ?
Possibly the same could be achieved with .NET.
Any both posesses a virtual machine - all pioneered originally by Xeror Smalltalk.

Also JVM and .NET are in fact enviroments where you can have other languages:

JVM
.NET

But I wouldn't recommend installing Eiffel for Visual Studio say.
Last 3x I've tried it messed up my environment - and still never worked.
Shame because I really like the Eiffel syntax a lot.

Turning everything into an object in a procedural language like Java would have a tremendous negative impact on performance, since currently there aren't practical optimizations to take care of that. Such a hypothetical language would be an immediate failure, even though it might look ellegant.

Funny, I seem to have heard of some real, practical languages where every variable is an object.

Back in my early 20s, compilers and development systems were my primary interest in computers. (My reasoning was that we as programmers spend all day interacting with a development system, but don't seem to spend much time thinking about the development system, and I wanted to change that.) My source code format was going to be structured text, much like XML is nowadays. (Back then, I only had SGML as a reference.) I generated a huge stack of notes and thoughts on the system, but got to the point where I realized I'd need a team to have a reasonable chance of implementing it. And so it remains paper.

The reason I chose an XML-like source code format is that I wanted to allow the source code to be browsed by whatever visual metaphor the programmer felt comfortable with. The vast majority of average programming constructs can be expressed in any language, and allowing language-specific displays of XML-stored information seemed like a good way to allow programmers to use the system without a huge learning curve. It also allowed code written in other languages to be imported & turned into native XML-ish code instantly. That's important for leveraging legacy code.

Of course, the system supported far more constructs than the average language. It seems that most programming languages have some sort of religion they want to whip on you, and the language has a combination of features that tend to reinforce those religious beliefs. In contrast, my language featured every programming construct, and the ability to add new ones -- extending the compiler was intended to be as common as writing a subclass. The logic here was, we're real programmers implementing real projects in the real world, and we need the tools to get our job done, not some religious language-designing ninny forcing us into their dystopia.

To combat the obvious problem of bad programmers writing code that no one will be able to understand, I designed the language as two layers: the lower one is called Clay, and the higher one is called Scaffold. The idea is, Clay allowed programmers to do anything their heart desired, whether ill-advised or dangerous or whatever. It was something like a compiler-development toolkit exposed as a language. Scaffold, written in Clay, was an attempt to create a real software-engineering language on top of the free-for-all that Clay offered. Scaffold combined the low-level programming abilities of C++, the design-by-contract of Eiffel, the orthogonal pattern construct of Beta, and the high-level browsing of something like Rational Rose. The GUI would handle programmers writing code in metaphors they were comfortable with, and all of it would be stored in XML. The junior programmers would spend most of their time in a variant of Scaffold, and the senior programmers would write Clay constructs to make the development system more closely match the project, and thus make programming it less tedious and error-prone.

Oh well, it looks like once again, ideas I came up with years ago have been independently discovered, and due to my inadequate promotion skills, someone else will get the credit. I tried describing something like this back in 1995 or so, but got only glazed looks in response. (Want to hear about a neat video game I designed on paper back in 1992? The one I called "Turf"? Where you start out as a thug on the street, get jobs from gangs, and work your way up to more difficult jobs that pay better, and meanwhile you get to wreak havoc in an urban landscape? Sounds like Grand Theft Auto, you say? Damn right it does. I described it back in 1992 and got only glazed looks in response. Being visionary doesn't mean squat unless you can promote.)

- - - - - - - - - -

Think The Fountainhead is just a book? Check this out.

People interested in this should also check out Eiffel and Sather as well.

Just to bring you up to date:

Has reflection since they adopted the Eiffel Library Kernel Standard. This standard proposes the strictest and most comprehensive interface for reflection of any other OO language.

You're right, EiffelStudio is still far beyond SmartEiffel.

SmartEiffel did very well in the The Great Language Shootout back in 2001. I haven't seen any recent benchmarks but I do know that efficiency is a very high priority.

Eiffel is very much an open language. The ECMA committee is about to finish the written standard. Furthermore there has been NICE since about 1991. To say that it has been driven by Meyer's whims is to say that C++ has been driven by Stroustrup's whims. Sure they are instrumental in driving the standard, but they are not whims. Most people complain about Eiffel's lack of whims! The development of the Eiffel language has been the most structured of any I know.

I thought requirement for global type checking was a good thing.

Since when is covariance a serious problem! Covariance allows a lot of expressiveness and power. I think what you are referring to is CAT calls (Changed Availability and Type). Eiffel has an extremely tight type system, and this is a current hole in it. The hole is about half as wide as providing the ability to type cast.

Eiffel has method pointers and so much more. It has agents(chapter 25 from OOSC) which are functions treated as objects. Agents get all the benefits of objects including static typing, introspection, copying, comparison, etc. Furthermore agents support deferred parameters.

I do think C# is good, most likely because it has learned a lot from Eiffel. You won't see any direct mention of Eiffel in this article. However the style of generics and contracts are both Eiffel originals. Also Bertrand Meyer is part of the C# ECMA committee.

Can't make apps for other OS'es
And I never compiled a .NET app, but what if a Windows 98 person doesnt have the framework installed?

Also web-forms are crap - stay well clear of them!
Try and rendering a calendar control on a NETSCAPE hehe .. doesnt work! I just use my own XML/XSLT instead ...

I program in C# but really dont like it :(
It's just ahm ... too ugly methinks ..
(still searching for a better language - shame couldn't get Eiffel.NET to work)

PS: I am glad this is /. cos if this was angrycoder I would get boo-ed just for mentioning Windows 98!!! (but not their latest stuff)

For what it's worth, please make a distinction between C++ and C, they are two very different beasts. Two of the most common Eiffel compilers ISE Eiffel and SmartEiffel do compile to C code, not to C++ code. You probably refered to one of those when making your claim that Eiffel compilers generate C++ code (which is a false statement). Also please note that conceptually an Eiffel compiler can generate assembly code as well. In fact VIsual Eiffel does it. And ISE Eiffel does compile to Microsofts .Net byte code as well.

For what it's worth, please make a distinction between C++ and C, they are two very different beasts. Two of the most common Eiffel compilers ISE Eiffel and SmartEiffel do compile to C code, not to C++ code. You probably refered to one of those when making your claim that Eiffel compilers generate C++ code (which is a false statement). Also please note that conceptually an Eiffel compiler can generate assembly code as well. In fact VIsual Eiffel does it. And ISE Eiffel does compile to Microsofts .Net byte code as well.

There are compiled languages that are arguably better than C, such as Eiffel, Modula-3, and D. These may be promoted by companies, but surely not controlled. C is popular because it's simple and powerful, is good enough, and has inertia. But that doesn't necessarily mean it's the best.

Don't forget the wonders of lexical closures, something offered by any self respecting interpreted language.

And also offered by any self respecting compiled language. Just because C doesn't have 'em doesn't mean nobody else does, you know.

They so know that if they were to open up the CLR of their .net Technology, and like, allow people to write their own CLR languages, their stock would plummet.

Um, people can write their own CLR languages. Quite a few have. Hell, they even let Borland play.

Perl

Python

FORTRA

More FORTRAN

SmallTalk alike (SmallScript)

Mondrian

Pascal

Scheme

Mercury

Eiffel

Oberon

Cobol

Ya know what's annoying? Having to type in a bunch of random crap at the end of a message because slashdot does now seem to like having a low number of characters per line.

Some rather respected people in the field of object-oriented programming disagree with you.

• (US) http://ftp.eiffel.com/pub/download/macosx/54/Eiffe l54.dmg
• (Europe) http://www.cs.abo.fi/eiffel/ftp.eiffel.com/pub/dow nload/macosx/54/Eiffel54.dmg
• (Europe) http://gd.tuwien.ac.at/languages/eiffel/download/m acosx/54/Eiffel54.dmg
• (South America) ftp://ftp.pucpr.br/eiffel/macosx/54/Eiffel54.dmg

If you want to define "cross-language" as "languages that fit into this one paradigm", then yes, it's cross-language. You can make any statement true by redefining its terms.

But, just for fun, let's stick to the OO paradigm. Let me share some interesting paragraphs from an Eiffel Page on the subject.

The virtual machine provides a number of mechanisms useful to the implementers of all languages: signal handling, exception handling, security, memory management, garbage collection, debugging support. The last point is particularly interesting for object-oriented languages; although a bit apprehensive at first about the efficiency of the GC process, we were interested to discover that it uses many of the same techniques that we have applied to ISE Eiffel over the years; in particular it moves objects around, as needed to compact memory, and gives excellent performance results.

Not all applications will want to rely on these services. This is where the notion of "managed code" comes in. Code is managed if it relies on the runtime's services, unmanaged otherwise. Managed and unmanaged code can coexist; as noted above, C++ will only let you enjoy the benefits of full managed code if you limit your use of the language to a subset that roughly corresponds to a C#/Java style of programming (no multiple inheritance except from interfaces, no "friends").

You can bring in features like multiple inheritance if you're willing to let the dotnet framework give you nothing. Why implement in the dotnet framework in the first place?

Please take a look at Eiffel ENViSioN! if you're looking for templates (called generics in Eiffel and Ada, and more appropriately so IMHO) and multiple inheritance in .NET.

Also interesting is the new F# language from MS that is an implementation of (the functional language) CAML for .NET.

EiffelVision 2 that is available for free download here It is definitely the easiest GUI toolkit to use I've ever encountered, no nasty callbacks here :)

Some interesting reading:

PerlNET.

Perl for ASP.NET.

Python for .NET.

COBOL for .NET.

Eiffel for .NET.

Scheme for .NET .NET for Linux.

Lameness filter:
Important Stuff:

Please try to keep posts on topic.
Try to reply to other people's comments instead of starting new threads.
Read other people's messages before posting your own to avoid simply duplicating what has already been said.
Use a clear subject that describes what your message is about.
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Problems regarding accounts or comment posting should be sent to CowboyNeal.
Important Stuff:

Please try to keep posts on topic.
Try to reply to other people's comments instead of starting new threads.
Read other people's messages before posting your own to avoid simply duplicating what has already been said.
Use a clear subject that describes what your message is about.
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
Problems regarding accounts or comment posting should be sent to CowboyNeal.

Who does this guy work for?

Well, Bertrand Meyer is a CS professor (having posts at UCSB and Monash University), but more to the point he has a company which tries to commerialize his "Effiel" programming language. Meyer was annoyed that a group (amusingly, from Meyer's native France) made an free version of Effiel. Meyer then saw fit to attack the icons of free software in revenge. Pretty childish, really.

Eiffel Software's EiffelStudio 5.2. There ya go. Eiffel comes in a few free flavors, too, that compile just fine on Unix and Linux boxen, including your YOPY. Graphical libraries are just that, libraries, and can be called from C and whatever else. It's about as difficult, once you've done the detective work, as writing one of those stupidly long Java strings that constitutes a statement in that language.

I would argue that yes, in fact, C++ does have all the features Java has that are worth having. With C++ you certainly have access to all kinds of libraries that implement all the stuff that Java implements in multithreading, garbage collection, blah, blah, blah, but faster, and just as free. I might point out, as well, that libraries are not language features, bud. And Java, also, does not have anything, to my knowledge I'll admit, like the STL which, when you know how to use it, is key to C++'s power. I'm always impressed at how many people fire away at C++, driven often by Sun's huge shove-it-down-your-throat marketing campaign for Java, and then go on to state completely incorrect "facts" about C++'s capabilities or the operations of the STL. I'm quite sure now that Java will have generics Sun will begin to work on something comparable, and when it is released thousands of Java sycophants will herald it's genius and utility while C++ programmers will yawn and set the snooze alarm.

You are correct, it has been 6 years and the failure of ADA code to correctly catch an exception was used as an example of where design by contract could have negated a $500 million dollar loss. But if HP uses it for printer firmware I doubt it's much less robust than ADA for imbedded applications. btw for a list of some high profile uses of Eiffel in commercial and scientific environements see: Here and Here

You are correct, it has been 6 years and the failure of ADA code to correctly catch an exception was used as an example of where design by contract could have negated a $500 million dollar loss. But if HP uses it for printer firmware I doubt it's much less robust than ADA for imbedded applications. btw for a list of some high profile uses of Eiffel in commercial and scientific environements see: Here and Here

here

here. Check it out if you can as this software is great and helps me no end.

Bertrand Meyer is one of the biggest .NET boosters on the planet, and he already oversaw a port of Eiffel to .NET. This was available like a year ago.

There's also a Scheme compiler, called Hotdog, with a .NET backend:

Keep in mind that F# is but one of MANY language research projects going on at Microsoft Research, and there are many more going on at other sites that Microsoft is tangentially involved with.

Instead of seeing a NON-free version of Eiffel, I would like to se a free version.
There already is a free compiler for Eiffel, you can download it here.

available with Eiffel Software's EiffelStudio development suite. It's called Vision2 and provides platform independent look and feel by using a bridge pattern to separate an interface layer from the underlying implementation layer (which uses the Win32 API and Gtk+ for the platform dependent stuff).

You can download the full EiffelStudio suite for linux (and Windows) and use it free for non-commercial software, Vision2 is included and is available here, it's free!