This is an old revision of this page, as edited by Ideogram (talk | contribs) at 16:39, 22 August 2006 (→Welcome to Dr. Meyer and a warning: reply to Mikademus). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Revision as of 16:39, 22 August 2006 by Ideogram (talk | contribs) (→Welcome to Dr. Meyer and a warning: reply to Mikademus)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)July 2006: this page should describe the language!
A general look at this page (end of July 2006) suggests that it is mostly written from the viewpoint of comparison to other O-O languages and that a much better job can be done of capturing the real flavor of Eiffel. For example there is an inordinate amount of space devoted to trivial matters like typesetting conventions, but almost nothing about the core of the language: mechanisms such as multiple inheritance (mentioned, but no explanation of renaming etc.), once routines, constrained genericity, conversion, agents etc. Time permitting I hope to expand the article in the next few weeks so that in the end it will give a neutral but accurate picture of what Eiffel really is, from the viewpoint of people who actually use it on a daily basis. I also hope to add a few elements about the underlying methodology, without which it's hard to understand Eiffel, and to remove statements of opinion to replace them by more factual information.
- Sounds great. I'll try to help when I can. --P3d0 12:23, 15 August 2006 (UTC)
- As you can see I have started. It will take several weeks.Fuchsias 16:45, 15 August 2006 (UTC)
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 — even C was not designed primarily for performance. Fascism is pretty over-the-top too — 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. --P3d0 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. :-) --P3d0 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. --P3d0 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 (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
- 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 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 (in the eiffel base). Momet 16:33, 17 June 2006 (UTC)
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. --P3d0 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"? --P3d0 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
computer code tag
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-<code>
style in the text. Mikademus 17:38, 20 August 2006 (UTC)
- Thanks for the advice. I am applying it at the moment (include <code>), 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 Misplaced Pages, 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
require
butrequire else
.
- The concepts of Design by Contract are central to Eiffel. The keyword in that case is no longer
- All wikipedia programming articles follow the convention of black-in-
<code>
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.Just plain, unadorned code will do in the text regardless of example formatting
. Mikademus 22:17, 21 August 2006 (UTC) - Adding another note when on the topic, every so often there are links inside code-tags, like
#include <iostream>
. Considering that, I assume you see the unreasonableness of colouring the text itself. Mikademus 22:35, 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):
- 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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages editor.
- The typographic issue is somewhere in the middle of where the content's conventions intersect with the conventions of Misplaced Pages. 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. Misplaced Pages 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 Misplaced Pages 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. Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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)
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/en/index.php/FAQ does not use blue for either inline or block examples, but simply <pre> and <code>.
- As one would probably expect, the "Invitation to Eiffel" at the Eiffel Software page uses the blue for code, including a boldface for certain keywords: http://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-00.html
- Susan Stepney's Programming language list at http://www-users.cs.york.ac.uk/susan/cyc/p/prog.htm does not use any special conventions for Eiffel rather than other languages. At that page, a large number of languages are shown in toy examples, all using just simple fixed font for code.
- Interestingly, the comp.lang.eiffel FAQ, even in the HTML version does not use blue highlights, though this document seems to have been bulk converted from a TXT version rather than really being HTML in a deep sense.
- The toy example at the Encyclopedia of Programming Languages (http://www.scriptol.org/eiffel.html) does not use blue highlights.
- The actual ECMA standard (http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-367.pdf) uses the blue convention, but also uses several others that this article does not seem to:
- 1 Symbols of BNF-E itself, such as the vertical bars | signaling a choice production, appear in black (non-bold, non-italic).
- 2 Any construct name appears in dark green (non-bold, non-italic), with a first letter in upper case, as Class.
- 3 Any component (Eiffel text element) appears in blue.
- 4 The double quote, one of Eiffel's special symbols, appears in productions as ' " ': a double quote character (blue like other Eiffel text) enclosed in two single quote characters (black since they belong to BNF-E, not Eiffel).
- 5 All other special symbols appear in double quotes, for example a comma as ",", an assignment symbol as ":=", a single quote as "'" (double quotes black, single quote blue).
- 6 Keywords and other reserved words, such as class and Result, appear in bold (blue like other Eiffel text). They do not require quotes since the conventions avoid ambiguity with construct names: Class is the name of a construct, class a keyword.
- 7 Examples of Eiffel comment text appear in non-bold, non-italic (and in blue), as -- A comment.
- 8 Other elements of Eiffel text, such as entities and feature names (including in comments) appear in non-bold italic (blue).
- 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.
Welcome to Dr. Meyer and a warning
I have long observed that brilliant innovators have difficulty joining a community. Some here may recall the Carl Hewitt case where he tried to promote his Actor model here and eventually decided to leave Misplaced Pages instead.
There is no question that Dr. Meyer is a brilliant innovator, and his contributions to the article on Eiffel are certainly welcome, provided that he can work with the community. No matter how brilliant he is, no matter how valuable his contributions, if he does not respect the community and most importantly the process of reaching consensus then he will have to go.
The characterizations of feedback to his edits as "heckling" are unfair. Experienced Misplaced Pages editors know more about Misplaced Pages conventions than Dr. Meyer does. While Dr. Meyer is of course the expert on the Eiffel programming language, he needs to recognize that he has much to learn about the Misplaced Pages way of doing things.
Brilliant innovators generally aren't humble. But working in a community requires humility. Misplaced Pages would benefit from Dr. Meyer's participation, but the Eiffel article is one out of over a million. No matter how brilliant Dr. Meyer is, if he can't take a little "heckling" he doesn't belong here.
--Ideogram 09:01, 22 August 2006 (UTC)
- You don't seem to be the kind of person who knows anything about humility. B-Meyer 15:32, 22 August 2006 (UTC)
- I tried to give you advice. You aren't listening. --Ideogram 15:50, 22 August 2006 (UTC)
- Ideogram, you do come through as unnecessarily harsh. I do agree with the principles you posit but surely there are better ways of putting it? There is a difference between being right and being confrontative about it. We still haven't seen that Meyers can't work with the community, so innocent until proven guilty, m'kay? Mikademus 16:03, 22 August 2006 (UTC)
- I would indeed feel bad if I was the one to drive Dr. Meyer away. But I did try to be polite in my warning. I called Dr. Meyer a brilliant innovator, what, half a dozen times? He seems to be offended that I suggested he needed some humility. Calling other Misplaced Pages editors "hecklers" is just unacceptable from anyone, no matter how brilliant they are.
- I don't know how better to put it. Dr. Meyer doesn't make the rules here. Experienced Misplaced Pages editors know the rules here, and if Dr. Meyer refuses to learn from them then this isn't going to work. --Ideogram 16:39, 22 August 2006 (UTC)
Yielding to the mob
This article is a disgrace. It says very little about the language; what it does say is mostly inaccurate, written by people who took a 5-minute look at Eiffel. I corresponded with a few of them who admitted they knew next to nothing about it but consider themselves Misplaced Pages vigilantes who want all the articles to look the same, and do not care about the contents.
In August 2006 I set out to write a clear, precise, factual description of the Eiffel language. I was soon heckled down by a coalition of the kind of people cited above.
I still have not come to terms with the idea that dozens of people know a technology better than the person who created it and has devoted 20 years of his life to developing it. The only analogy I can think of is "Sofia Petrovna" by Lydia Chukovskaia -- read it to understand the incoming nightmare.
This is the worst fear of the Misplaced Pages skeptics coming true: mob rule, proud of its arrogant incompetence. I will move the text to a place where it is free from interference from the vandals.
B-Meyer 15:31, 22 August 2006 (UTC)
- Goodbye and good riddance. --Ideogram 15:50, 22 August 2006 (UTC)
- Let's be nicer, Ideogram!
- Bertrand has indeed fallen into a bit of a pitfall that a lot of experts do when trying to cooperate in Wiki style on matters close to them. It's hard for newbies to fully understand WP:OWN and WP:AUTO (Dr. Meyer had a small number of contributions some months back, but essentially is a newbie since his real contributions are all in the last few days). Remember WP:BITE.
- But I absolutely do not wish Bertrand "good riddance"... I hope he takes a short break, and tries working a bit on some articles he is less close to personally. I am sure there are many topics about which he is highly knowledgeable without them being his personal creation. For example, I think the writing on Covariance and contravariance (computer science) could definitely stand improvement. Or perhaps the article on Lydia Chukovskaya could be better. After a bit of work somewhere else, I am certain Bertrand would gain a better feel of the "wiki way". And even if he decides not to work further on Misplaced Pages, Bertrand's contributions so far have been valuable, and form a great basis for further article improvement... and I thank him for these efforts. LotLE×talk 16:03, 22 August 2006 (UTC)
- Wow, that was quick arrival at the blanket definition of wikipedians as a proudly ignorant mob. It is a shame you feel that way since this means you're leaving an important first reference on Eiffel to that very mob. Frankly, the disputes on this page are nothing, and compared to the bitter battles of Academia it is lighthearted banter. Of course it must feel ankward to come to a place where one isn't given reflexive deference, but does that mean one should quit the field as soon as people fail to genuflect? Of course, there might be more to it than what's found on this talk page, but I know nothing of that, and calling what's found here "heckling" and "mob rule", especially given that no-one has interfered with the edits undertaken by Bertrand Meyers, is overdramatic in the extreme. Mikademus 16:18, 22 August 2006 (UTC)