Talk:Eiffel (programming language)/Archive 1

Older comments (2004 or so?)
This all reads a bit like advertising copy for the ISE commercial product. Is there someone out there who actually knows Eiffel, but also knows something else and can give a more realistic appraisal. (Yes, it does look like a nice language, but there are other nice languages, and this stuff is just over the top.) -- Geronimo Jones. (This comment is now largely obsolete due to much work on the page. Thanks guys.) -- Geronimo Jones.

--

I have taken out a lot of preachiness in the recent changes to the "fascism" section and tried to make it more factual; however, it was so absurd to begin with (and I am such an Eiffel advocate) that it may require more work.

Also, I removed unsubstantiated and inflamatory claims that Eiffel compilers are somehow "smarter" than C++ compilers. The discussion of moving runtime analysis to compile time presumably refers to the SmartEiffel compiler's ability to devirtualize method calls, and even to inline dynamically dispatched methods. However, this alone (while clever) is no great compiler breakthrough---Self and Smalltalk have had devirtualization for years---and it certainly doesn't allow SmartEiffel to claim that it's "smarter" than C++ compilers (some of which, in fact, can also do some devirtualization). On the contrary, SmartEiffel produces C code, and therefore leaves all the difficult aspects of compilation to the C++ compiler (eg. optimization, register assignment, etc.).

For what it's worth, I think the section Elegance, simplicity, or fascism? is really silly. There are a variety of languages that are simple and more high-level than C, and these comments could apply to any one of them. Moreover, "clever coding tricks" are not what I'd call optimization hints to the compiler; they are hand-optimizations. Finally, "Eiffel seeks to produce a quality software system over anything else" seems to imply that other languages are not designed for this purpose, which is silly &mdash; even C was not designed primarily for performance. Fascism is pretty over-the-top too &mdash; I dare anyone to design a "fascist" language. I'm seriously considering deleting this whole section, if there are no objections. Deco 21:13, 15 Nov 2004 (UTC)


 * I agree. The section is a sales pitch.  Eiffel leans more toward clarity (over efficiency for example) than many other languages, but this section as it stands doesn't explain that very well.  There are probably a couple of nuggets in that section that could be reworked into the article a different way, but on the whole I think the article would be improved by this section's deletion.  --Doradus 14:38, Nov 16, 2004 (UTC)


 * Really, this article needs a serious cleanup. The trouble is, I have found that computer science articles don't stay cleaned up for long.  Well-meaning CS people come along and add in their opinions, seemingly unaware that they are not objective facts.  That's why I have turned my attention more towards science and astronomy articles lately.  :-)  --Doradus 14:40, Nov 16, 2004 (UTC)

Pure OO
In the section where it is claimed that Eiffel is pure OO, it introduces control structures that are not in any way object oriented. I'm not a purist or formalist, but if you claim a language to be pure OO, "special form" control structures like loops and ifs should be replaced by message sends (like in Smalltalk). This page really is a sales ad!


 * Yeah, the claim of "pure OO" is meaningless, as everyone has different ideas of what constitutes purity. Probably the fact all Eiffel types are classes (even INTEGER and NONE) contributed to this claim, but as you say, there are different dimensions of purity.  --Doradus 18:33, Dec 13, 2004 (UTC)

- The loop example is silly, it would be better to show an example using the COLLECTION interface or at least *even* an example of that, since you almost always use that interface which is available in every kind of sequence/list/array/data structure.

from x.start until x.after loop x.forth x. end
 * Have one question -- what is "x." you've used there? I'm not guru in Eiffel, but can you explain this for me? Why should this be placed in the article if this isn't clear? May it is better to use simple examples? -- Kolesnikov P.A. (ru-wiki) 17 June 2006
 * I guess that the x. is a typo, it has no mean in Eiffel syntax. Whereas x is a reference to an instance of a class that inherits from TRAVERSABLE[G] (in the eiffel base). Momet 16:33, 17 June 2006 (UTC)
 * That's clear for me now that "x." has no meaning. But said "inherits form class in the Eiffel Base" -- you restricted that example only for those implementations with Eiffel Base. IMHO, that are ISE Eiffel and Visual Eiffel. Am I right in that? And SmartEiffel hasn't this class at all. --Kolesnikov Paul
 * I think I made a mistake, it's not TRAVERSABLE in the EiffleBase (from ISE), I guess it has to inherit from LINEAR, but don't trust me... There is something very similar in SmartEiffel, and it is ITERATOR, see this documentation for more informations Momet

Reflective?
The article began like this: "Eiffel is a reflective, object-oriented programming language[...]" Eiffel is not reflective. I don't know where did that come from, but Eiffel is a statically typed, *compiled* language (it's usually compiled to C). The runtime system includes a garbage collector (usually mark-and-sweep) and not much else. Of course this doesn't mean one cannot write an implementation of Eiffel which provides facilities for reflection, but I haven't heard of such an attempt and it would be against the "nature" of Eiffel, as far as I can tell. Maybe we are talking about a different kind of reflection? Regarding programming languages it usually has the meaning defined at the famous [] but Eiffel is famous for inventing their own terms for everything (features instead of methods, etc).


 * Compiled languages can be reflective. There is no requirement that reflection has to be at runtime. Read Reflection (computer science) for more information. - DNewhall

Bias
Out of curiosity for the language I just read this entry, and I have got to say, though the author(s) clearly have been trying to be objective it is quite a biased account. The neutrality of the article feels very superficial, and the tone of the contents is clearly that of an ardent advocate. I had no preconceptions of the language but after reading the article I find myself slightly put off from Eiffel simply from the subtextual bias present the text. -- Mikademus


 * The group of people who have contributed to this article tend to be a self-selecting group of people who like the language, and may not even be aware of the biases we have inserted. We welcome any assistance in identifying the biased portions. --Doradus 17:56, 19 November 2005 (UTC)

It is difficult to point out specific things since the entire text emits a promotional air, not overtly, but undeniably there. It goes to the credit of the authors, however, that much effort has obviously been spent on trying to retain NPOV. Nonetheless, one salient thing is the "contra-sed contra" argumentation style prevalent in the text. To provide one example from early in the article:

"Eiffel intentionally limits stylistic expression, providing few means for clever coding tricks or coding techniques intended as optimization hints to the compiler. Some software developers feel constrained by Eiffel's simplicity and compiler-enforced structure; the language has been referred to as a "bondage and discipline" language.

In contrast, others feel that the simplicity of the language not only makes the code more readable, but also allows a programmer to concentrate on the important aspects of a program without getting bogged down in implementation details. Eiffel's simplicity is intended to promote simple, readable, usable, reusable, reliable and correct answers to computing problems. Eiffel seeks to produce a quality software system over anything else."

Though neutral by definition, the entire phrase "Some software developers feel constrained by Eiffel's simplicity and compiler-enforced structure" is designed as a counter-argument in itself, and the entire following paragraph is in turn a defence, then turns the table on the antagonist to show that the alledged weaknesses are really strengths, before finally, ending in close to pure promotion for the greatness of Eiffel. Again, I know nothing at all about the Eiffel language, but I do know marketing (even subconscious such).

This style is recurrant in the article, and, though from good intentions, is more reminescent of sales talk than encyclopaedic treatment or dispassionate analysis. Hope this helps! Mikademus 21:04, 19 November 2005 (UTC)

I think the sentence fragment that reads "which emphasizes the production of robust software" is questionable. It would be better (more accurate/NPV) to change this to something along the lines of "emphasises the production of software which is provable correct to a formal specification". Esp. given the Eiffel tendency to fail hard on contract breaches at the expense of absolute robustness.

