Slashdot Mirror


EiffelStudio Goes Open

WeiszNet writes "Bertrand Meyer, the creator of Eiffel the language and CTO of Eiffel Software in Santa Barbara, CA has announced in his Software Architecture course at ETH Zurich that the company's flagship product - EiffelStudio was released under the GPL today. Here is the press release: and the project's page. Eiffel is an object oriented programming language supporting contracts. Last year the international standard (ECMA) for Eiffel was released and now the initiative to go open has been taken."

40 of 219 comments (clear)

  1. About time by imbaczek · · Score: 5, Funny

    This was the #1 reason for not using Eifell.

    1. Re:About time by Eightyford · · Score: 2, Funny

      This was the #1 reason for not using Eifell.

      That, and it sounds French...

    2. Re:About time by x2A · · Score: 3, Funny

      yeah it just quits half way through :-p

      --
      The revolution will not be televised... but it will have a page on Wikipedia
  2. Oh Thank God by bigtallmofo · · Score: 3, Funny

    Eiffel is an object oriented programming language supporting contracts.

    I was beginning to get concerned about the incredible lack of object oriented programming languages currently available.

    Fortunately, there's now another one to choose from that is now free.

    --
    I'm a big tall mofo.
    1. Re:Oh Thank God by shutdown+-p+now · · Score: 5, Informative
      Mods, parent is not "Funny". It's "Uninformed".

      It is true that Eiffel is not the only language with some support for OO out there. It is, however, the only industrial strictly object-oriented language with static typing enforced thoroughly on all levels. This is different from the much more relaxed model offered by the likes of Java and C#. Also, Eiffel is the only such language which fully incorporates Design by Contract (in fact, it is where it originates from) - and by that I mean not only in the language itself, but also in standard and all 3rd-party libraries as well.

      So, yes, there are many good reasons to choose Eiffel over other OO languages.

    2. Re:Oh Thank God by IDontLinkMondays · · Score: 3, Insightful

      When choosing the right tool for the job, you choose the tool that can meet a balance of three particular things.
          1) Best tool for producing the application
          2) The tool you can find people that know how to use
          3) The tool with the best support

      Well, there are tons of places that Eiffel is the best tool for the job. I would even imagine that there are circumstances where the support is there. Problem is finding the people that know how to use it.

      I've been goofing with Eiffel ocassionally, but time and time again, it proves the wrong tool for the job. It's just too different from other languages to be able to meet my needs. I always fall back onto C++ with a widget toolkit (such as Qt). It is definately not because C++ is a better language. It is definately not that Qt is the ultimate widget toolkit. It is because there is a good balance of all 3 criteria being met.

      I am 100% in favor of companies trying to sell us a new language, but what it really boils down to is that only a handful of people will use it and other than an ocassional interest article, this is probably the big hay day for the language since there is a open source news worthy article written about it.

      Another great example of a language that is probably better but has never picked up steam is Scheme. Every compiler developer in the world loves scheme. It is by far the most heavily optimized compiled language on the planet. It has great merits. But the fact is that with the exception of the scheme compilers written in scheme and an ocassional university project, the language stalled years ago.

      The parent comment to yours was sarcasm... it may have been misinformed as you comment, but the fact is that he is right in his sarcasm.

    3. Re:Oh Thank God by civilizedINTENSITY · · Score: 3, Insightful

      "I am 100% in favor of companies trying to sell us a new language...", but since Eiffel dates back to 1985-86, I don't know what you mean.

      "Another great example of a language that is probably better but has never picked up steam is Scheme. Every compiler developer in the world loves scheme. It is by far the most heavily optimized compiled language on the planet. It has great merits. But the fact is that with the exception of the scheme compilers written in scheme and and an ocassional university project", which is what it was designed for: Scheme was meant to be simple rather than useful, in order to further the study of such things as program correctness (software algorthims studied as mathematics) by academia. The industrial version is Common Lisp.

      When discussing the right tool for the job, comments regarding the attempt to use a thermometer as a hammer (Scheme vs Common Lisp) make it hard to take your C++ vs Eiffel seriously, especially since you seem to think a 21 year old language is "new". It is old enough to drink.

    4. Re:Oh Thank God by maxwell+demon · · Score: 3, Funny
      It is old enough to drink.

      I'm not sure that drunken languages are an advantage :-)
      --
      The Tao of math: The numbers you can count are not the real numbers.
  3. Re:Info please? by Jello+B. · · Score: 5, Informative
  4. Re:Info please? by jbolden · · Score: 4, Informative

    The big thing is design by contract. Calling procedures specify what they will guarantee functions and what they expect, functions guarantee what they won't change and list what they expect. This makes code reuse actually practical, since global effects are spelled out.

    For example a sqrt function will require x >= 0, that is the calling function must have checked. Since this is specifically listed in the contract your calling function is expected to be able to indicated how it knows that x >= 0 before computing sqrt(x).

    The second big thing is that the language is pretty high level and you just give hints to the compiler about how to implement things (sort of like Oracle SQL) unlike Java or C++ where implementation details are definitely part of the program.

    That's pretty much it.

  5. Re:Info please? by Coryoth · · Score: 5, Informative

    I haven't heard of this language, and don't want to do too much research (go go procrastination!). Can anyone tell me some of the basic info about this, and what makes it different? Why would I want to use this language over something already available, for example.

    Eiffel has been around for a long time, and is a mature language. What does it offer? A very clean and well designed Object Oriented language with a very clear and readable syntax and great support for Design by Contract. The principle behind Design by Contract is simple enough: objects, and methods provide contracts - providing you meet their stated requirements, the guarantee things in return. Statically typed languages offer some level of this already: you have to provide paramters of the right datatype, and it guarantees the datatype of the return type. Design by Contract essentially just extends this principle to allow for much more expressive contracts than just type signatures, and things like object invariants (properties of an object that are guaranteed not to change). The result is a much clearer statement of intention as to how code should work, and a powerful test harness that massively speeds up the test/debug cycle. In theory you can achieve this by liberally sprinkling assertions through your code. The advantage of having a language with explicit support for Design by Contract is that things like inheritance of contracts and invariants are all handled automatically and elegantly etc.

    As well as this release of EiffelStudio as open source, there's SmartEiffel which is an open source Eiffel compiler (which supports a number of extra features beyond what is given in the recent ECMA spec).

    Jedidiah.

  6. Eiffel Contracts by j · · Score: 5, Informative
    I had to look up what Eiffel Contracts were:

    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.
  7. The Real Link by ploss · · Score: 5, Informative

    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.

    --
    What are the odds that some idiot will name his mutex ether-rot-mutex!
    1. Re:The Real Link by zsau · · Score: 2, Informative

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

      Depending on what browser you're using, you might actually be able to have a reasonably accurate automatic PDF warning system. It's not perfect (it goes by the name of the link, so if you've got a download page in between it marks it as PDF, and if there's a file without a PDF extension that is PDF, it doesn't get noted), but it works reasonably well. (Obviously the best solution is to get the linkmaker to do it properly, but if they don't, this is a pretty good fallback.)

      Basically, you add the following exerpt to you system's CSS file, which is usually called chrome/userContent.css in your profile folder if you're using a Mozilla-based browser.

      a[href$=".pdf"]:after {
                      font-size: smaller;
                      content: "[pdf]";
                      line-height: 0;
                      vertical-align: super;
                      text-decoration: none !important
      }

      I got it from someone else at Slashdot, but I can't remember who.

      --
      Look out!
  8. flashback by agendi · · Score: 5, Interesting

    I'm having first year comp sci flashback! I remember at the time being taught Eiffel as my first OO langage used to teach OO techniques and design - I hated it back then it felt clunky, overly protective and claustraphobic. Now after almost 10 years as a programmer every so often I crack open the old textbooks and think "wow.. that is rather elegent and expressive". Eiffel is engineered/designed - it is deliberately not suited if all you want to do is hack about. It's funny, only yesterday I was using Eiffel as an example to my IT team as a language that forced strong contractual based interfaces.

    --
    I just can't be bothered.
  9. To make a long story short ... by ScrewMaster · · Score: 4, Funny

    In other words, Algorithms + Data Structures = Programs. I'll be damned ... that Wirth guy was right after all.

    --
    The higher the technology, the sharper that two-edged sword.
  10. the "pet rock" of programming languages by Speare · · Score: 3, Insightful
    This guy has had what, fifteen years? The language is a niche language in a crowded field of languages. It's not going to just catch fire and get more fans because you slapped the seal of Free Software onto it. It smells more of an abandonware goodwill gesture than anything.

    As a language, Eiffel doesn't make it more convenient to express a problem to receive a good solution, it just makes the programmer follow the public speaker's maxim:

    • First, say what you're about to say; then say what you came to say; then say what you just said.

    Programming by contract is essentially just writing twice as many unit tests, wrapped all around the code that is supposed to be doing the work. It's even easier to write bad tests when it's right next to the code being tested, so why bother?

    Bertie, give it up already!

    --
    [ .sig file not found ]
    1. Re:the "pet rock" of programming languages by QuantumG · · Score: 2, Funny

      Harsh.

      --
      How we know is more important than what we know.
    2. Re:the "pet rock" of programming languages by Coryoth · · Score: 5, Informative

      Programming by contract is essentially just writing twice as many unit tests, wrapped all around the code that is supposed to be doing the work.

      Programming by contract is writing your unit testing harness as assertions while you write the code, and having those assertions respect inheritance elegantly, saving you considerable work if you actually have any sort of class heirarchy built up in your code. Programming by contract is about stating clearly how you intend your code to work so that it is much easier to determine whether the code you wrote actually does what is intended or not. Programming by contract is about providing clear and explicit documentation of the interfaces making code reuse and code maintainability far easier.

      Programming by contract is not the right choice for every programming project. Sometimes you want flexibility. Sometimes rapid adaptability is more valuable than correctness or maintability. Sometimes, however, it is not. I don't draw up careful plans to build a treehouse, I hold the wood where I want it to go and cut it to fit: being able to adapt to the exact organic shape of the tree is more important than the strict integrity and finish of the treehouse. Likewise I don't build home by nailing 2x4's together and cutting the next chunk to fit: Having a truly solid structure, with all the walls and floors are properly aligned is more important than the speed with which I can get started building something. Different projects have different needs, and there are plenty of projects for which Design by Contract is a fantastic way to go. Just because you, personally, don't happen to work on those projects, doesn't invalidate its usefulness for others who do.

      Jedidiah.

    3. Re:the "pet rock" of programming languages by GileadGreene · · Score: 2, Informative
      Effiel was the first language with garbage collection if I remember correctly.

      Er... you don't recall correctly. Lisp had garbage collection in the early 60's (in fact, John McCarthy invented garbage collection specifically for Lisp). Eiffel isn't even the first OO language with GC - that honour goes to Simula (also the first OO language ever).

    4. Re:the "pet rock" of programming languages by swilly · · Score: 2, Interesting
      Wasn't java based off it?

      Not even close. Java most resembles Object Pascal with C++ friendly syntax.

      Effiel was the first language with garbage collection if I remember correctly.

      Lisp is the first language that I'm aware of to use it, but I bet someone else did it even earlier. Most functional languages use garbage collection. Eiffel is the first statically typed language I'm aware of to use garbage collection (as part of the language itself, not implemented in a library). This is probably the area where Eiffel most influenced Java.

      Eiffel's most notable features are Design by Contract, Multiple Inheritance, and Generics, and it's been doing all that for over fifteen years (as opposed to Java and C# which only recently figured out Generics). Design by Contract is particularly nice if you are willing to spend a little extra effort to write very reliable code, but it would be even better if there were good theorum provers out there to verify that contracts will always hold and warn if they don't. The would be much more developer friendly than the predicate calculus normally associated with formal methods.

      Eiffel's biggest drawback (to me) is the horrible Pascal like syntax. Some of Meyer's philosophy has also made the API a little clumsy in places. His belief that a method should never return a value and have a side effect is particularly bad. Writing a stack with get_top() and remove_top() instead of pop() is a little weird.

    5. Re:the "pet rock" of programming languages by Coryoth · · Score: 2, Informative

      Design by Contract is particularly nice if you are willing to spend a little extra effort to write very reliable code, but it would be even better if there were good theorum provers out there to verify that contracts will always hold and warn if they don't. The would be much more developer friendly than the predicate calculus normally associated with formal methods.

      If that's what you're looking for then I would suggest that you take some time to check out JML and ESC/Java2 which provides almost exactly that functionality for Java. It's not as clean as Eiffel as the contracts have be be kludged into Java as add-on annotation in comments, but all the functionality you'd want in a good expressive DbC system is there in JML, and ESC/Java2 provides a static checker/theorem prover that can attempt to verify contracts and provide warn you when they might fail. It also provides a number of other strong static checks based on JML annotations, allowing you to have high degree of confidence in well annotated code that passes ESC/Java2. Honestly, download JML, JMLEclipse and ESC/Java2 and try them out - you'll be amazed the number of subtle errors that can be quickly and efficiently caught!

      His belief that a method should never return a value and have a side effect is particularly bad. Writing a stack with get_top() and remove_top() instead of pop() is a little weird.

      It seems odd, but it does have nice aspects, particularly if you're used to a more functional perspective: it goes a long way toward isolating side effects and allowing better reasoning about the scope of effects that a given block of code may have. It certainly makes sense to me.

      Jedidiah.

    6. Re:the "pet rock" of programming languages by maxwell+demon · · Score: 2, Funny
      Well as I recall it was (1) flipping switches (machine code), then (2) assemblers, then (3) macroassemblers, then (4) fortran, then (6) lisp. I'm pretty sure that the first 5 didn't have garbage collection.

      Somehow I'm missing (5) ...
      --
      The Tao of math: The numbers you can count are not the real numbers.
  11. Eiffel is pretty fast... by dudeX · · Score: 2, Interesting

    At least according to this website I found via the Artima.com website.
    It lets you compare any two languages that have compilers in Linux and it gives you a graph of speed vs memory usage in various kinds of programming patterns such as matrix math, branchy programs, etc.
    Eiffel (compiled with SmartEiffel) vs C++ (GCC 3.3.4) is actually slightly faster than C++ in almost all of the tests that the author came up with. And the memory usage is just as efficient as C++.

    I've looked at Eiffel, but the syntax isn't very pretty. However, for important projects I think Eiffel will be the right language for the job.

  12. Re:Differences by Coryoth · · Score: 2, Interesting

    What are the differences between Eiffel and other free object oriented programming languages? What does Eiffel have that Ruby, Python, and Java do not?

    Compared to Ruby, Python and Java the biggest thing Eiffel has going for it is raw speed. Consider the benchmarks and you'll see Eiffel is much much faster than Java, with considerably less memory use. You get that sort of performance from a langauge with an exceptionally clean, well designed and engineered OO system, and great support for Design by Contract, and a very clear readable syntax: learning Eiffel is very easy.

    If you're doing very dynamic work that really calls for the flexibility of Python or Ruby, then Eiffel probably isn't for you. If you want something to build robust complex large scale systems then Eiffel is actually better than Java for producing robust, well documented, reusable, maintainable code - and its faster to boot. Java, of course, has its own advantages in terms of "run anywhere" and its huge standard library, but Eiffel is well worth acquainting yourself with.

    Jedidiah.

  13. always wanted to try it by goldfita · · Score: 3, Informative

    I've heard of Eiffel a number of times. The contract by design feature intrigues me; I've always wanted to try it. Well, I guess now I have more incentive. I don't think there's anything like it in the more common languages - C, Python, Java, etc. When I'm coding, I usually try to force myself to make decisions about which objects/functions are responsible for what. But it never seems to work out that way. Things decay over time.

    I've wondered just how much a language can compensate for programmer laziness, carelessness, or just lack of ability. This question recently came up in a discussion. I am somewhat confident that software or languages can be designed to force good behaviour and eliminate (certain types of) mistakes. After all, there are no memory leaks in scripting languages, right? And you can't write to memory that's not yours. In lisp, it's harder to make off-by-one mistakes than in some other languages. Java forces you to handle error conditions with checked exceptions.

    Yeah, I'm going to have to try this eiffel thing.

    1. Re:always wanted to try it by killjoe · · Score: 2, Interesting

      The thing is that companies by and large don't want to hire great programmers because they cost too much. They would rather hire a bunch of mediocre or crap programmers and make them use a bondage language like java or eiffel. The idea is that you need one sort of smart guy to design the application (writing the interfaces, contracts etc) and then an army of easily replaceable monkeys to do the actual implementation.

      I don't think people will use eiffel for personal projects because there is no sense in putting yourself into bondage like that. The super l33t programmers seems to prefer really fluid languages like lisp and smalltalk.

      --
      evil is as evil does
  14. Back in the day, before C++ was the "winner"... by IvyMike · · Score: 3, Informative

    For all of those hearing about Eiffel for the first time. Back in the mid 80's, when the OO paradigm was first starting to gain traction (but it wasn't obvious that C++ would become the first mainstream object-oriented language) there were debates about whether the big OO language of the future would be C++, Smalltalk, or Eiffel.

  15. D programming language by WalterBright · · Score: 2, Informative

    If you want contract programming, but prefer C++ style syntax to Eiffel style, try the D programming language.

    http://www.digitalmars.com/d/

    1. Re:D programming language by wysiwia · · Score: 2, Insightful

      If you want contract programming, but prefer C++ style syntax to Eiffel style, try the D programming language.

      It's sad but I fear the D programming language will face the same fait as Eiffel: Not enough used! But I've several times said how this can be solved. I really hope people would listen to my suggestion since I think the D language is well worth the effort.

      In OpenSource no matter what you do, to become successful you have to be the number one in your area. Only then developers are faced to delve into your product and use it because it's state of the art in its area. But it's ridiculous to compete in any area where others have a 1000 or more times more developers. If possible compete in an area where others only have less than 10 times as much as you.

      For the D language there is an area which it can easily become the number one, that's the small C-libraries area. D is perfectly well suited to replace C in this area. But someone has to start this process (sorry it's not me) else this change won't happen. There simply has to be enough sample code around until others start to use D also.

      I'm quite sure that if D successfully tackles the libraries area it will soon become the chosen candidate for kernel development and after that for framework development, etc. But it won't become a successer for C++ before it hasn't become a successor for C.

      O. Wyss

      --
      See http://wyoguide.sf.net/papers/Cross-platform.html
  16. Re:Differences by Pxtl · · Score: 4, Informative

    1) Designed for native compilation. Compare it vs. Common Lisp and C++, not the modern enterprise toys.

    2) Design-by-contract. Think of it as taking type-safety squared. Just like static-typed languages are more verbose but compile-time safer than dynamic-type languages (don't argue static/dynamic, you know damn well what I mean), design-by-contract is moreso.

    3) Extremely generic-oriented and had generics designed in, as opposed to the after-the-fact hacks that appeared in C++, Java, and C#. And it has multiple inheritence.

    Plus, I'm also very disappointed by all the languages you listed being non-generic Algol family languages. That's like asking someone "what's your favourite beverage - Coke, Pepsi, or RC Cola?" The example languages you listed are all of the same line of descent (although Ruby pulls more from SmallTalk than the others). Plus, most of the languages you mentioned are just a mishmash of features. Eiffel is more like "Lisp" in the mentality of design, which is "keep the language simple but make it expressive enough that complex concepts can be expressed simply anyways".

    Such languages tend to be much more intelligently structured, safe, and extendable, but also fall short in legibility.

    Basically it is similar to Ada and C++, with a little functional programming thrown in. The problem is that most attempts to make C++ "safer" have focussed on ripping out language features like multiple inheritence and templates that made it "too complicated" but were important, useful features. Eiffel takes the alternate approach - instead of paring down the featureset, it pares down the language while actually expanding the featureset.

    And if you've never coded with generics and still just typecast your container data: get out of my sight you disgusting hacker. OOP without generics is like a car that only turns left - sure you can go right, just do three lefts.

  17. Re:.NET/Mono by Coryoth · · Score: 2, Informative

    It's also worth noting that the GNU Eiffel com piler SmartEiffel provides a tool that can compiler Eiffel code to Java byte-code, so you can run Eiffel programs on a JVM too.

    Jedidiah.

  18. Re:Talk about Situational Irony by jbolden · · Score: 3, Interesting

    You aren't remembering correctly, he went after all open source and free software. His biggest criticism of Stallman and Linus was for not distancing the free software movement from the NRA when Raymond tried to link the two (he held Stallman more responsible since Linus being a Finn might not have known what the NRA was...). He attacked FreeBSD explicitly for poor quality.

    What is funny though he lists a whole bunch of reasons vendors turn something open source that pretty much amount to "it isn't worth keeping as commercial product for reason X" where he lists the possible X's. Anyway here is a reminder:

    http://www.apostate.com/programming/bm-freesoftwar e.html

  19. Re:this is why /. is dead and digg triumphant by Noodlenose · · Score: 2
    I don't know what you had in your coffee this morning, but rants like this are not constructive.

    Sure, Digg can deliver some news faster, but then I prefer the depth of the userbase on Slashdot, the moderation system, the fact that it is frequented by more than just 16 year olds and of course its lovely green.

    If Digg is what you want, Digg is what you should get, so piss off.

  20. Re:Differences by scragz · · Score: 2, Funny

    ". . .the biggest thing Eiffel has going for it is raw speed."

    Wikipedia's entry gives the secret to this raw speed:

    "Eiffel is generally closely connected to C: three of the four Eiffel compilers output no object or machine code, but only C source code as an intermediate language, to submit to a C compiler, for optimizing and portability."

  21. Progress or abandonware? by Animats · · Score: 2, Informative
    Is this one of those "we're not making money with it so we're going to GPL it and abandon it" deals, or is it real progress.

    Eiffel is kind of dated. Even its successor, Sather, didn't catch on, even though Sather has been out under the GPL since 1999. There are some great ideas in there, but the language was a bit too clunky. It's kind of like Ada and Modula in that respect; the concepts are sound but the syntax is too bulky to become popular.

    On the other hand, all the languages listed here protect against buffer overflows without requiring an interpretive run-time system.

  22. yeah? really? by penguin-collective · · Score: 2, Insightful

    The benefits of Design by Contract include the following:

    Ah, and this has been demonstrated how? Programming language designers like to dream about how their features are going to lead to fewer bugs, lower costs, and all that, but there is almost no acceptable experimental data to support their claims.

  23. The many uses of Design by Contract by ribuck · · Score: 2, Interesting
    Design by Contract, how do I love thee, let me count the ways...
    • DbC is a documentation tool. It specifies the behaviour of a class concisely and precisely.
    • DbC is a design tool. The application is specified by means of classes equipped with assertions (I call this Contract Driven Design, or CoDD).
    • DbC is an enhancement tool. Assertions can be added to existing code to make it more robust. I call this Contract Hardening, or CoHa.
    • DbC is a maintenance tool. Assertions can be added to existing code to confirm (or improve) understanding of the behaviour of existing code prior to changes being made.
    • DbC is a refactoring tool. Assertions make sure that desirable behaviour is retained even in the face of extensive refactoring. Eiffel code is so malleable when it is contract-equipped.
    • Dbc is a correctness tool. Assertions in parent classes help ensure that child classes (which inherit the parents' assertions) are substitutable.
    • DbC is an error-handling tool. Assertions define the success or failure of a routine and direct its error recovery during exception handling.
    • DbC is a concurrency tool. Well, it will be when SCOOP is fully-implemented, because preconditions play a key role in synchronization.
    • DbC is a testing tool. It enables a tool like AutoTest to stress-test your code for you, based on the contracts that you have specified.
    • DbC is a project management tool, for maintaining and enforcing specifications.

    Have I missed any?

    By the way, here are some useful links related to the newly-open-sourced EiffelStudio, and you can find additional Eiffel libraries and tools at EiffelZone.

  24. Re:Eiffel Contracts are syntactic sugar by Anonymous+Brave+Guy · · Score: 2, Insightful

    You can acquire and release resources in many languages, too, but using the RIAA idiom in C++ you never forget the latter, while in languages that rely on finally or Dispose or whatever, you can.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  25. Re:It's true. The french name is really irritating by Archtech · · Score: 2, Insightful

    Well, you opened this can of worms; so I'll close it. And by the way, I do not "hate America". On the contrary, I very much like and admire America, and almost all Americans. Which is why it depresses me so much when they write things like your last article.

    "I hate everything french for all the basic reasons most people hate the french which are all more or less deeply rooted in their insurmountable arrogance".

    Yeah, right. Those arrogant French, thinking they are God's chosen people! Don't they know that *Americans* are God's chosen people?

    And they're a real bunch of chicken-livered, gutless surrender monkeys, too - right from Charles Martel who defeated the Arabs at the battle of Tours in 732 (preventing Europe from becoming a Muslim continent), to the heroes of the Resistance who fought on against one of the most viciously efficient repressions the world has ever known. By way of Joan of Arc, Napoleon and his soldiers who conquered Europe in about ten years (on foot), the Foreign Legion and many, many others. Not to mention Lafayette -

    "In 1777, Lafayette purchased a ship, and with a crew of adventurers set sail for America to fight in the revolution against the British. Lafayette joined the ranks as a major general and was assigned to the staff of George Washington. He served with distinction, leading American forces to several victories. On a return visit to France in 1779 Lafayette persuaded the French government to send aid to the Americans. After the British surrender at Yorktown, Lafayette returned home to Paris. He had become a hero to the new nation. At home he cooperated closely with Ambassadors Benjamin Franklin, and then Thomas Jefferson in behalf of American interests". http://www.lucidcafe.com/library/95sep/lafayette.h tml

    As for the "surrender" part, in September 1939 Britain and France declared war on Germany because it had invaded Poland. The USA did nothing. In 1940 Germany invaded France, launching one of the most inspired, unexpected, and vigorous surprise attacks in history. This defeated the large British and French armies, and compelled France to surrender. The USA still did nothing. At that time the US army (and other armed forces) were pathetic remnants. It took a full two years to get them up to a level at which the administration dared to enter the war. Had the USA been where France was in 1940 - right next to Germany, with a long land border - the Wehrmacht would have walked in, pulverised the US armed forces, and taken over the country with contemptuous ease. (Ask any competent American officer if you doubt this). With the Atlantic Ocean in the way, nearly two and a half extra years to get ready, about three times the population of either France or Germany, and far greater natural and industrial resources than both put together, the USA finally entered the war - but only when it was forced to because Hitler declared war on it.

    As for "rescuing" France, don't be ridiculous. The USA was at war with Germany; to win, it had to invade Germany; and the only reasonable path lay through France. Taking credit for having liberated Europe, when the only reason the USA was even in the war was because the dictatorships attacked it, is the sheerest hypocrisy.

    At least the French had the guts to take on Nazi Germany. The USA, which didn't dare take on Hitler, was happy to attack Saddam Hussein - a third-rate copy of Stalin, with a large army of disaffected, poorly-trained troops equipped with obsolete Soviet weapons. About as brave as a farmer going out with a combine harvester to cut a field of wheat.

    --
    I am sure that there are many other solipsists out there.