Talk:Eiffel (programming language)/Archive 1

message: 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)
thread_title:  Bias 

message: 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)
thread_title:  Thrown away Principles? 

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

message: It's been a week and there's been no discussion by the "Pro-Bertrand" parties and there's a new draft to replace the current article that they haven't commented on. Does the page still need to be protected? - DNewhall 21:10, 28 August 2006 (UTC)
replies: text: I would suggest copying the material we believe to be useful in the /Expanded draft into the article section-by-section, rather than simply all at once.  While the previous contributions were generally excellent, there are a few tone issues that I'd like to work on as we expand the article.  In particular, while the degree of detail is very strong, there is somewhat of an advocacy tone that I'd like to move in a better NPOV direction. Thoughts? LotLE×talk 01:36, 29 August 2006 (UTC)

text: I've started at more concretely re-expanding the article.  The first thing I notice here is that while the "scratchpad" version has a lot of good content, this is a good opportunity to greatly reduce the amount of "peacock language" in the description, and also to trim descriptions to more concise and precise phrasings.  Most programming language articles have, naturally, been written by their enthusiasts; but the tone should not make that fact overly obvious.  None of the draft langauge is bad, but as you we copy over material, let's keep NPOV prominently in mind. LotLE×talk 04:41, 29 August 2006 (UTC)
replies: text: A few things that you took out that might have been too much were the SmartEiffel differences and the "Hello, world" example. The SmartEiffel differences are very important because SmartEiffel is a very notable implementation and it isn't standard and the "Hello, world" code example is canonical to every programming language article. - DNewhall 18:00, 29 August 2006 (UTC)
replies: text:  You are correct - the Wikipedia c, perl, pascal, simula, logo, and basic articles all have a "Hello World" section (although the lisp article doesn't).  I'll add it back in. 144.189.5.201 18:11, 29 August 2006 (UTC)

text:  OK.  I'm not crazy about the Hello World, and a lot of languages don't do it (Python, R, S-Plus are a few I've looked at recently).  But a bunch do, so that's fine... I moved it to a more relevant section, closer to the top and in the overall "Syntax and semantics" section.  The SmartEiffel section just feels wrong; definitely SmartEiffel should be linked to, but specific differences from the Eiffel Software version should be discussed in its own article.  But mostly it just felt like the tone sounded like advertising for Eiffel Software, i.e. "SmartEiffel isn't as good as our version". LotLE×talk 20:11, 29 August 2006 (UTC)
thread_title:  Post-protection 

message: As the editor everyone is pointing to as the "bad guy" here I feel the need to weigh in.  In my defense let me point out that my first response to Dr. Meyer was excruciatingly polite.  But there is a point to made here, aside from all the histrionics, and that is that WIKIPEDIA IS RUN BY CONSENSUS AND NOT BY DR. MEYER.  Dr. Meyer was INSULTED that we even TRIED TO DISCUSS THE MATTER.  Then he tried to invalidate the GFDL, further showing that he has no respect for anything and he only wants his way.
I happen to have dealt with Dr. Meyer before, and so my store of patience was not as great.  But you are all missing the point.  No amount of patience would have been enough to deal with Meyer, because he wants his way and that's all he wants.
Dr. Meyer doesn't compromise.  He doesn't discuss.  That's why he doesn't belong here.  All of you defending Dr. Meyer and criticizing our already careful handling of him do not understand that the Wikipedia community is more important than any one article.  It's not about fonts, for christ's sake, it's about being willing to discuss.  Nothing you can say will change the fact that Meyer was a rude, arrogant, selfish, spoiled child.  --Ideogram 07:09, 6 September 2006 (UTC)
thread_title:  September Meyer exit thread 

message: ==== Eiffel color/font in code blocks ====
*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 Meta:Wiki is not paper, Wikipedia is not bound by the costs of colour ink, colour is trivial, Wikipedia should take advantage of this fact. - Hahnchen 03:13, 7 September 2006 (UTC)
replies: text: 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)
thread_title:  Code Blocks 

message: *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 Meta:Wiki is not paper, Wikipedia is not bound by the costs of colour ink, colour is trivial, Wikipedia should take advantage of this fact. - Hahnchen 03:13, 7 September 2006 (UTC)
thread_title:  Eiffel color/font in code blocks 

message: *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 Wikipedia:Algorithms_on_Wikipedia. Leland McInnes 18:55, 8 September 2006 (UTC)
thread_title:  Eiffel style (no color) in code blocks 

message: * 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)
thread_title:  Wikipedia (partially implicit) style guidelines in code blocks 

message: * 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)
replies: text: 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)
thread_title:  What value does the blue color add? 

message: ==== 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 Meta:Wiki is not paper, Wikipedia is not bound by the costs of colour ink, colour is trivial, Wikipedia should take advantage of this fact. - Hahnchen 03:13, 7 September 2006 (UTC)
thread_title:  Inline Code 

message: *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 Meta:Wiki is not paper, Wikipedia is not bound by the costs of colour ink, colour is trivial, Wikipedia should take advantage of this fact. - Hahnchen 03:13, 7 September 2006 (UTC)
thread_title:  Eiffel style with color in inline code 

message: *Use the Eiffel conventions for inline code except for the colour. Example:  "In the below code block, the class called HELLO_WORLD has a feature called make, 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". --LambiamTalk 06:00, 8 September 2006 (UTC)
thread_title:  Eiffel style about bold/italics, but no color in inline code 

message: *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: #include <iostream>). 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)
thread_title:  Use generic fixed-font for inline code 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Discussion 

message: 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:
# Wikipedia is run by consensus and you must be willing to discuss any edits you wish to make.
# 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)
thread_title:  Trying again with Dr. Meyer 

message: 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)
replies: text: 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)
replies: text: The keyword is is no longer required by the standard. 83.79.215.69 11:43, 7 July 2007 (UTC)
thread_title:  Once routines 

message: 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)
replies: text: 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)
thread_title:  keyword ''is'' & ECMA 367 

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

#!/usr/bin/python
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,

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)
replies: text: 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)
thread_title:  Adding boldface to keywords 

message: 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)
thread_title:  authors intention not important? 

message: 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)
thread_title:  No instructions, advice, or how-to 

message: 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)
replies: text: --Cybercobra (talk) 05:28, 25 April 2011 (UTC)
thread_title: Introductory sentences are promotional, not NPOV

message: 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)
replies: text: in the info block to the web page mentioning the history of the language. Alexander (Sasha) (talk) 09:06, 24 August 2017 (UTC)
thread_title: When appeared?

message: 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)
replies: text: to the language template block. Alexander (Sasha) (talk) 08:48, 24 August 2017 (UTC)
thread_title:  Missing File Extension