Thrown away Principles?
Does anyone know what exactly are these 'thrown away' principles?

This standard is not accepted by the SmartEiffel team, which has decided to create its own version of the language, because they think the ECMA standard throws away important principles of the original language. Eiffel Software and Gobo have committed to implementing the standard. Object Tools has not to date expressed a position.

--rolandog 02:08, 17 April 2006 (UTC)

Begun?
What's wrong with starting a sentence with "begun"? --Doradus 19:57, 9 May 2006 (UTC)

What code formatting convention should be used?
The font conventions and in particular the use of blue for program texts are part of Eiffel's style conventions. Whatever rules are applied in the descriptions of other languages are not applicable here. Thanks for respecting the specific rules for Eiffel. B-Meyer 17:18, 20 August 2006 (UTC)


 * That colour and style use would demand a short note before the first code example mentioning this. Also, in the discussion following or surrounding the text, the normal  should be used since using blue text in caps in body text makes the article look garsish, difficult to read, unencyclopedic and deviates from the wikipedia style guide. Also, it probably won't carry to a possible printed edition. So sure, go wild with idiomatic colours in code examples but use the conventional black-in-  style in the text. Mikademus 17:38, 20 August 2006 (UTC)


 * Thanks for the advice. I am applying it at the moment (include &lt;code&gt;), but I think that using black in the text would be confusing — the connection with the code extracts then disappears. Changing to code fonts, although this is not done in Eiffel documentation, should make the mix look less "garish" to you.


 * I think the blue text is improper for this article because A) it's easily confused for a link and B) no other article uses it. - DNewhall 21:10, 20 August 2006 (UTC)

These idiosyncratic blue fonts should really be removed. It doesn't make any difference what Eiffel's own documentation uses for formatting conventions: this is an article on Wikipedia, which has its own set of typographic (and other) style conventions. There would be a case for exact colors (well, as exact as web rendering can be) if this were on Color Forth or the like: i.e. something where colors are part of the actual program semantics. But that is not true of Eiffel. LotLE × talk 19:41, 21 August 2006 (UTC)


 * I appreciate the desire for consistency, but faithfulness to the subject matter should always supersede other criteria. Let me again ask you not to redefine Eiffel. The font conventions are part of the language rules. Eiffel is not just a programming language; it is a certain way of thinking about software and describing it. In particular, it is a language for publication of programs. B-Meyer 21:38, 21 August 2006 (UTC)


 * If the use of blue fonts is idiomatic to Eiffel code I for one have no issues with a blue colour being used in the code examples. Examples are just that: examples of language structure, grammar and style. Thus, though other may disagree with me, I personally find the blue colour appropriate if it is as is claimed, a convention used by the majority of the Eiffel community. However, I would for several reasons strongly recommend the blue to be removed from the bread text: first of all it does break with wikipedia style and will cause a lot of negative reaction from many readers and editors. Secondly it does in fact make the article a bit garish and distracting. Thirdly, colours in the text does not contribute anything, the point is already made in the code examples. Finally, as has been stated above, it is somewhat confusing because they blue passages as suggestive of hyperlinks. Look at this artificial paragraph I cut together from the article (note that I have link underlining turned off, as have many others too):
 * The concepts of Design by Contract are central to Eiffel. The keyword in that case is no longer  but.
 * All wikipedia programming articles follow the convention of black-in- for keywords etc discussed in the text. That this article should not will ruffle feathers and is, above all, unnessesary and superfluous. When I look at a painting I want to see the colours. When I read a critical review of it I do not want it written in matching colours. Also, think about the wether to use bold and italics in the text, the current libera use, while mirroring the constructs in the code examples, are again if not confusing then at elast contributing to the garishness.  . Mikademus 22:17, 21 August 2006 (UTC)
 * Adding another note when on the topic, every so often there are links inside code-tags, like . Considering that, I assume you see the unreasonableness of colouring the text itself. Mikademus 22:35, 21 August 2006 (UTC)


 * Two things, first the statement "Let me again ask you not to redefine Eiffel. The font conventions are part of the language rules." by Dr. Meyer is incorrect. Quoting the ECMA standard : "The color-related parts of these conventions do not affect the language definition, which remains unambiguous under black-and-white printing (thanks to the letter-case and font parts of the conventions). Color printing is recommended for readability." So color printing is NOT part of the standard for any other reason besides formatting of text. If this is to be considered part of the standard then we also have to use BNF to describe everything because that is defined in the standard. Second, while Eiffel is defined as a specification language too a quick look at the title of this article shows the text "Eiffel programming language". - DNewhall 23:00, 21 August 2006 (UTC)

The ECMA text that yo cite precisely confirms that this is the way Eiffel text should read. That text is in fact saying the same as the Wikipedia rules: semantics should not depend on color. On the other hand, color should be used to reinforce semantics, in a consistent way.

Until I and another person started working on the Eiffel article a few weeks ago it was a disgrace, full of inaccuracies and opinions, with almost no factual information on the language (a single code extract, "Hello world", and poorly written at that!). Apparently that was not a reason to complain. Now that we are devoting our time to producing a good article with the same standards of quality as a scientific publication we are being heckled by people who only care about enforcing some font commonality.

I wonder if you realize the harm that you are doing to Wikipedia by harassing the designer of the very technology that the article describes. Maybe I am naive or pretentious, but I would assume that such a contribution by the original author should be enjoyed rather than heckled down. If you want to turn away such contributors, and get to the level of soc.culture discussions, this is exactly the way to go. I don't assume that's the case, so please correct errors of substance if you find any (I make no claims of perfection) and in the meantime respect the conventions and rules of the topic being addressed. Thanks. B-Meyer 23:32, 21 August 2006 (UTC)


 * Unfortunately, the Wikipedia warning against autobiography, WP:AUTO, is there for a fairly good reason. While this article is not autobiography per se, I would suggest that the chief architect of the language should take a step back from too much emotional investment.  It's hard to have a good NPOV distance from a topic you are so close to.  We appreciate the great help you've given to this article, Bertrand—and indeed, I appreciate that you've created an interesting and well-thought programming language.  I see you've also made contribution to a number of other related article topics.  But an encyclopedia takes its own values as primary: this isn't an advertising pamphlet for Eiffel, and neither is it the official documentation that your company produces.  But most especially, nothing you write here is anything that you have any more ownership in that does every other Wikipedia editor.


 * The typographic issue is somewhere in the middle of where the content's conventions intersect with the conventions of Wikipedia. For example, I've worked on the Python programming language article, and think it would be utterly foolish to say that Python code examples should not use that language community's traditional "spam" and "eggs" meta-variables because most programming language articles use "foo" and "bar" or "x" and "y".  At the other extreme, many commercial products (in software, or in completely unrelated areas)—or for that matter, many religions or other beliefe systems—use a set of jargon intended to create a positive impression of the product.  Wikipedia absolutely should not adopt the "feel" of the way marketers talk about their particular product (mentioning the usage, sure; but not adopting it).  I think in the end the best solution will be one suggested above: use the Eiffel-style code coloration for block examples, but use Wikipedia style for inline examples  (and make sure the unusual block example style is explained in the text).  But I'll wait for some more opinion, and check some other usages.  LotLE × talk  01:12, 22 August 2006 (UTC)


 * Bertrand, I, along with others, deeply appreciate you personally investing time in this article. Being the architect of the language there are innumerable contributions you can make. So please don't make this discussion about you. Wikipedia is about cooperation, collective ownership and shared responsibility, and its most dangerous enemy is Ego, as we see in many articles. Risking preaching to the choire, since I know you as a WP advocate, it must be said that above all Wikipedia is an encyclopedia, and characteristic for encyclopedias are on the one hand accurate representation of the subject, and on the other hand a dispassionate and to other articles stylistically consistent treatment of it. No-one here will object to the code snippets being formatted according to your doxa, but taking that into the article text is not "stylistic accomodation", it is, as has been shown, confusing, idiosyncratic and disparate. You love your language and I respect you for your work; I and many wikiminions love wikipedia and I wish you would respect us for our dilligence. Also, since you desire to produce an article of scientific caliber, then why are you surprised at receiving peer review? What separates Wikipedia articles from paper ones is that here you get immediate feedback while the article is written. As for submitting to stylistic regulations, that should hardly be something new. My psychology articles have been written to the APA (American Psychologist Association) standard, from which any significant deviations are criticised. You know that when submitting articles to journals they must generally be written to that journals' specifications. Conforming to rigid standards is something I personally dislike but is a battle not worth fighting because the message can principally be made regardless of form. The alternative here is entrenched battle and the Eiffel article suffering, which really seems quite unnecessary since we are on the same side here... Mikademus 09:06, 22 August 2006 (UTC)


 * I'm a little uncomfortable with departing from the house Wikipedia style for code samples. But I think it'd be a reasonable compromise to retain colored text in the block samples, while sticking to black text for inline samples. --Allan McInnes (talk) 19:47, 22 August 2006 (UTC)

Data points
Looking at "the rest of the world" I find ( LotLE × talk ):


 * The FAQ for the GNU SmartEiffel project at http://smarteiffel.loria.fr/wiki/en/index.php/FAQ does not use blue for either inline or block examples, but simply  and  in the code extract above or below.)


 * Please give due consideration to any editors who know and practice Eiffel. This is really only a page about a programming language and it doesn't need to become a battlefield about Wikipedia principles. Substance should prevail.


 * There is still a lot to add and improve in this article; please help. In particular my additions have not had enough proofreading; there must be typos and inauspicious phrasings.


 * I don't think I have cancelled any edit of substance made recently, but if I inadvertently have please accept my apologies and fix the problem.

The present section will have to be moved elsewhere (in fact it would be good if the whole discussion were eventually removed from this page, which should be devoted to talking about how best to describe the language) but I would really appreciate if you left it as it is, since it explains my view as completely as I could express it, and used a separate section for any further discussion of this topic.

B-Meyer 00:11, 7 September 2006 (UTC)

Requested move
WP:BOLDly move article name per consensus at: Wikipedia talk:WikiProject Programming languages/Renaming poll. Bye bye transclusion.

Stomping on other editor's work
Unfortunately, now that I've taken a look at what Bertrand Meyer has added back, I see he almost entirely destroyed the work I put into the article after he stomped out (and destructively blanked stuff repeatedly, earning himself a 3RR block). In particular, even apart from the font issue that he continues to refuse to discuss cooperatively, he also removed all my improvments to tone to try to meet NPOV and encyclopedic style. The result being that the article looks like... well, like an article that suffers badly from WP:AUTO violations. It is altogether too exuberant in tone, reading something like an advertisement for Eiffel rather than like an encyclopedia article on the language.

I'm quite frustrated by this. Quite honestly, even without the additional material that could be helpful, I think the last version of the article before Meyer came back was quite a bit better than the latest version with his changes. However, I'm nearly certain that if I try to improve anything, including restoring my own not-insignificant efforts, Meyer will play a similar game of either mass-deletion, or edit-warring, or make a new round of spurious claims not to have seen the GFDL release. At this point, I think he just has no place editing this particular article, he simply cannot approach it with the necessary objectivity, detachment, and especially not with the needed understanding that Wikipedia is based on cooperation.

Before I launch some more formal effort to prevent Meyer's edits, can someone of more optimistic spirit suggest a way this article can move forward despite Meyer's involvement. I'm not really sure what the formal procedure might be. I suppose a user conduct RfC is possible, but those are awkward and rarely productive. Maybe a WP:ANI request, but those also tend to fizzle. Possibly something with the mediation committee. Or just try to get an editor to block based on WP:AUTO violation. I honestly don't want to do that sort of thing, but seeing all the inappropriate tone (and jarring fonts, of course) reinserted just makes me cringe (because I care about the encyclopedia, and not particularly about this particular programming language). LotLE × talk 02:00, 7 September 2006 (UTC)


 * Just calm down. I am not aware of having removed any of your edits. I added a section that wasn't there (apart from one subsection on agents). If I have made a mistake, please correct it, or point me to it and I will do the correction (but this may not be the most effective way to proceed since I won't be much available in the next few days). And stop accusing me of imaginary evils past and future.


 * How can you say that a version that didn't say a word about what characterizes Eiffel -- features, Design by Contract, inheritance, conversions, genericity etc. etc. -- is better than the latest version?


 * Earlier you were upset that I removed some material; now if I understand you properly you are upset that I put it back. I don't quite understand.


 * For the record: until I and another editor started working on this page earlier this summer, it said nothing about the language. We added a detailed section on language mechanisms, so that the page actually describes Eiffel. Everything else is a figment of your imagination. If you feel that at some place I have been over-enthusiastic (although I don't know of any such occurrence), just make the correction you feel appropriate and get over it. There is no need for the pathos. Thanks. B-Meyer 02:22, 7 September 2006 (UTC)
 * I think it'd be more constructive Dr Meyer, if you let others write the article. And then review it here, tell them where it went wrong, what needs to be embellished etc.  I really don't see what's wrong with having the fonts blue/bold if the language dictates that it is useful, it's better to be accurate then for it to look consistent with  other pages.  Because if both parties are editing this article in their own ways, then it's going to go to shit. - Hahnch  e  n 02:39, 7 September 2006 (UTC)


 * I see that "Lulu" has started editing the text and restoring his earlier changes that were unintentionally cancelled as a result of the change of fonts in the agents subsection. I was going to do it, but thank you very much for taking care of it so quickly. Let me point out that as far as I can tell there is no disagreement with other recent editors on the substance of the text, and that if you see an unwarranted cancellation of an earlier edit it is most likely the result of a mistake B-Meyer 05:44, 7 September 2006 (UTC)

Quick poll on typographic conventions
Past debate has occurred on the best typographic conventions to use in this article. In a nutshell, documentation produced by Eiffel Software and other parties documenting Eiffel generally uses a set of conventions for color (mostly blue), boldface, and italics in the visual presentation of code samples. In contrast, Wikipedia conventions (as indicated by most programming-related articles) use a simple ). Also, it is bad pedagogics because it throws of normal text flow. There are very simple reasons that text books not to laborate with colours in mid-text. Mikademus 06:54, 7 September 2006 (UTC)
 * Best way would be to apply the "Eiffel style in code blocks, Wikipedia style in blocks" scenario, as it leaves the Wikipedia text unformatted. Code blocks are OK on Eiffel style. ≈ jossi ≈ t &bull; @ 19:45, 7 September 2006 (UTC)
 * I have not done lots of editing on wikipedia yet, but I am familiar with software engineering (including Eiffel) and typography. As a user I was puzzled with the inline blue fonts (I expect links to be blue). I hear that one of the reasons why Lulu wanted all the standard typographic editing was to make it easier to edit for beginners, right? Looking at the source, I do not understand, why using the font tag with the color argument also alters the face to italic when using uppercase only. Personnally, I find it best to read if the words appear in Eiffel style (except for the color) inline, while code snippets are completely in Eiffel style --Masche 08:11, 11 September 2006 (UTC)

Eiffel style (no color) in code blocks

 * I agree with Lambiam. While it would be good, in principle, to use Eiffel style conventions wherever possible, I agree that the blue text colour, particularly in inline text, can be confused too easily with Wikilinks. That, however, only represents an argument against the use of blue text. My understanding is that if colour is unavailable as an option, then it is reasonable to default to black text according to the standard. Given the potential confusion of blue text, perhaps it is best to assume colour is, essentially, unavailable, and default back to black text with all the other style conventions remaining. As Lambian said, this deals with most of the objections of both sides. I would also point out that this is hardly jarring given that it would be similar to pseudocode according to Wikipedia style guidelines in Algorithms_on_Wikipedia. Leland McInnes 18:55, 8 September 2006 (UTC)

Wikipedia (partially implicit) style guidelines in code blocks

 * Beyond the general jarringness of encountering a non-standard convention in one particular programming language article, I found additional difficulties when I began to edit code blocks marked in the "Eiffel style". A lot of extra markup goes into those conventions, making code samples extremely fragile for editors to modify without disturbing markup features (often in ways that produce dramatically bad results).  Non-editing readers will not see this issue, but allowing easy collaboration (rather than implied "invariant" sections) is an important principle of Wikipedia.  LotLE × talk  03:01, 7 September 2006 (UTC)
 * Besides the reasons above there is no official standard for the font. Yes, the ECMA standard does recommend the typographic conventions discussed but it is not an official enforced standard. If an implementation's IDE would not be considered compliant because they changed the color of the text then it would be a standard. There are unofficial standards for many languages. Should the Java article (and all articles that feature Java code) be rewritten using the same font as Sun's documents? Likewise, should all the C code (and there's tons of it) be rewritten using the "One True Brace Style" (which has been recommended by standards groups just like Eiffel's conventions)? I don't think anyone would seriously advocate any of the previous notions, hence, I believe that enforcing the stylistic recommendations over the current Wikipedia de facto standard is inappropriate in this case. - DNewhall 05:59, 7 September 2006 (UTC)

What value does the blue color add?

 * Like every other programmer I understand the value of syntax highlighting - keywords in one color, variables in another, separators in third... That's really useful. But highlighting all the code with just one color doesn't make sense to me. It's just as good as not highlighting it at all. The black-text codeblocks stand out just fine, there's no need to add extra emphasis with bright blue color. If I look at the page, the codeblocks are like screaming: "Look at me! I'm codeblock!". Marking the keywords in boldface is fine, but the blue color has absolutely no meaning. Admit it. Nene 13:07, 1 December 2006 (UTC)


 * The principe of using blue typeface for code is that all code, including inline code referring to variables in the previous codeblock, or keywords, or feature calls etc. can then be easily distinguished as code. Note that the emphasis here is on inline code being easily distinguishable from text. Because of the poor quality compromise that this article has taken the end result is moot. Code blocks being blue serves little purpose if inline code is left alone. Consistency of style differentiating it from text is the aim. I agree that it is not served here. I suggest using black text evrywhere and reserving bold and italic text for code to help distinguish it. Leland McInnes 18:12, 1 December 2006 (UTC)

Eiffel style with color in inline code

 * I definitely think that we should use the colour guidelines as laid out by the standard, especially in the code boxes. These are not as jarring as the inline code samples, and if you're going to edit the code blocks, you should know what you're doing anyway.  Wikipedia is for the reader first, the editor second.  It's better for it to be accurate than for a less accurate easy-edit version.  For me, this stems down to Wiki is not paper, Wikipedia is not bound by the costs of colour ink, colour is trivial, Wikipedia should take advantage of this fact. - Hahnch  e  n 03:13, 7 September 2006 (UTC)
 * I think Eiffel code must be made to look like Eiffel code looks. Otherwise the article trivializes it to just another code syntax and misses a key point of its purpose and design.  Make it blue, etc. Dicklyon 05:43, 7 September 2006 (UTC)
 * I tend to prefer this option, this way the article is more illustrative -- Twi light 03:38, 8 September 2006 (UTC)
 * Me too. There are the following precedents on Wikipedia for using each language's preferred convention (although not with color): Algol 60, Simula, Algol W, Pascal (programming language). Anyone know of others? Fuchsias 03:38, 9 September 2006 (UTC)
 * if there is a standard resp. recommendation, i'd rather go with the standard. --ThurnerRupert 21:18, 24 September 2006 (UTC)

Eiffel style about bold/italics, but no color in inline code

 * Use the Eiffel conventions for inline code except for the colour. Example: "In the below code block, the   called   has a feature called , which is usually used as an entry-point for the class."   I think this is better than "Eiffel style in code blocks, Wikipedia style in paragraph text" and takes away most of the objections against both "Wikipedia style everywhere" and "Eiffel style everywhere". --Lambiam Talk  06:00, 8 September 2006 (UTC)
 * I agree with Lambiam. While it would be good, in principle, to use Eiffel style conventions wherever possible, I agree that the blue text colour, particularly in inline text, can be confused too easily with Wikilinks. That, however, only represents an argument against the use of blue text. My understanding is that if colour is unavailable as an option, then it is reasonable to default to black text according to the standard. Given the potential confusion of blue text, perhaps it is best to assume colour is, essentially, unavailable, and default back to black text with all the other style conventions remaining. As Lambian said, this deals with most of the objections of both sides. I would also point out that this is hardly jarring given that it would be similar to pseudocode according to Wikipedia style guidelines in Algorithms_on_Wikipedia. Leland McInnes 18:55, 8 September 2006 (UTC)
 * I would be more than happy to use this convention, if it is general consensus. Color is the part I find the most jarring, italics and boldface are farily neutral (this is enforced by the fact that ital/bold have built-in wiki markup, where color needs to drop to HTML).  It still makes modifying examples slightly harder, but not too badly.  LotLE × talk  19:45, 8 September 2006 (UTC)
 * I have not done lots of editing on wikipedia yet, but I am familiar with software engineering (including Eiffel) and typography. As a user I was puzzled with the inline blue fonts (I expect links to be blue). I hear that one of the reasons why Lulu wanted all the standard typographic editing was to make it easier to edit for beginners, right? Looking at the source, I do not understand, why using the font tag with the color argument also alters the face to italic when using uppercase only. Personnally, I find it best to read if the words appear in Eiffel style (except for the color) inline, while code snippets are completely in Eiffel style --Masche 08:11, 11 September 2006 (UTC)
 * —Ruud 13:06, 16 September 2006 (UTC)

Use generic fixed-font for inline code

 * This should satisfy all parties, and was my original suggestion at the beginning of the entire debacle. On the one hand it allows the example code the appearance of "normal" Eiffel code, on the other hand it will not mar the discussion. Of specific significance is that blue text in the body text is confusing in a hypertext context because it is easily mistaken for hyperlinks, even if in code-tags (f.i. this occurs in several C++ articles: ). Also, it is bad pedagogics because it throws of normal text flow. There are very simple reasons that text books not to laborate with colours in mid-text. Mikademus 06:54, 7 September 2006 (UTC)
 * Best way would be to apply the "Eiffel style in code blocks, Wikipedia style in blocks" scenario, as it leaves the Wikipedia text unformatted. Code blocks are OK on Eiffel style. ≈ jossi ≈ t &bull; @ 19:45, 7 September 2006 (UTC)
 * Beyond the general jarringness of encountering a non-standard convention in one particular programming language article, I found additional difficulties when I began to edit code blocks marked in the "Eiffel style". A lot of extra markup goes into those conventions, making code samples extremely fragile for editors to modify without disturbing markup features (often in ways that produce dramatically bad results).  Non-editing readers will not see this issue, but allowing easy collaboration (rather than implied "invariant" sections) is an important principle of Wikipedia.  LotLE × talk  03:01, 7 September 2006 (UTC)
 * Besides the reasons above there is no official standard for the font. Yes, the ECMA standard does recommend the typographic conventions discussed but it is not an official enforced standard. If an implementation's IDE would not be considered compliant because they changed the color of the text then it would be a standard. There are unofficial standards for many languages. Should the Java article (and all articles that feature Java code) be rewritten using the same font as Sun's documents? Likewise, should all the C code (and there's tons of it) be rewritten using the "One True Brace Style" (which has been recommended by standards groups just like Eiffel's conventions)? I don't think anyone would seriously advocate any of the previous notions, hence, I believe that enforcing the stylistic recommendations over the current Wikipedia de facto standard is inappropriate in this case. - DNewhall 05:59, 7 September 2006 (UTC)
 * I would be fine with this too. - Hahnch e  n 03:13, 7 September 2006 (UTC)
 * I'd be fine with this. I use emacs when writing Eiffel programs. Having code in blue makes it difficult to make a complete article in Wikipedia style. I think the main article should be shorter and details moved to subtopics, which could be expanded. Epiteo 03:51, 29 October 2006 (UTC)

Examples
To illustrate the proposed stylistic conventions, each is presented below.

Wikipedia style everywhere: In the below code block, the  called   has a feature called , which is usually used as an entry-point for the class:

class HELLO_WORLD create make feature make do        io.put_string ("Hello, world!") io.put_new_line end end

Eiffel style in code blocks, Wikipedia style in paragraph text: In the below code block, the  called   has a feature called , which is usually used as an entry-point for the class:

class HELLO_WORLD create make feature make do io.put_string ("Hello, world!") io.put_new_line end end

Eiffel style everywhere: In the below code block, the  called   has a feature called , which is usually used as an entry-point for the class:

class HELLO_WORLD create make feature make do io.put_string ("Hello, world!") io.put_new_line end end

Eiffel style everywhere, less colour: In the below code block, the  called   has a feature called , which is usually used as an entry-point for the class:

class HELLO_WORLD create make feature make do io.put_string ("Hello, world!") io.put_new_line end end

Eiffel style everywhere, colour in code blocks only : In the below code block, the  called   has a feature called , which is usually used as an entry-point for the class: class HELLO_WORLD create make feature make do io.put_string ("Hello, world!") io.put_new_line end end


 * guys: I can't follow the long baroque discussion about formatting.
 * is this what your are looking for? :
 * the source/syntaxhighlight label has many parameters, just decide which ones to use and be consistent in their use. Please do not format directly the program text, otherwise it would be useless for copying and pasting to try it with an Eiffel compiler.
 * the source/syntaxhighlight label has many parameters, just decide which ones to use and be consistent in their use. Please do not format directly the program text, otherwise it would be useless for copying and pasting to try it with an Eiffel compiler.

Discussion
An additional problem, to my mind, with using syntax highlighted code (even in code blocks) is that it tends to mislead readers who may be unclear at first exactly where the highlighting comes from, and whether it is required to make code compile/execute. I.e. do I need to use a custom IDE to manually mark keywords as such, in order to create or run Eiffel code? In my personal world, the most common way I look at code is something like:

% cat hello.e class HELLO_WORLD create make feature make is      do          io.put_string ("Hello, world!") io.put_new_line end end

I never see any special highlights or non-standard console color, even when I look at completely compilable source code files. Now obviously, if I were to use specific IDEs or programming editors, I might see the "Eiffel style" markup features (or I might see other ones, depending on what syntax highlighting features I chose). Picking something non-generic and IDE-specific draws readers into thinking a non-essential feature is an actual part of the language syntax (albeit a moderate amount of potential confusion). LotLE × talk 19:56, 7 September 2006 (UTC)


 * To carry the example of the confused reader "I.e. do I need to use a custom IDE to manually mark keywords as such, in order to create or run Eiffel code?" to its logical conclusion, we should probably remove the indentation so that the mentioned reader does not wonder "Do I need to indent manually indent blocks of code in order to create or run Eiffel code?"

something like: class HELLO_WORLD create make feature make is do io.put_string ("Hello, world!") io.put_new_line end end

or

class HELLO_WORLD create make feature make is do io.put_string ("Hello, world!") io.put_new_line end end

75.30.203.153 06:57, 9 September 2006 (UTC)


 * Agreed - it's unreasonable to try to cater for, to me, a misunderstanding so silly as to be only an academic exercise. Removing colour from the code purely to avoid the case where a user assumes the colouring is somehow part of the syntax is akin to handing out rubber knives and forks at a restaurant to stop people accidentally stabbing themselves.

Destynova 01:24, 3 November 2007 (UTC)

WP:AUTO
I would kindly request from Mr. Meyer to allow others to edit the article. Mr. Meyer can provide guidance via the talk page, and limit his direct editing to correcting mistaken or out-of-date facts only. ≈ jossi ≈ t &bull; @ 03:09, 7 September 2006 (UTC)


 * I dont agree, this article is not about Dr. Meyer, and in no way can be considered a biografy or an autobiografy. This article is about a programming language, and nobody can illustrare it better than its creator. -- Twi light 03:49, 8 September 2006 (UTC)


 * Why don't you read the policy. --Ideogram 04:16, 8 September 2006 (UTC)


 * Because the policy makes no sense, and blatantly promotes stupidity. 128.135.99.80 22:58, 1 November 2006 (UTC)
 * Agree! Agree! Agree!, more over a policy is not a rigid rule just a guide, flexibility is a quality of policies. People can use their criteria to apply policies!

Trying again with Dr. Meyer
Dr. Meyer, despite everything I have said, I do welcome you back and I am glad you are making another effort to work with us, even if you are not perfect. I apologize for all my nasty and intemperate statements and ask you to pretend they never happened, but there are two overwhelming factual points that I will not let you ignore:


 * 1) Wikipedia is run by consensus and you must be willing to discuss any edits you wish to make.
 * 2) The GFDL (that's GNU Free Documentation License) cannot be revoked on your whim.

Thank you, and I will now leave you in peace and let you work. --Ideogram 05:49, 7 September 2006 (UTC)

Once routines
There is a mismatch between the current text and its examples. The text suggests the do is replaced by once, but the sample reads:

shared_object: SOME_TYPE do      create Result.make (args) -- This creates the object and returns a reference to it through 'Result' end

Should this be:

shared_object: SOME_TYPE once create Result.make (args) -- This creates the object and returns a reference to it through 'Result' end

Can someone clear up the conflict between description and code sample? LotLE × talk 06:15, 7 September 2006 (UTC)


 * You are correct. Also, the keyword is after SOME_TYPE is missing, which I have added now. MoA)gnome 15:01, 11 September 2006 (UTC)


 * The keyword is is no longer required by the standard. 83.79.215.69 11:43, 7 July 2007 (UTC)

keyword is & ECMA 367
Thanks for adding these. Oddly, all the code samples with the missing "is" seem to have been written by Bertand Meyer. What's up with that? Does Eiffel allow some syntax variant, or something? LotLE × talk 15:50, 11 September 2006 (UTC)


 * As I've found out now, leaving out is seems to be a quite new standard ; the current version 5.6 of the EiffelStudio IDE does not support it, but obviously, 5.7 will. Same thing goes for the Tuple, as it is described in the article, it won't work in 5.6. Somebody decide about having it there or not (or maybe mentioning it explicitly), but make sure to keep it consistent.... MoA)gnome 17:14, 11 September 2006 (UTC)

I've just removed one of these again, so I thought I would mention it here again: the keyword is in the feature declaration is, according to the ECMA-367 standard mentioned in the text and listed on the links, not part of the Eiffel syntax any more. MoA)gnome 11:46, 6 October 2006 (UTC)

Page vandalized again
Well, it seems someone (apparently Mr. "Lulu" if I read the history right) went surreptitiously (no comment in the history) through the whole material and destroyed all the font conventions -- all of them, not only color. All this without any discussion (in fact the comments expressed on this topic were mostly for retaining all the conventions.) The resulting text does not look like Eiffel; it violates all the typesetting rules of the language.

This is sheer vandalism and this person should be barred from editing the article any further.

All this makes Wikipedia look terrible -- Usenet at its worst. I am powerless to try to instill some civilized behavior here, but perhaps someone else will have the courage take over. Too bad, it could have been fun. B-Meyer 18:38, 7 September 2006 (UTC)


 * But there are colours in the "style" header. Isn't that sufficient to indicate the preferred presentation of standard Eiffel code? When re-reading the article, after your post, above, nothing about it struck me as "terrible" --note that I am not an Eiffel practitioner-- and the separate header for normal style was informative without breaking the encyclopaedic convention. Or am I missing something here? Because I hope there must have been some significantly nefarious editing going on for someone to cry "vandalism" and "ban the witch!". Mikademus 18:49, 7 September 2006 (UTC)


 * I am an Eiffel practitioner. Nobody I've ever met cares about the official Eiffel Font Conventions™ except Meyer.  He's being inexcusably stubborn and rude on this point.   --Doradus 16:47, 8 September 2006 (UTC)


 * If or when consensus is reached to use a non-standard style convention for this article, despite the rather glaring contrast with other PL articles, I will happily defer to such consensus. That's why I created the above "Quick poll" to gauge sentiment" (given that the prior reams of discussion were inconclusive, and excessively rancorous). But unless such agreement is reached, using the "standard Wikipedia convention" is really the only reasonable action.  As Mikademus indicates, I took the trouble of adding an example using the "Eiffel convention" so that readers could see it, and tried to integrate that well with the narrative text about style conventions.  If you think some other code sample would illustrate more conventions, I'd be more than happy to use such an expanded example.


 * Do we really need the ongoing almost hysterical accusations and insults from Bertrand Meyer? This seems awfully close to WP:NPA violation to accompany the WP:AUTO violations (especially following on all the "idiot mob rule" stuff from before).


 * And what's the weird thing with the scare quotes around my username? Not that four ticks actually harms me, but it seems peculiar... is this some sort of "discovery" that my birth-certificate didn't actually read "Lulu of the Lotus-Eaters" (I've actually used that name for about 14 years now, in various fora, and it's pretty simple to figure out roughly what my birth certificate did say... and notably, if one were to stand on ceremony as "Dr. Meyer" insists on, my honorific is 'Dr.' not 'Mr.' LotLE × talk  19:08, 7 September 2006 (UTC)


 * I really think you should have waited the result of the poll you have created, before taking any action related to style conventions. The bitter reaction of B-Mayer is fully justified IMHO. -- Twi light 03:42, 8 September 2006 (UTC)


 * The sequence of edits has just about no resemblance to Meyer's description of it. I was restoring a large number of wording improvements that he had removed, and did so only after he said "go ahead and restore" on this talk page.  His "vandalism" foolishness is just another example of his belief that he "owns" the WP article because he created the language that is its topic.  LotLE × talk  04:26, 8 September 2006 (UTC)


 * Do you know what vandalism is? How about large-scale removal of previously contributed material?  --Ideogram 04:18, 8 September 2006 (UTC)


 * For anyone thinking that the accusation of vandalism is in any way founded in reality, please reread Vandalism. Vandalism should only be claimed when you can no longer assume good faith.  Blanking is vandalism, bold edits are not.  I find it hard to view changing the font to the common font style used on WP and otherwise leaving the samples intact as "large-scale removal".  The poll is underway, but until it is completed where's the harm in having the article adhere as closely as possible to common WP style conventions?   -- Isogolem 21:33, 8 September 2006 (UTC)


 * Just to clarify, my comment was in response to Twilight, not Lulu. The "large-scale removal" I was referring to was Meyer's attempt to withdraw his contributions, not Lulu's edits.  --Ideogram 03:54, 9 September 2006 (UTC)

I am Eiffel agnostic, and do not have specific POV on ths subject. Can someone explain what is the contention about the "font conventions"? Please provide Diffs for the different versions. Thanks. ≈ jossi ≈ t &bull; @ 19:15, 7 September 2006 (UTC)


 * I added samples of the three basic proposed style conventions at the above quick poll. LotLE × talk  19:29, 7 September 2006 (UTC)

Why WP:AUTO matters
This is all so silly that I probably should not respond, but in the interest of openness, and to close my part: (1) I don't know where you get the idea that I care about titles next to my name -- I don't give a hoot, call me whatever you like. I am not sure how you want to be called, so "Mr." seemed a generic form of respect. (2) I do care about substance, and don't understand why you find it so crucial to spend your time removing again and again the carefully prepared style conventions of Eiffel, apparently as a kind of preemptive more since it's so much more difficult to restore them later than it would have been to leave them as they are and then remove them if that's the consensus view. (3) All the accusations of autobiography etc. make no sense; this article existed for 5 years (five years!) before I came anywhere close to it, and I simply made it factual; describing how Eiffel handles inheritance or object creation has nothing to do with autobiography. (4) The allegations of personal involvement are just as groundless; I took it upon myself to add to this article what it should have had in the first place, a matter-of-fact description of the language; there has not been any biased of self-serving element, and anyone who thinks he has spotted one can just fix it, like anything else, by editing the page. (5) It's true that it takes some guts to post under one's own name, especially if that name is known in the corresponding community; but I decided that using a pseudonym, like most of the people who have hampered the development of this article, would just be devious. The result is that I have been hooted down not because of what I wrote (with which no one found any serious problem, other than typos or other minor points) but because of who I am. There's this prejudice that because I have been involved with the language I should not be permitted to contribute to the description. This is absurd and discriminatory. I wrote descriptions of language mechanisms because no one else had done it and as a result the article was deficient in its presentation of the language (it was mostly expressions of various POVs). (6) Obviously a few people determined to make a point, Usenet style, have more time than I do, and I am happy to leave them the last word. What no one can deny is that even though the article is far from perfect -- not just because the font conventions are wrong -- it is much better than when a couple of other people and I started working on it (just see the record of what it was only seven weeks ago). That's what counts, and it means that I haven't completely wasted my time. I hope that others, perhaps with names less likely to attract the attention of the censors, will continue that work, and wish everyone good luck, with my thanks for what I have learned in the experience. B-Meyer 12:02, 8 September 2006 (UTC)


 * With "I have been hooted down not because of what I wrote (with which no one found any serious problem, other than typos or other minor points) but because of who I am." you're twisting the sequence of events horribly as well as adding a substantial self-serving and self-aggandising bias to the debate. No-one opposed your edits, regardless of who you were, until you started ignoring the concerns of several editors, started acting autocratically, and finally claimed all wikipedians a "proudly ignorant mob". Then, and only then, did the debate turn to being about you and WP:AUTO et ál started being invoked by commentors. Mikademus 15:02, 8 September 2006 (UTC)


 * Call me whatever you like. 'Dr. Lulu' has a nice sound to it, but lots of things are equally fine.  Like you, my well-known "real name" is perfectly apparent too (it occurs within the first few words on my user page; and takes no particular bravery or chutzpah to reveal; FWIW, it seems I'm "half as famous as Meyer" :-): ).  Meyer's above note tends to emphasize why WP:AUTO really is an important concern.  This isn't about rules-lawyering (yes, "autobiography" on WP is clearly not limited to biography as such; no, Meyer didn't create the article).  Let's get to the real problem, and why it relates to WP:AUTO...


 * Like Jossi and some others, I am entirely agnostic about Eiffel; I have have no great knowledge or investment in the language, but I have known for a number of years its general structure and the ways it differs from other similar languages. I really only stumbled across the article because of a slightly-too-exuberant couple sentences about it someone inserted into Functional programming, which is an article I had contributed to significantly (though again, a topic about which I am pretty agnostic).  The first thing that struck me upon reading the article as it was then was, indeed, how very jarring the idiosyncratic font conventions were in a Wikipedia article; and I indeed politely asked about that on the talk page (having seen some prior comments to the same effect there).  My perspective is one of a Wikipedia reader and editor, not one of a dedicated Eiffel proponent and enthusiast.  The garish color certainly harms the article from that perspective


 * Now that I've gotten around to really editing the article, I see quite a lot of problems that pretty closely tie in to Meyer's role in writing it. I don't want to do a forensic analysis of exactly which word was added by whom.  But the overall tone is really quite a bit off for a Wikipedia article.  There are three general categories of problems that most strike me, all closely connected to this:


 * 1) The article reads much too much like advocacy.  Rather than say that Eiffel does things such-and-such way, it tended (before my cleanup, more still needed) to argue why such-and-such is the right way to do it, and why other PLs are wrong to do it otherwise.  And even where it wasn't per se "Eiffel is better", there were altogether too many circumlocutions into the thinking of the designers (i.e. Meyer) in chosing such-and-such.  A general section on "design goals/philosophy" is useful, but not a reiteration of that when discussing each dot and tittle, as it had.
 * 2) The article reads much too much like a tutorial.  It's easy to write tutorials, and some other PL articles fall into this trap to varying extents.  But that assumes the wrong perspective for readership.  Meyer (and advocates generally) start with the assumption the reader comes in with: "I want to learn Eiffel, what do I need to know?"  For the most part, that's the wrong readership of an encyclopedia.  Instead, they come in with: "I want to understand (a) What Eiffel is (i.e. a PL, one which has certain principles and strengths, etc); (b) How Eiffel differs from other PLs; (c) The history, tools, community, etc. that surrounds the PL".  Readers should most certainly be pointed to other resources, such as actual tutorials on a PL.  But an encyclopedia article isn't the right place to learn a programming language... it's the place to learn about a PL.
 * 3) The article jumped much too quickly into the specific lingo of Eiffel without providing context and bearings for readers who are likely to be familiar with other PLs.  For example, before I added it, there was not even a mention of the fact that what Eiffel calls a "feature" is often called a "method" in other PLs.  Similarly for many other terms and phrases.


 * In the interest of accuracy: a "feature" in Eiffel does not correspond to what is called a "method" in Smalltalk and subsequent languages. Features cover both "routines" (the closer equivalent to "methods", or "functions" in C++) and "attributes" ("instance variables" in Smalltalk, sometimes called otherwise, e.g "field", in other languages). I guess that if you want a word in a more widely used language it's "member". The reason for the importance of the word "feature" in Eiffel is the "Uniform Access Principle" which implies that you cannot distinguish functions from attributes from the outside, i.e. in "a.a_feature", a_feature could be a function or an attribute and the other class can use it without knowing which. Perhaps you could correct this. Fuchsias 03:32, 9 September 2006 (UTC)


 * Or to put it all in a phrase: WP:AUTO matters. LotLE × talk  15:37, 8 September 2006 (UTC)

Meyer points to an old version at in the above thread. I'm not sure if that's the exact version before his contributions, or what. But looking at it, I'm quite struck by what a nice tidy article it was then. It's not really clear to me whether that 7-week ago version was better than the current one, but it certainly avoids a lot of the pitfalls of the current WP:AUTO version, and was a very clear and well-written overview of the language at a conceptual level. I do think it's better to move forward with trimming down the newer additions, and working for NPOV in them; but it's quite striking how wrong the claims of prior deficiency in the article are: I really encourage editors to glance at that pre-Meyer version. What the older one was not, of course, was an Eiffel tutorial; which is exactly what a WP article should not be. I don't think the article is big enough to spin off an "Eiffel syntax" child (we did that at Python), but I encourage editors to keep in mind letting readers get the conceptual parts as close to the top of the article as possible, while postpoining syntax details until later (I just moved "background" up to this purpose). LotLE × talk 16:37, 8 September 2006 (UTC)

I would argue that the article is way too long and reads more as an how-to than an encyclopedic article. See for examples C++, a widely used language. I would suggest to trim the article to a compact size, explain the overall concepts of the language, and provide some references for any assertions that require it. All other text could be moved to Wikibooks. Tag added. ≈ jossi ≈ t &bull; @ 19:51, 8 September 2006 (UTC)

What's wrong with language font conventions?
I see two articles on programming languages with examples using specific fonts in accordance with the respective language conventions (keywords in boldface): Simula and Algol 60. It's not clear why this can't apply to Eiffel as well. Fuchsias 03:18, 9 September 2006 (UTC)


 * These two examples make use of bold and italics, but neither use any special color. Just a data point. If you'd like to participate in the Quick Poll about this, I'm sure that would be helpful, Fuchsias. LotLE × talk  03:21, 9 September 2006 (UTC)


 * I understand color is more controversial, but didn't you remove all boldface and italics as well?Fuchsias 03:35, 9 September 2006 (UTC)
 * One more: Pascal (programming language) uses bold keywords. What's all the fuss about?Fuchsias 03:49, 9 September 2006 (UTC)


 * I didn't remove any typography at all, at least not in the way Meyer claims. I copied some sections over from the "scratch pad" draft that a few editors used while the article was protected, in order to get my wording improvements back in place (as Meyer requested I do on the talk page!).  Nonetheless, what we have now is clearly the "Wikipedia default", so absent some consensus to do otherwise, it's the right thing.  FWIW, I thought about how I might automatically add highlighting to code samples should such consensus emerge.  I found a keyword list, and the whole thing would take less that 20 lines of code to do automatically.  So bellyaching about the huge effort that might be involved in adding highlights is rubbish... I'll write a script in 15 minutes, and run it in 5 seconds.  LotLE × talk  04:15, 9 September 2006 (UTC)

Just found another example: Algol W uses underlining. More evidence that elsewhere having each language article follow the language's own conventions doesn't seem to have bothered anyone. Fuchsias 03:34, 9 September 2006 (UTC)


 * Note that no-one has contended the use of Eiffel-specific code formatting in the code sample blocks. It is formatting of inline code (code in the article text) that is controversial and inadvisable for many reasons. So the articles you've listed are, unfortunatly beside the point; notice that none of them uses language-idiosyncratic formatting of inlined code. Mikademus 09:16, 9 September 2006 (UTC)


 * Please note the quick poll above: A number of editors have stated a preference against using Eiffel conventions in code blocks, in some cases only against the color convention. But certainly, a larger number of editors dislike inlined code highlighting.  LotLE × talk  14:49, 9 September 2006 (UTC)


 * I meant that during the flurry of Meyer's edits, before the real atagonism arose, no-one was intransigent about colours in the code boxblocks. Mikademus 17:35, 9 September 2006 (UTC)


 * Which, I think, leaves the best compromise position as being that of using font conventions everywhere without use of colour anywhere. This removes the primary complaint with regard to font conventions for inline code - that it becomes confused with Wikilinks, and removes the primary complaint with regard to removal of font conventions - that keywords, variables, etc. referenced inline in the text are clearly referencing code, are more readable, and consistent in style with their reference point in code blocks.
 * It strikes me that this is an easy solution. Clearly if we can have readability and consistency without creating confusion then we should do that. Leland McInnes 21:05, 9 September 2006 (UTC)

FTR, the Wikipedia manual of style is very clear on the use of color -- namely, don't do it. - Keith D. Tyler &para; (AMA) 18:34, 19 September 2006 (UTC)


 * I read the use of color as very clearly stating: "Using color ALONE to convey information (color coding) should not be done. ... It is certainly desirable to use color as an aid for those who can see it, but the information should still be accessible without it." 75.5.175.149 02:34, 20 September 2006 (UTC)

Adding boldface to keywords
Here's the 15 lines necessary to highlight all the keywords in the Wikitext:

import sys kws = ''' alias all and as check class create debug deferred do else elseif end ensure expanded export external feature from frozen if implies indexing infix inherit inspect invariant is like local loop not obsolete old once or prefix redefine rename require rescue retry select separate then undefine until variant when xor'''.split fname = sys.argv[1] wikitext = open(fname).readlines for line in wikitext: if line.startswith(' '): for kw in kws: line = line.replace(" %s" % kw," %s" % kw) print line,
 * 1) !/usr/bin/python

If I have the keywords wrong, let me know to fix it. I'm not really sure what the rule is for where italics go (the article doesn't really say clearly), but presumably if I did it would be easy to add to the simple scaffolding. LotLE × talk 04:44, 9 September 2006 (UTC)


 * Please note that such a script will also only cover codeblocks, and not inline code. There is also, as you note, the issue of italics. Leland McInnes 05:53, 9 September 2006 (UTC)

authors intention not important?
if the author thinks the typesetting is important, why not leave it as such? if you really write code in eiffel, you anyway use an editor and set your style to your own preferences. imo wikipedia tries to give an authentic picture and is not "your personal text editor". one paragraph at the end hinting at that is just blowing up an already long article.

also python uses a special kind of indention ... but contrary to eiffel the python compiler enforces it. currently the article sometimes does not get the indention right - comp. http://se.ethz.ch/~meyer/publications/online/eiffel/basic.html.

is there a place to vote about such things in en.wikipedia.org?

--ThurnerRupert 05:22, 19 September 2006 (UTC)

Bold and italic font conventions
I think we have, at this point, at least a rough consensus for bold and italic Eiffel font conventions to be used throughout the article (inline, and in codeblocks). Colour, whether restricted to codeblocks or not, seems to still be somewhat cntroversial, so let's leave that aside for now. Barring no further complaints in response to this I will, sometime in the next week or so, try and go through the article and apply bold/italic font conventions wherever appropriate. Leland McInnes 05:47, 20 September 2006 (UTC)


 * i tried to re-order the poll and separate out a vote for code block, and for inline code.
 * it seems to be a clear vote for eiffel standard with color in code blocks.
 * for inline code i do not know how to interpret the vote. it seems quite even for all three options. if we take away the color then wikipedia style looses. --ThurnerRupert 22:02, 24 September 2006 (UTC)


 * No, there's not. The way things work is that the editor with the most time (or sockpuppet friends) wins.  If you don't like it, fork Wikipedia; it's Free. 128.135.99.80 23:05, 1 November 2006 (UTC)

Font conventions (again)
Another possible approach to handlign syntax conventions has become available. Wikipedia now supports GeSHi, which provides automated syntax highlighting by use of

However, if we were to convert the page to using GeSHi option   if that makes sense.
 * I don't know if you already had noticed that. This discussion is so long that I forgot what other point I wanted to write about.

No instructions, advice, or how-to
I removed Thumperward's "how-to" marker, as I do not see where it applies. Please provide a specific example or more detailed critizism. Thanks. --Schoelle (talk) 15:42, 20 December 2007 (UTC)

Introductory sentences are promotional, not NPOV
The introductory paragraph reads like marketing copy.. Since efficient development, reliability, and extensibility are generally considered virtues, and object-oriented programming is widely seen as a road to these qualities, all this introduction says is that Eiffel is designed to be a good object-oriented language. The way the first paragraph reads now, it seems to say, "Eiffel is designed to get object oriented languages right, which is demonstrated by its use in academia and in all of these different applications, and you even have a wide choice of tools to use!" It is only in the second paragraph that the article gets around to discussing the specific principles that distinguish Eiffel from other languages.

The introduction should describe what makes Eiffel objectively different, and anything that is said about how good it is needs to be backed up by citations to published and peer-reviewed studies that demonstrate using Eiffel leads to measurably better results than using some other specific choices that could be made. Only then are such statements NPOV. What we have here instead sounds like bandwagon marketing tactics don't cut it (ironic, since according to Tiobe Software's Programming Community Index, Eiffel is not even in the top 50 programming languages).
 * popularity is not a way to judge the good quality of a language. Many OO languages are very bad designed. Eiffel, was designed with a more formally rigorous approach, I don't care if the majority of programmers ignore what a precondition is, preferring languages more easy to learn for the laymen, those with no types, and a lot of traps to fall.


 * Eiffel has a good design because it gives no rope to programmer for hanging himself. And has features which were added just recently to those more popular OO languages, which I wont mention to avoid a religious discussion with their fans.
 * I hate OO languages because they distorted many concepts. For example, encapsulation, in many OO languages the objects are parametrized changing internal constants. That violate the information hiding principle.
 * Nevertheless, I am interested to learn about Eiffel, because contrary to many of the other OO counterparts, seems a well designed language, Because it is designed for good software engineering practices, like design by contract. It is not in the top list of popularity, but had positively influenced both other programming languages and the programming practice.
 * It may sound publicity to you, but it is not.   — Preceding unsigned comment added by 2806:106E:B:EB8A:5812:FFA3:1BF4:BDDD (talk) 03:34, 4 June 2021 (UTC)

Unless there are objections which need to be worked through, I will soon rewrite the first sentence to "Eiffel is an ISO-standardized, general-purpose object-oriented programming language," move the rest of the paragraph to the end of the section into a paragraph just above the contents, and continue the first paragraph with the second paragraph. --—C. V. Hyphus\talk 04:16, 25 April 2011 (UTC)
 * ✅ --Cyber cobra (talk) 05:28, 25 April 2011 (UTC)

When appeared?
Infobox says 1986; text says "Since 1985, many suppliers have developed Eiffel programming environments". Any better sources? 192.12.12.178 (talk) 02:24, 2 March 2010 (UTC)
 * ✅ in the info block to the web page mentioning the history of the language. Alexander (Sasha) (talk) 09:06, 24 August 2017 (UTC)

Missing File Extension
Can someone who knows Eiffel add the file extension used by its components. Thanks. — Preceding unsigned comment added by 189.209.111.39 (talk) 22:49, 7 May 2015 (UTC)
 * ✅ to the language template block. Alexander (Sasha) (talk) 08:48, 24 August 2017 (UTC)