Talk:D (programming language)/Archive 1

Old discussion

"(This needs elaboration.)" has just turned into a link, the target of which has only one sentence of relevance, which says practically nothing.

OK, so it gives a lower bound for the number of languages that have been called D, but that's certainly nowhere near an adequate elaboration in my mind.

Maybe someone should start D programming language (disambiguation)....

-- Smjg 09:44, 20 Apr 2004 (UTC)

---

Wouldn't it be slightly better to use a D-specific statement in the example like foreach instead of for ?

The problem is that it won't have exactly the same output as the current example (you can't print the number of the argument unless you add an i variable somewhere and increment it each time, but that doesn't look very clean)

D allows foreach loops to be indexed, so there's no problem at all. -- Smjg 22:36, 3 Jul 2004 (UTC)

OK, I don't know D well enough :) and what do you think of my proposition then ? → SeeSchloß 20:44, 5 Jul 2004 (UTC)

Yes, we should put this in. A good code example is one that does things in the way of the language. -- Smjg 09:45, 6 Jul 2004 (UTC)

Thanks, I've replaced the for example with the foreach one. By the way it looks like the new release now has writef() and writefln(), which could give writefln ("args[", i, "] = ", arg); instead of the printf in the example, but I haven't used it yet. → SeeSchloß 21:30, 10 Jul 2004 (UTC)

The article reads like an advertisement for D

I need to learn more before I can rework it, but for starters, "archaic features" is not NPOV. --Ardonik 00:43, Jul 16, 2004 (UTC)

yes, the article ends up being an advertisement for D instead of an impartial explanation of what it is, it's history and it's capabilities. Maybe it has something to do with D being still under development and some purveyors of that language being quite active in the astroturfing department.

A complete impartial re-write of this article is needed.

Any input from a real-life D programmer would be more than welcome at this point. --[[User:Ardonik|Ardonik(talk)]] 03:23, Aug 31, 2004 (UTC)

I added the advertisement notice since:

• There's no criticism
• There are sentences like OOP is supported, of course!
• There is a list of Enhancements over C++, but many of them may or may not be considered enhancements, such as: all vars automatically initialized to 0. Some developers do NOT want them initialized to 0 since its a waste of CPU.

Unfortunately I'm not a D programmer so I'm not qualified for a rewrite :( --Swalot 22:55, 18 September 2006 (UTC)

I hope that I've cleaned up the issues you mentioned. However as for criticism, that might have to wait until v1.0 is released, which BTW is likely to be very soon. DerekP 23:42, 19 September 2006 (UTC)

Initialisation of variables is needed, becouse pointers can point to not existent objects, preventing GC from collecting. And if you Realy want not initialising, no problem: int x = void; And this is marginal (1% ?) fraction of execution time. --149.156.67.102 14:23, 25 June 2007 (UTC)

Added a "problems and controversies" section. Reviews are welcome. --80.121.25.47 11:17, 10 October 2007 (UTC)

Your ideas, noticible hidden behind anonymity, appear to be either grossly misinformed or delibrate lies. The gist of your assertion sounds like "because D does not behave as C++ does, it is self-evident that D is a flawed programming language". It simply looks like you just don't get it - D is not C++. It doesn't try to be or claim to be C++, in spite of your unsubstantiated quotation that 'D is often stated as being a "fixed and improved C++"'.

You state that D operator overloads are significantly less powerful than the C++ counterparts. What evidence do you have to justify this? How is "powerful" to be measured? I'm sure that one could simply swap 'D' and 'C++' in that statement and use it as a counter argument. You state A popular example is the opIndex but how did you measure that this was 'popular'? You then go on to say that because opIndex does not do exactly the same as C++ that it must therefore be the flawed operand. That fails to acknowledge that opIndex is deliberately designed to have a different role than C++'s multifaceted indexing operand. You imply that opIndexAssign was later added to make up for the lack of functionality in opIndex. But this is not the case and is a distortion of the truth. opIndex was designed to be the RHS action and opIndexAssign was designed to be the LHS action.

You believe that D structs are underpowered because they do not behave like classes. This position fails to see that D makes a distinct separation between classes and structs whereas C++ treats them almost as the same things. In D classes are reference types and structs are value types. They have different roles and are are meant to solve different problems.

You state associative arrays which can be implemented easily in the standard library as STL-like maps like that would be a good thing. Again, the implication is that you see that when D does things in a manner that C++ does differently, that therefore necessarily D must be in the wrong. The built-in AA functionality lowers the entry barrier for new users and it does not prevent templated maps as alternate AA implementations from being created.

You state On Windows systems, DLLs are currently not supported. Thus, writing plugins in D is currently not possible. This is just wrong. DLLs are supported. One can create DLLs and one can use DLLs. Plugins, using the DLL interface, are perfectly possible.

DerekP 04:38, 11 October 2007 (UTC)

As said, D 2.0 will introduce an opIndexLvalue operator precisely to mimic C++'s one. You can still say that this is D's way of doing things, but then you are implying that D's [] operator is less powerful than C++'s one. One of the goals of D is to recast C++ in a sane and straightforward language; deliberately castrating one of C++'s most used abilities (operator overloading) is not a smart idea. A "opIndexAddAssign" operator has been proposed for the a[i] += b; problem in the past, which is yet another short-sighted solution. Logically, an opIndex returning a *reference* automatically fixes ALL of these cases.

I know that D makes a distinct separation. But then I ask you: why can structs have methods, but not constructors? Why can't they have simple inheritance without support for vtables? They remain lightweight this way while becoming even more useful for metaprogramming.

Also, I want to know how a simple "import std.containers.map;" and "my_map["A"] = b;" raises the entry barrier.

I want to see code actually using D via DLLs. You are aware of the fact that currently, phobos is NOT a DLL, thus a DLL and a program have two different GCs, which leads to havoc? Or are you confusing them with DDL, which are something entirely different? Also, name your compiler. In case of DMD 2.x, you are using experimental software. --80.121.55.165 13:27, 11 October 2007 (UTC)

There appears to be another growing language family called D

Date & Darwen, in The Third Manifesto, propose a category of pure-relational database languages called D. Their example language is called Tutorial D, and there appear to be a number of implementations already under development. For one, see: http://dbappbuilder.sourceforge.net/Rel.html —FOo 04:01, 23 Sep 2004 (UTC)

Proposed or possible

"Proposed or possible" successors to C++ is redundant. I'm going to change it back to just "proposed."

Babel

I've added D to the Wikipedia:Babel project. Feel free to put it in your babelbox! -- Smjg 09:33, 27 October 2005 (UTC)

when created?

When was it designed? 71.96.234.140 04:20, 27 April 2006 (UTC)

Perhaps in 2001, based on this post from August 2001 being the earliest one there. The earliest version of D I can find mention of in the changelog was from September 2002. –Tifego^(t) _{04:35, 27 April 2006 (UTC)}

However, if you mean when was it initially thought of, this might apply: "D was conceived in December 1999 by Walter Bright as a reengineering of C and C++". –Tifego^(t) _{04:38, 27 April 2006 (UTC)}

Example 3

It's not clear in the comment which portions of Example 3 are or aren't part of C++ already. I don't know D at all, so could somebody clarify? matt kane's brain 13:50, 5 May 2006 (UTC)

D does not "extend" C++

To say that D extends C++ implies that D is C++ with more features. That's just wrong. Infact, that's the opposite of the spirit of D.

D does not "extend" C++; D re-engineers C++ in a better way. D is a modern language that combines the robustness of modern languages (like Java and C#) with the power and features of C/C++.

Hmmmmmm, ... mmmm?? At least this container/dictionary stuff is somewhat original for the C-family proper. I'm not quite sure what D does, but it reworks the C-family of language by incorporating constructions of minimalist alternative "interpretations" (in linguists' sense). If the classes per default are non-virtual (statically allocked), then the nearest language is C++; however, if the classes are virtual (dynallocked), then the nearest language is in fact Objective C. I think D is developed from the C-family using experiences from C, C++, Objective C, Java, C-sharp and some other inspirations. To be more precise than that is to provide an erroneous image. Said: Rursus ☺ ★ 09:28, 14 June 2007 (UTC)

Sorry, I think I spake balderdash! What I meant was that dynamical method lookup (by default) implies a nearer relationship with Obj-C, and statical same C++. Either way D is a general reelaboration on the basis of C-related PL:s, not more precize than that. Said: Rursus ☺ ★ 13:47, 14 June 2007 (UTC)

The current version is ...

There is no indication of the current version of either the compiler (or the tools). This information would be useful in determining how "ready is D for prime time." 24.188.206.103 00:56, 13 July 2006 (UTC)Cacofonix

—The preceding unsigned comment was added by 209.89.183.89 (talk • contribs) .

So fix the article matt kane's brain 21:31, 12 June 2006 (UTC)

DTrace

The DTrace kernel tracing mechanism uses a "scripting language" also called "D", that appears to be a different language than the one covered in this article. I think there should be at least some mention of it, as DTrace is probably more current as a topic than this "older" language. More info on dtrace can be found [[1]], as well as some [code]. --Booch 06:35, 8 November 2006 (UTC)

Requested move

D programming language → D (programming language) – Conformance with WP naming conventions atanamir

The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was move as outlined. -- tariqabjotu 02:43, 7 September 2006 (UTC)

Note: This poll has been transcluded onto the talk pages of a number of individual programming languages, but is in fact a subpage of Wikipedia talk:WikiProject Programming languages. When you comment, please note that this survey is for multiple programming languages, not just the one you saw it on.

Some editors have proposed a general rename of articles named with the pattern "FOO programming language" to the pattern "FOO (programming language)". Please note that this poll only is applicable to those programming languages whose names alone would introduce ambiguity. For example, programming languages such as Java and C , whose names alone are ambiguous, would be at Java (programming language) and C (programming language), respectively. Unique names such as Fortran and COBOL, should remain at their respective simple names.

For instructions on how to add a poll participation request to additional applicable article talk pages, please see: Wikipedia talk:WikiProject Programming languages#Poll procedure

Please add "* Support" or "* Oppose" followed by an optional brief explanation, then sign your opinion with ~~~~

Voting

• Abstain Support - I initially abstained because I just wanted to get a procedure rolling. Looking at the first few comment, I support the rename. As with other editor, I only want this where ambiguity exists in the name: e.g. for "Python" but not for "Perl". Also, something like "Python programming language" would still redirect to "Python (programming language)" under the proposal, so existing links would not break. LotLE×talk 22:32, 1 September 2006 (UTC)
• Support - However, I would object to specifying "programming language" anywhere in the title, as parenthetic remark or not, if the name of the language itself does not have any ambiguity issues. For example C programming language should change to C (programming language) (since C is already taken), but Fortran should stay at Fortran. --Serge 23:24, 1 September 2006 (UTC)
• Support - originator of the request; it would also meet the common names policy and also meet the disambiguation guideline. atanamir 23:32, 1 September 2006 (UTC)
• Oppose. The convention has been "<name of language> programming language" for quite a while and I don't think it helps by changing it now. There are already redirects in place for "<name> (programming language)" and it would only add more work to move them all there. Also, it goes against conventions in other media. In books related to programming on the copyright page where it sometimes has sorting information for the book many books say "Computers & Internet - <name> programming language I. Title" or something similar. - DNewhall 23:32, 1 September 2006 (UTC)
• Oppose. To quote Wikipedia:Disambiguation, "When there is another word (such as Cheque instead of Check) or more complete name that is equally clear (such as Titan rocket), that should be used.". It is undeniable that the "C programming language" is a widely-understood name, not just a description. There's a reason K&R's book is called The C Programming Language rather than C, a Programming Language. Diverse examples from other areas include French language, Titan rocket, sticking plaster, bread roll, contract bridge. What makes programming languages different from these topics? Deco 23:44, 1 September 2006 (UTC)
  • If those articles were named like the programming languages are currently, they would have been something like sticking plaster dressing, bread roll food, and contract bridge card game. Titan rocket, in fact, is a redirect to Titan (rocket family). The natural languages are a slightly odd exception to the normal convention, but i'm not a linguist, and not about to argue with them. (I do know, however, that many non-English Wikipedias use the normal (parenthesized) disambiguation convention for natural languages.) --Piet Delport 13:40, 2 September 2006 (UTC)
    • Apologies for the bad example - Titan rocket was moved since it turned out to be a rocket family, but others such as Angara rocket were not. The controlling question here is whether "C programming language" is a "more complete name" for C. I argue that it is, and so standing guidelines strongly support the current name. Deco 10:12, 3 September 2006 (UTC)
      • I would argue that isn't. You can say "I play contract bridge" and "I use C", but not "I use C programming language". You can expand the names into noun phrases, as in "I play the contract bridge card game" and "I use the C programming language", but in both cases "the * card game" and "the * programming language" are not part of the name itself, anymore. --Piet Delport 06:04, 4 September 2006 (UTC)
        • The presence or absence of a leading article is not a reliable indicator of whether it's a name or not, as indicated by French language, unless you wish to expand this proposal to move X language -> X (language) as well. Deco 06:28, 4 September 2006 (UTC)
          • Definitely not something i'm interested in pursuing; let the linguists and editors involved with natural languages worry about their own naming convention. --Piet Delport 12:09, 4 September 2006 (UTC)
            • (I know I am commenting on a now old post, but...) My take on "French language" is that it's different from "C programming language" since French is the language of the French. However, "C" is not a language named after a culture, country, or people (or anything). "C" only refers to C; "French" refers to a whole lot more than a language. Also, "French" is descriptive, but "C" is not. There's no need to clarify "C" or let it modify a noun. But being that a one letter name for something is inherently ambiguous, as well as names such as "Java" or "Python" (as already mentioned), there needs to be the parenthetical, "(programming language)".
• Support - due to its name being "Ruby". --Yath 01:31, 2 September 2006 (UTC)
• Support - this is the standard way that most Wikipedia articles are named. Use the common name and disambiguate appropriately using parentheses when necessary. --Polaron | Talk 01:43, 2 September 2006 (UTC)
• Oppose - For the same reasons as DNewhall. Chris Burrows 02:11, 2 September 2006 (UTC)
• Oppose — Per Deco, I don't see how adding parentheses to an article title which is already clear is an improvement. --Craig Stuntz 02:47, 2 September 2006 (UTC)
• Support -- Crypotography has had much the same problem for some time. It has adopted the "<topic> (cryptography)" approach which has worked well. Not elegant perhaps, but ... ww 05:20, 2 September 2006 (UTC)
• Oppose — Either way, there should be a second link so that both "C (programming language)" and "C programming langage" produce the C article. My main reason for opposing is that it isn't really consistent with the new "C programming language, criticism" page that was spun off the main C article; what would that name turn into? By the way, the official standard name is "programming language C", but to me that sounds too much like "PL/C" which would be wrong. Deco's remark is quite right. — DAGwyn 07:56, 2 September 2006 (UTC)
• Comment. This proposal is different from the original proposal, found here, which is now understood as having unanimous consensus in favour. Please do not interfere with the original proposition by misrepresenting it and opening a straw poll here, which can only serve to undermine the usefulness of the original proposal. It would have been much better to simply post a link. - Samsara (talk • contribs) 09:40, 2 September 2006 (UTC)

The original proposal seems pretty wacko to me, and I don't see any evidence of a consensus. As I understand it, this current section is not a "straw poll", but a genuine attempt to determine whether or not to move the C article to a new name, independently of whether that wacko proposal is accepted. — DAGwyn 09:53, 2 September 2006 (UTC)

• Oppose - As per Deco, if syntactically correct name is enough for disambiguation, it should be preferred. And also, without parentheses it's more pythonic (readability counts). Samohyl Jan 10:24, 2 September 2006 (UTC)
• Strong Support — The current convention is at odds with the rest of Wikipedia, and as cumborsome as it would have been to have things like Quicksilver novel, Manowar band, and Darwin operating system. --Piet Delport 13:28, 2 September 2006 (UTC)
• Support. Needs disambiguating, and the name seems to be to be currently misleading. --maru (talk) contribs 19:25, 2 September 2006 (UTC)

In what way is "C programming language" misleading? I can't think of a more natural title for such an article. — DAGwyn 05:48, 4 September 2006 (UTC)

• Support. Those opposing often Some of those opposing assume that the poll is about deleting the "X programming languages" links - this is not correct. Nor is the intention to move names which are unambiguous, such as Fortran. Aaron McDaid (talk - contribs) 23:06, 2 September 2006 (UTC)
  • For the record, I do not make either of these assumptions, and continue to oppose on the stated grounds. Deco 10:10, 3 September 2006 (UTC)
    • I didn't intend to imply that there weren't other reasons for opposing. Thanks for pointing that out Deco. Aaron McDaid (talk - contribs) 10:33, 3 September 2006 (UTC)
      • Don't worry about it - I appreciate your clarification that these are not valid grounds for opposition. Deco 10:38, 3 September 2006 (UTC)
• Support per Piet Delport. — Hex (❝?!❞) 23:35, 2 September 2006 (UTC)
• Support per Hex. -- Fredrik Johansson 12:54, 3 September 2006 (UTC)
• Support per Piet Delport. – Smyth\^talk 14:33, 3 September 2006 (UTC)
• strong support. Piet Delport puts it well. Programming language articles should be disambiguated the same way that other Wikipedia articles are. — brighterorange (talk) 18:15, 4 September 2006 (UTC)
• EMPHATIC Support I've wanted this to happen for a long time now. Per Piet Delport. RN 10:34, 5 September 2006 (UTC)

Discussion

Response to DNewhall's comment

In order to reduce clutter in the voting section, i've deicded to respond to DNewhall's vote here. If you're afraid of the amount of work it would take to move the articles, I can move most of them and i'm sure there are other editors willing to take up the task. Also, most books about programming languages simply have the title or common name of the programming language as the title of the book -- the Wrox series uses "Professional PHP" or "professional Java", not "professional PHP programming language" or "professional Java programming langauge". Many of the books I have also have the sorting information as "Computers -- Programming languages -- X," where X is the programming language. atanamir 23:36, 1 September 2006 (UTC)

The main issue is not that I'm afraid of the work but that it'll be a lot of work with next to no perceived benefit. Both "Euphoria programming language" and "Euphoria (programming language)" go to the same page and I (and others apparently) fail to see how that is an improvement over the current convention. The text is exactly the same, you're just adding parentheses. No one is going to get confused about the lack of parentheses (also remember that the names with parentheses already have redirects in place). Is "<name> (programming language)" a more correct title for the article? Arguably. Is it worth the effort of moving all the pages over from their perfectly understandable title to a title that already has a redirect in place for it? No. - DNewhall 16:10, 2 September 2006 (UTC)

I think you misunderstand the point of stylistic consistency on Wikipedia. Any one article in isolation would be fine under either convention; in fact, if the project was only the one article on, e.g. "C programming language" there would be no contrast with all the other uses of parens for disambiguation. But if WP (or some subset) was prepared for print or other syndication, having relatively consistent stylistic choices helps a lot (article naming is, of course, just one small issue among many others, of course). The work involved in a rename would, obviously, be a tiny fraction of the work involved in discussing the question, so that is "vanishingly insignificant". LotLE×talk 16:42, 2 September 2006 (UTC)

When it comes to C, we need to clear and distinct names for the articles on the programming language article and for the book. C (programming language) and The C Programming Language (book) are those two names. They are unambiguous and (or is that because?) they conform with the Wikipedia standard. Anything else should be a redirect to one or disambig page to both. 'C programming language' should redirect to the language and 'C Programming Language' to the book or a disambig page. The existence of a book called 'The C Programming Language' is actually an argument in Support. Aaron McDaid (talk - contribs) 12:49, 4 September 2006 (UTC)

... Appending to own comment ... It's never referred to directly as 'C programming language'. It's always 'C' or 'the C programming language. Note the ' the '. The latter is of the form 'the X Y' where X is the name and Y is the type of object. 'the X Y' (or even 'X Y') is not a new name for the object, simply a way to refer to X where there may be some ambiguity. Aaron McDaid (talk - contribs) 13:07, 4 September 2006 (UTC)

Repsonse to Deco's comment

Imagine if you have a set of objects which all fall under the same category -- let's say they're all different types of Widgets. The types are Alboo, Kabloo, Hello, Wawoob, Baboon, Choogoo, Chimpanzee, etc. Because some will cause ambiguity -- Hello, Baboon, and Chimpanzee -- they need to be disambiguated. However, since the common name (in this case, the real name) is "Hello," "Baboon," and "Chimpanzee," wikipedia has an established precedent of using parentheses. Thus, the unique widgets, Alboo, Kabloo, Wawoob, Coogoo, can have articles simply at the name itself; but the ambiguous names should have articles at Hello (widget), Baboon (widget), and Chimpanzee (widget). Thus, the article titles will be uniform in that they are all "at" the name itself, but with a disambiguator on several of them. This is easier than making all of the articles at Alboo widget, Kabloo widget, Hello widget, etc. Also, it allows for the pipe trick, so links can easily be made with [[Hello (widget)|]] --> Hello. atanamir 23:54, 1 September 2006 (UTC)

• an example of this that's currently on wikipedia is colours. Some colours, such as Blue, Brown, and Red are at their articles, but colours like Orange (color) need the disambiguation part on them. It isn't at Orange color, althouh there is a redirect -- we can do the same thing with redirects. atanamir 23:57, 1 September 2006 (UTC)

• also, your examples -- Titan rocket is a redirect for Titan (rocket family). Your other examples do not incite ambiguity, otherwise they'd be at places like Contract bridge (card game) atanamir 00:33, 2 September 2006 (UTC)

• Titan rocket may now be a redirect, since it turned out to be a family of rockets rather than a single rocket, but there are still many rockets named that way (e.g. Angara rocket) and it's still cited on Wikipedia:Disambiguation specifically. The miniscule convenience of the pipe trick is not a reason for anything. My point is that this is a much wider concern than programming languages alone and represents a significant departure from the disambiguation guidelines. It would be radical to make such changes in a single area without raising them to the wider community, when your argument seems to apply to everything. The point of contract bridge and bread roll is that the more common names for these topics are "bridge" and "roll". Deco 07:48, 2 September 2006 (UTC)

Simpler disambiguation

Even if we add the parentheses, the guideline at Wikipedia:Disambiguation#Specific topic makes sense to me:

If there is a choice between disambiguating with a generic class or with a context, choose whichever is simpler. Use the same disambiguating phrase for other topics within the same context.

For example, "(mythology)" rather than "(mythological figure)".

In this case, we could have the simpler and more widely applicable "(computing)" instead of the long "(programming language)". --TuukkaH 10:04, 2 September 2006 (UTC)

I agree with the sentiment, but i think "(computing)" is too wide, with way too much opportunity for clashes:

• Curl versus cURL
• Curry versus Currying
• Icon versus Icon (computing)
• Leopard versus Leopard (DHT)
• Mercury versus Mercury (computer)
• Nice versus nice (Unix)
• Pico versus Pico (text editor)
• Ruby versus Ruby (hardware description language)

"(programming language)" might lean towards the long side, but i don't think any alternative class comes close to being as simultaneously large, well-defined and well-populated. --Piet Delport 15:14, 2 September 2006 (UTC)

I agree that if we were to use parentheses, "(computing)" is not specific enough. Your examples are excellent, particularly "Icon", which clashes with an already-existing article! Deco 10:40, 3 September 2006 (UTC)

Perhaps you're right in that it's not specific enough. On the other hand, the disambiguation can never be perfect as there are several programming languages that share a name: NPL has three programming languages, The Language List has four programming languages called G. What about "(language)" then? --TuukkaH 22:02, 3 September 2006 (UTC)

"Language" connotes something rather different from "programming language". "Lisp (language)" for example. "Programming language" is the accepted category in the industry, abbreviated to "PL" quite often in discussions (whereas "L" is never used for this). — DAGwyn 05:59, 4 September 2006 (UTC)

What about just "(programming)"? Or is that too ambiuguous as well? atanamir 02:39, 5 September 2006 (UTC)

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Pages like C programming language, criticism

To meet the new standard, the pages should be moved to something like Criticism of C (programming language), right? examples are Georgia (U.S. State) and Politics of Georgia (U.S. state). atanamir 02:42, 5 September 2006 (UTC)

Depends on the page in question, most likely; some would work like above, some (like C syntax) wouldn't require any changes, and some might want to use a different method to disambiguate. --Piet Delport 05:55, 5 September 2006 (UTC)

Agreed with Piet; only the ones that would incite ambiguity -- simply "Criticism of C" would have ambiguity, but "C syntax" or "Syntax of C" are both rather unambiguous and would not need change. atanamir 06:01, 5 September 2006 (UTC)

Surely, criticism of C is pretty unique and should be the article? Are there any other C's that would be criticized? Aaron McDaid (talk - contribs) 21:41, 5 September 2006 (UTC)

I agree that the most likely "C" to be criticised is the programming language, but some may be looking for a criticism of the letter or magazine. Unlikely, but possible. This decision would be left up to the community, though. atanamir 01:57, 6 September 2006 (UTC)

As of now, there is only one C that is criticized on Wikipedia, and I am not aware of anyone wanting to write an article criticizing any other Cs. Therefore, criticism of C is unique. The Wikipedia standard is to only disambiguate when necessary. That article should be moved to criticism of C at some point, but we should let this debate finish first. Aaron McDaid (talk - contribs) 09:16, 6 September 2006 (UTC)

For the record, "Criticism of C" didn't even exist until I created the redirect yesterday. Was kind of surprised because it was at that wierd, longish name and is a pretty good article :). RN 10:19, 6 September 2006 (UTC)

The C criticism article was split off from the main C article, where it had previously been embedded, in response to a requirement in order for the main C article to be designated a "Good Article". I picked the name with the idea that it was a sub-article of the main one. Once the discussion has settled, I don't object to some reasonable renaming, so long as the links between the two articles are fixed up so they still point to each other. — DAGwyn 21:51, 6 September 2006 (UTC)

Aaargh! Whoever just renamed the main C article ignored this linking issue. I have edited the C criticism article so its link to the C article does not have to redirect. — DAGwyn 20:20, 7 September 2006 (UTC)

The term "criticism" should not be used (I've stated reasons for this on Talk:C (programming language); the more accurate term of "analysis" or something similar should be used. Dysprosia 03:54, 7 September 2006 (UTC)

You also received feedback to the effect that criticism doesn't have to be negative, that the article is fairly balanced, and that a list of limitations has to seem somewhat negative no matter how well-intentioned it may be. The C criticisms article is not at all a complete analysis of the language, just a description of the many characteristics of C that have drawn reasonable criticism. Since C is so popular and wide-spread, it is a target for a lot of sniping and second-guessing, and it is undeniable that that has happened, which is part of what the C criticism article specifically addresses. One of the useful functions of the C criticism page is to bring some balance to that criticism. — DAGwyn 20:20, 7 September 2006 (UTC)

I also responded to that comment by saying (and I'll repeat the comment here for the benefit of readers of this page) that the term "criticism" still has primarily a negative connotation and that because of this it is an undesirable term. The article in question has the potential to contain discussion on design points on the language and opinions on those who comment on these design points. That is an analysis of the design of the language, and has the potential to encompass views from all points on the spectrum on the matter. Dysprosia 07:43, 8 September 2006 (UTC)

I just want to chip in that i agree with DAGwyn that "criticism" does not carry negative any primarily negative connotations in this context. As the criticism article says:

"In literary and academic contexts, the term most frequently refers to literary criticism, art criticism, or other such fields, and to scholars' attempts to understand the aesthetic object in depth."

There are certain fields ("In politics, for instance [...]") where "criticism" connotes mainly negative criticism, but it should be reasonably clear that encyclopedias won't limit themselves to that. --Piet Delport 23:32, 10 September 2006 (UTC)

Technically, it shouldn't carry any as you suggest but most seem to think it is a dumping ground for it. I would recommend "Analysis" as that's what I'm doing for criticism page I watch. RN 23:43, 10 September 2006 (UTC)

"Analysis" usually implies something more formal, complete and reductionistic, though. Is that what the article is aiming for? --Piet Delport 00:00, 11 September 2006 (UTC)

It doesn't need to imply that. The article in question however should aim to examine as many viewpoints on as many language points as possible. Dysprosia 02:33, 11 September 2006 (UTC)

Unfortunately, the C (programming language) article itself does force the negative connotation on the reader by saying "Despite its popularity, C has been widely criticized. Such criticisms fall into two broad classes: desirable operations that are too hard to achieve using unadorned C, and undesirable operations that are too easy to accidentally achieve while using C. Putting this another way, the safe, effective use of C requires more programmer skill, experience, effort, and attention to detail than is required for some other programming languages." That whole paragraph implies that the article Criticism of the C programming language is negative (why else say "Despite its popularity" and then cite two negative classes?) Mickraus 17:14, 24 January 2007 (UTC)

I'll just wait for someone else to paint the bikeshed — Preceding unsigned comment added by 121.211.204.77 (talk) 12:52, 6 July 2015 (UTC)

D influenced by C#?

Recently, C# was added to the list of influences of D (diff). However, I think that is not the case, since D got started before C# had gained a considerable momentum – I think the languages are similar since they merely have common ancestors. Any opinions? -- intgr 10:41, 13 November 2006 (UTC)

I added that because I recall discussions with Walter Bright saying things that indicated that some concepts now found in D are also found in C#. These were things not originally in D but have made their way into the current specification after being proposed for C# (3.0 from memory). I'll try to locate the discussions and post references.

Comment added by another reader: my attention was drawn to D by a recent Dr Dobbs newsletter item. Upon looking through the description of D on http://www.digitalmars.com/d/2.0/overview.html, my reaction is that D has a very large overlap with C# both in motivation and details. (I have no knowledge about who deserves credit for which features; perhaps C# & D both availed themselves of some ideas from Java.) The big difference is the aim of D to compile to machine code and to allow assembler code inline, so that it is a good candidate for systems programming. A lesser difference is D's dropping of the namespace concept. After being frustrated for some time by aspects of C++, I found C# to be a huge improvement. I expect that someone moving to D would be similarly appreciative. 64.111.150.248 (talk) 19:50, 3 February 2009 (UTC)

IDE for D available

I'm the author of Geany, a light IDE which supports the language D. Geany isn't a full-featured IDE and it's still in heavy development but it supports already D with some auto completion, folding and such things. Perhaps someone wants to add it. —The preceding unsigned comment was added by 80.144.60.98 (talk) 17:33, 8 December 2006 (UTC).

Eclipse have good support of D language via Descent plugin.

...built making the DMD compiler front end...

I'm not a native English speaker, so I probably just don't get it.

Gnu D Compiler (GDC): the GNU D Compiler, built making the DMD compiler front end and the GCC compiler back end work together.

Is it correct that Gnu D uses part of the DMD compiler? I can not find a confirmation of that. - ru:User:Saproj —The preceding unsigned comment was added by 89.106.39.140 (talk) 19:30, 15 January 2007 (UTC).

I haven't followed it for a little while, but from memory, the DMD release comes with source code for the compiler front end. DMD itself utilize the DMC compiler for the backend whose source are not release. GDC take that front end source and make it work with GCC, so yes is the answer to your question. -- KTC 17:37, 15 March 2007 (UTC)

Changes are made regularly?

There is this in the article:

D is still under development, and changes to the language are made regularly. Although the design is almost frozen, it is possible that some of these changes could break D programs written for older versions of the language and compiler.

I find this strange, because, the article mentions that D already hit 1.0. Can somebody more knowledgeable about D verify this issue? Jorge Peixoto 10:37, 15 March 2007 (UTC)

That was written prior to the 1.0 release, and nobody has just changed it yet. -- intgr 14:57, 15 March 2007 (UTC)

In the end, 1.0 was little more than a symbolic milestone. Things haven't really changed since then. -- Smjg 16:53, 15 March 2007 (UTC)

I changed the text to reflect was is in fact going on. --Mariano(t/c) 17:20, 15 March 2007 (UTC)

Examples in RGB??

OK, no trouble for me, because my color vision is virtually perfect, but there are color blindness out there. I suggest using other kind of highlight based on background and font style! Said: Rursus ☺ ★ 15:00, 14 June 2007 (UTC)

Syntax highlighting with font color is a very established practice — anything else will probably appear unnatural and distracting to programmers; even the colors (blue for keywords, red for literals, green for comments) are a de facto standard for C-like languages.

Do you really think there is a good reason to change this? -- intgr ^#%@! 10:06, 15 June 2007 (UTC)

The color scheme presently used to highlight code samples looks awful: bright red and dim yellow is not a good selection of colors to enhance readability. Also, consider the fact that in printed version of Wikipedia, the colors will most likely not be distinguished. I would propose to get rid of them alltogether, and merely mark the keywords in bold. This would suffice to highlight the syntax of the language and enhance readability without making anyone's eyes hurt. -- int19h 14:44, 23 July 2007 (UTC)

I'm inclined to agree that some of the colours make it a little harder to read, but that doesn't strike me as a reason to get rid of the colours. Perhaps better would be to pick a few colours that are easy on the eyes, and combine this colouring with other means of formatting such as bold and italics (indeed, italics are already used for comments).

Removing the colours isn't in any way going to fix the problem of some users not being able to see them. As for colour-blind people, monochrome printouts and the like, you have a point, but being able to read the code easily is much more important than seeing the code in pretty colours. Moreover, a well-chosen colour scheme will be appreciated by those of us who can see the colours, while at the same time keeping the code legible to those who can and can't distinguish the colours alike. -- Smjg 17:36, 23 July 2007 (UTC)

For the record, here is example 2 in TextPad's default colour scheme:

import std.stdio;       // for writefln()
 
int main(string[] args)   // string is a type alias for const(char)[]
{
    // Declare an associative array with string keys and
    // arrays of strings as data
    char[][] [char[]] container;
 
    // Add some people to the container and let them carry some items
    container["Anya"] ~= "scarf";
    container["Dimitri"] ~= "tickets";
    container["Anya"] ~= "puppy";
 
    // Iterate over all the persons in the container
    foreach (char[] person, char[][] items; container)
        display_item_count(person, items);
    return 0;
}
 
void display_item_count(char[] person, char[][] items)
{
    writefln(person, " is carrying ", items.length, " items.");
}

Already easier to read than what we have now IMO. Here's a slightly modified version:

import std.stdio;       // for writefln()
 
int main(string[] args)   // string is a type alias for const(char)[]
{
    // Declare an associative array with string keys and
    // arrays of strings as data
    char[][] [char[]] container;
 
    // Add some people to the container and let them carry some items
    container["Anya"] ~= "scarf";
    container["Dimitri"] ~= "tickets";
    container["Anya"] ~= "puppy";
 
    // Iterate over all the persons in the container
    foreach (char[] person, char[][] items; container)
        display_item_count(person, items);
    return 0;
}
 
void display_item_count(char[] person, char[][] items)
{
    writefln(person, " is carrying ", items.length, " items.");
}

What do you think? -- Smjg 19:58, 23 July 2007 (UTC)

Better of course, sorry for the delay in answering... Rursus dixit. (^mbork³!) 13:29, 25 January 2010 (UTC)

BTW, I realize someone have taken the color issue seriously and chosen a color scheme that is prob fairly well adapted for various kinds of color vision deficiencies. While the colors look a little "bland" for us with good color vision, it is verily worth it in order to make it visible for all. Thanks, someone! Rursus dixit. (^mbork³!) 13:35, 25 January 2010 (UTC)

Features section, comments on backwards compatibility with C

Regarding the following quote from the Features section: "D is being designed with lessons learned from practical C++ usage rather than from a theoretical perspective. It uses many C++ concepts but discards some, such as strict backwards compatibility with C source code." [My emphasis.]

Could the person who wrote it clarify their meaning here? C++ is not strictly backwards compatible with C anyway. Consider e.g. the statement,

 int *a = malloc(10*sizeof(int));

which is legitimate in C but not C++. Is the intent to mean compatibility with C system calls, or ability to link with C libraries, or is the paragraph just plain wrong? —WebDrake 18:17, 14 June 2007 (UTC)

Good point. I think the intention was to say that while D is based on the concepts and their implementation in C++, and thus C to some large degree, it is not bound to the idea of strict backwards compatibility with either C or C++. DerekP 08:03, 18 June 2007 (UTC)

Convert examples to 2.0-compatible syntax

How about converting the examples to be 2.0-compatible? This will probably involve simply replacing char[]s with strings, and will (somewhat) improve readability for those new to the language. --Vladimir 05:25, 5 July 2007 (UTC)

And how about a section explaining the differences between 1.0 and 2.0? I can't find it on the D-site itself (or I must be blind), it would make a good addition here. Jalwikip 11:59, 15 August 2007 (UTC)

No! Please revert examples to 1.0. D 2.0 is highly experimental and i don't see any good reason to put in Wikipedia. If some one is interested it can check webpage of D.—Preceding unsigned comment added by 83.19.20.122 (talk • contribs)

The string alias is not only a part of D 2.0, but also D 1.0 (added retroactively when D 2.0 was introduced). Although it was mostly added as a transition feature, it is still a standard language feature (being included in object.d), and using it in the examples will help improve readability, especially for types such as char[][][char[]] (string[][string]). However, I do agree that using 2.0-exclusive features in examples is inappropriate.-Jeff ^(talk) 04:29, 23 August 2007 (UTC)

Imperative programming with D

I strongly disagree with the claim that "imperative programming is almost identical to C". D is full of features not existing in C. An earlier section mentions features such as "design by contract, unit testing, true modules, automatic memory management (garbage collection), first class arrays, associative arrays, dynamic arrays, array slicing, nested functions, inner classes, limited form of closures, anonymous functions, compile time function execution, lazy evaluation and has a reengineered template syntax". Almost all of those features are applicable to imperative programming. So if your imperative D programs are almost identical to your C programs, that is because you have limited yourself to a subset of D which is almost identical to C.—Preceding unsigned comment added by 85.225.42.48 (talk • contribs)

Too many examples

There are presently 4 examples on this Encyclopedia page, when there probably be, at most, 1 short example. There is a Wikibook for this content, and I suggest that the examples be moved. Certainly, some direct links from an "Example" section in this article could be made directly to those examples in the Wikibook. +mt 21:46, 23 September 2007 (UTC)

I agree. Also, better examples are possible. Particularly interesting would be to show D implementations of template patterns which require a lot more work in current C++, for example patterns where static_if like functionality and variadic parameter lists are used often. --80.121.25.47 10:34, 10 October 2007 (UTC)

Yeah, I don't think anyone could argue against this. Just need someone to implement it all. -- intgr [talk] 03:11, 28 October 2007 (UTC)

I agree, there are too many examples and they are too much long. Better to add explanations of why D avoids some of the problems of C++. —Preceding unsigned comment added by 87.19.202.63 (talk) 17:17, 31 October 2007 (UTC)

Recent edits to examples and reversion thereof

87.18.200.81 (talk · contribs) made a handful of stylistic edits to the code, which Intgr (talk · contribs) mass-reverted. The summary: "revert completely unnecessary style changes".

Firstly, just because they're unnecessary doesn't make it the best course of action to revert them. Indeed, if you believe otherwise, you're stuck because reverting the edits is also unnecessary.

But really, what we should be considering isn't so much what's necessary and what isn't as what sets the best example. With that in mind, here are my thoughts on the edits:

void main versus int main

It seems silly to return a value from a function if this value's always going to be the same. As such, I generally prefer to use void main in such cases.

import std.stdio: writefln;

Self-documenting code is nice. Why add a comment to indicate which function from an imported module you're using when you can make the code speak for itself? It's a bit like how you'd write

int width;

rather than

int x;  // width

Moving display_item_count to above main

This is one where I'm inclined to prefer what it's been reverted to, since it shows a neat feature of D, namely that you can define functions in any order and not need forward declarations.

Parameter types in foreach

I'm not sure about this. Nowadays, I probably find myself omitting them about as often as not. There are probably a few competing points of view here.

Spaces between a statement/declaration and its comment

It's nice to have such comments lining up in a column to an extent. Changing it to just a single space makes it seem a bit too cluttered.

Putting some statement comments on a line of their own

I've mixed feelings about this. On one hand, having them all the same seems more consistent. On the other, it does make the layout too wide for some readers.

What does everyone else think? -- Smjg 02:09, 15 November 2007 (UTC)

I am the autor of the last little edits, I am not a vandal. I'm not an expert of Wikipedia, but I know D enough, I use it to write real code, and I post on its newsgroups regularly.

Regarding

import std.stdio: writefln;

This the right way to program in D because that's enforced by the compiler, it imports just one name instead of polluting the namespace.

Moving display_item_count to above main

some people think that putting the main at the end helps you find it faster.

Spaces between a statement/declaration and its comment

the lines of that program (that I think is too much long for a Wikipedia page) are too much wide. —Preceding unsigned comment added by 87.16.87.90 (talk)

Multiple inheritance

The sentance "C++ multiple inheritance is replaced by Java style single inheritance with interfaces and mixins." needs to be revised. Multiple inheritance and interfaces are different things. —Preceding unsigned comment added by 87.116.148.199 (talk) 20:28, 20 December 2007 (UTC)

They are different things, but the defense for not implementing multiple inheritance is always that you can achieve almost the same using interfaces.85.235.250.110 (talk) 14:04, 9 July 2008 (UTC)

Tango vs Phobos incompatibilities

Whereas there certainly are differences in Tango's and Phobos' Object (less now after Tango's last release, 0.99.4), saying that these differences cause GC problems is wrong. The only differences in Object as of today, is a couple of aliases related to strings, and the notification methods (in both cases these are absent from Tango's Object). However, Tango's Thread (especially implementation, but also API) differs quite much from Phobos'. Also, the GCs have diverged over time, but aren't incompatible beyond the fact that some may have workarounds for bugs in either. Exception hierarchies are different, and are as such usually considered among the incompatibilities. Others are generally QOI issues in the runtime. FWIW, Tango developers are in a dialogue with Walter Bright et al to bring the runtimes in Tango and Phobos closer in the 2.0 timeframe of D. What will transpire from that, is still not certain. Note that I don't want to edit the article myself, considering I'm rather biased towards both D and Tango. -- Larsivi (talk) 23:27, 23 December 2007 (UTC)

Considering this comment was added a few months ago, I'd like to know what the status is on this now. I plan on cleaning up this article soon and would like to know what kind of progress has been made towards Phobos-Tango compatibility. All I know so far is that Tango has switched over to using toString and that Phobos has incorporated some of the GC differences from Tango, is there anything I'm missing?-Jeff ^(talk) 18:31, 26 March 2008 (UTC)

Still too many examples

Currently, the examples section is over half of this article! Which examples would people be willing to part with? Whichever ones we get rid of should probably be moved to a Wikibook on D, and if there isn't one, one should probably be created.-Jeff ^(talk) 18:37, 26 March 2008 (UTC)

I removed the longest example and trimmed down two of the others, the section is still pretty long but much better. Perhaps the best course of action in the long run would be to provide brief examples of features in the article body rather than having a large examples section.-Jeff ^(talk) 02:08, 27 March 2008 (UTC)

Proposed move to "D programming language"

The current title of this article, "D (programming language)", implies that the name of the language is simply "D" and that it has no other name, however Walter Bright himself has recommended referring to the language as the "D programming language". This is mostly to help search engines find articles on the language, but I feel that given this recommendation, "D programming language" would certainly qualify as an alternate name which is unambiguous (which "D" is not). WP:NC (CN) is pretty clear on what to call the article in this case.-Jeff ^(talk) 16:17, 27 March 2008 (UTC)

The language is called D. Look on the website. "The D programming language" is just a description that's sometimes used for clarity. If this is going to be renamed "D programming language", so should the various other programming language articles in the same way. Moreover, from what I recall, the bibles of C and C++ were called "The C Programming Language" and "The C++ Programming Language" respectively; I don't think anybody took this as reflecting that the languages were named other than simply C and C++. -- Smjg (talk) 17:34, 27 March 2008 (UTC)

I guess I wasn't completely clear. I'm not saying that the language isn't referred to as "D", but that the language is referred to as the "D programming language" in addition to "D", and that "D programming language" better meets Wikipedia's common names policy in that it is the most common name that does not conflict with the name of something else. Also, I have looked on the website before, that's what gave me the idea that the more complete name is the "D programming language". As for renaming other language articles, I would support it only if a more complete name is needed for those languages and if one is available. This is why I suggested the D move. C++ on the other hand, doesn't need to be moved because it's name already conforms to WP:NC (CN).-Jeff ^(talk) 21:06, 27 March 2008 (UTC)

I think that even a casual reading if the title is enough to understand that we are talking about the programming language, rather than the letter or the vitamin. Please keep the parentheses. Blowfish (talk) 21:48, 5 April 2008 (UTC)

"D (programming language)" is just as clear as "D programming language", but the latter better meets the naming convention I linked to. Also, to add another point to this, I Google tested the name "D programming language" and all the links on the first page are for this language, and nearly all of them refer to it as the D programming language.-Jeff ^(talk) 05:03, 12 April 2008 (UTC)

I disagree with the renaming. The "(computer language)" suffix is consistent with naming of articles about C, C# and E languages. D's website calls it just D in many many places. Please remove that obnoxious "inappropriate name" template from D's article. 81.99.215.163 (talk) 23:26, 12 April 2008 (UTC)

Read my comments above. According to WP:NC (CN) we need to use the most common name that doesn't conflict with the name of something else. In other words, parentheses should only be used as a last resort if there is no common way to disambiguate a name. In this case, there is a common way to disambiguate the name "D", by using the more complete name: "D programming language". I'm not saying that this language is not called "D", but that the name "D programming language" better conforms to the common names policy. If other single-letter programming languages have an unambiguous common name, then they should probably be moved as well, I'm just focusing on this article for now.-Jeff ^(talk) 01:27, 13 April 2008 (UTC)

The problem is that you are lumping a description in with the name. D is a programming language, the name of the programming language is "D". Same with "C". C Programming Language is not the name of the programming language, C is. Considering how bad the wikipedia search is, disambiguous usages are actually the best case in this case. Though it would be amusingly redundant to the APL article retitled as APL programming language. (APL stands for A Programming Language) Judging by the discussion on this page, if you continue and retitled the article, it would be without much support and most likely be reverted. - Uselesswarrior (talk) 14:24, 24 April 2008 (UTC)

"D programming language" is a term used to refer to this language, therefore, it is just as much a name for the language as "D", at least for the purposes of the article title. Look at the title of the article bread roll, for example. Even though "bread roll" is nothing more than the real name (roll) "lumped together" with a description (bread), it is still located there and not at roll (bread). That's just how disambiguation is done per WP:NC (CN). Trust me, I went through a discussion a while back related to this same thing, and in the end we decided that the form that best meets Wikipedia's naming conventions is the form that avoids parentheses.-Jeff ^(talk) 15:54, 24 April 2008 (UTC)

Please see http://www.digitalmars.com/d/2.0/overview.html "What is D? D is a general purpose systems and applications programming language." Its name is just D (there's also a note on the site explaining the name origin). The fact that google gives you best results with "d programming language" rather than "d" is obvious. Personally, I don't care what title this article has, but I think it should be consistent with other articles, hence if we have "C (programming language)" and "C++ (programming language)" this should definitely be "D (programming language)". 87.20.68.116 (talk) 16:17, 10 May 2008 (UTC)

And yet the title of that page, as shown in the title bar, is "Overview - D programming language 2.0 - Digital Mars". The titles of other articles on the Digital Mars site also have "D programming language" in them, and my Google search proves that "D programming language" is a common enough name to use for the title of this article, so I'm proposing we change the title of this article to match this commonly used convention. I'm not proposing we change all instances of "D" in this article to "D programming language" that would be pointless as the context is already clear. All that needs to be disambiguated is the title, and this is most naturally done by using the term "D programming language", not by using parentheses. Also, as I've said before, I'm only focusing on this article for now, if it's decided that "C programming language" is a common enough name for the language, then that page should be moved as well, "C++" is fine as it is already and unambiguous name.-Jeff ^(talk) 01:29, 11 May 2008 (UTC)

Please check the FAQ too: "The original name was the Mars Programming Language. But my friends kept calling it D, and I found myself starting to call it D.". As I already noticed, the "google proof" you point out is almost totally useless: you just CAN'T search for "D" and hope to get accurate results, it is obvious that a search for "d programming language" works better. This is true for "C" too. I guess you know enough about search engines to understand what I'm talking about. As for the page title, D *is* a programming language, so I don't understand why the title should be different, considering the fact that people may still not know what "D" is. Being this a "naming convention" problem, and being a convention already in use in wikipedia (that is, with parentheses), I feel the "improper name" tag is silly and degrades the quality of the article. 80.180.164.228 (talk) 09:50, 18 May 2008 (UTC)

Wikipedia's naming convention is not to simply put parenthesis on an ambiguous title, but to disambiguate by using a clearer common name. The Google test was to show that "D programming language", a clearer name, is also a common name. Obviously it can't prove that it's a more common name than "D", but it doesn't need to. WP:NC (CN) says to use the most common name that doesn't conflict. "D" conflicts, so we shouldn't use it, but "D programming language" doesn't conflict, therefore it meets the convention. Also, I wish people would stop providing proofs that the language is called "D", I already know that, but that name does not conform to the common names convention. It's common yes, but ambiguous, and WP:NC (CN) tells us what to do in that situation.-Jeff ^(talk) 16:38, 19 May 2008 (UTC)

The name is fine the way it is. If C (programming language) and Python (programming language) work, then so does D (programming language). We have a redirect from D programming language, that will catch anybody who searches on that term. -- RoySmith (talk) 17:03, 19 May 2008 (UTC)

I disagree with the claim that "D (programming language)" is a title that violates WP's naming convention policy. I didn't find anything in that article that would indicate the parenthetical clarification is inappropriate at all, and in fact, parenthetical disambiguation seems to be the convention throughout all of WP. And, as has been stated several times, the "(programming language)" suffix is universal among virtually all programming language articles, so if we're seeking a conventional name, then "D (programming language)" would be it. Not to mention that a Google search for "d programming language" turns up the WP article on the first hit anyway (Digital Mars's D page is #2). Finally, the argument that "D programming language" is a common name is mistaken; when you have a website that is explaining what D is, it's a little awkward to just refer to it as D, since D has so many other meanings. Stating "the D programming language" helps disambiguate what the author means by "D". WP has its own method for this kind of disambiguation: parenthetical disambiguation, and this is the convention that we should stick to. This discussion has gone for two months, and so far, nobody but the OP has agreed to changing the article's title to "D programming language". I'm removing notification from the main page. Rainault (talk) 16:43, 20 May 2008 (UTC)

If "D programming language" is the name most websites use to clarify the name of the language, then I don't see why that isn't the "most common name that doesn't conflict". At the very least Wikipedia should follow that convention for the sake of consistency with other sites on this language. As for the argument that parentheses are how disambiguation is done on Wikipedia, that's both true and false. Parentheses are used if there is no other way to disambiguate a title, but if there is another way, such as a more complete/clear name, then we use that name. This is why we have bread roll not roll (bread), William C. C. Claiborne not William Claiborne (governor), Maryland Route 2 not Route 2 (Maryland), Wilmington, Delaware not Wilmington (Delaware), etc. That is how disambiguation is done per WP:NC (CN). If people are so worried about consistency with other language articles, then those articles should probably be moved as well, where applicable. I'm not sure what the more complete names for them are, the only one I can think off the top of my head would be C programming language for C considering a book with that name, referring to the language, exists. Also, the fact that someone took the time to create a redirect from C programming language to C (programming language) as well as an equivalent one for D, then it shows that these names are already considered common enough to be alternate names for the languages and should be considered as article titles.-Jeff ^(talk) 18:53, 20 May 2008 (UTC)

Oops, my apologies, I didn't realize that someone removed the "does not conflict" part from the convention I've been citing. However, Wikipedia:Disambiguation#Specific topic perfectly states what I have been saying:

For disambiguating specific topic pages, several options are available:
1. When there is another term (such as Pocket billiards instead of Pool) or more complete name that is equally clear (such as Delta rocket instead of Delta), that should be used.
2. A disambiguating word or phrase can be added in parentheses. The word or phrase in parentheses should be:

• the generic class that includes the topic (for example, Mercury (element), Seal (mammal)); or
• the subject or context to which the topic applies (for example, Union (set theory), Inflation (economics)).

3. Rarely, an adjective describing the topic can be used, but it is usually better to rephrase the title to avoid parentheses.

-Jeff ^(talk) 19:23, 20 May 2008 (UTC)

Ah, point well taken. After reading that snippet, I think I see your argument now, and I do agree that, in principle, "D programming language" is a more appropriate and conforming title than "D (programming language)". I noticed that this issue has come up before, and there was already a poll for adding the parentheses. This discussion appears to be a mirror image of a previous discussion (see the "Requested Move" section above). Given that this change has already occurred before, there's going to be a lot of inertia to getting the article titles changed back. At least that explains why the "X programming language" redirects exist now. For now, though, the consensus appears to be in favor of parenthetical disambiguation, and I have to admit, even though I agree that in principle you are right, I think that "X (programming language)" title styles feel more appropriate. In any case, I think that overall, this is a needless semantic issue. Both "X programming language" and "X (programming language)" allow for the pages to appear on the first page of a Google search, and one redirects to the other. If there were a more practical issue of concern due to the parentheses, I would be in favor of a mass title change, but for now, the parentheses should be fine where they are. There is no real disadvantage that I see to keeping them there. Rainault (talk) 20:04, 20 May 2008 (UTC)

Jeff, please have a look at the green box near the top of this page. 88.149.240.46 (talk) 12:13, 27 May 2008 (UTC)

I now realize that this was discussed before, but in that discussion the support votes seemed to be based on misunderstandings of WP:NC (CN). One person said that we should use the common name, then disambiguate with parentheses, and another said that the non-parens version is "at odds with the rest of Wikipedia". This was despite the fact that WP:NC (CN) did not say simply to use the most common name and disambiguate with parentheses, but to use the most common name that doesn't conflict, and that WP:DAB#Specific topic directly states that parentheses in article titles should be avoided. Its more important to follow these consensus-based guidelines than to simply look and see how some other articles are doing it, because those articles might be using parentheses as a last resort. The oppose votes, in my opinion, had stronger arguments, such as the very guidelines I linked to, and the fact that this is how the language names are disambiguated outside of Wikipedia. I'm going to try to put some of my thoughts about disambiguation into an essay soon, so I'll leave it at that. I also hope to take this up with WP:COMPSCI soon and see what they think about using more complete names for programming languages.-Jeff ^(talk) 16:41, 27 May 2008 (UTC)

I thought I would point out that the article was originally named D_Programming_Language and assume it changed from the vote, you can see it took place in 2006. -nascent ^(talk) 4:57, 8 March 2009 (UTC)

WP:CCC. Also, like I pointed out, that discussion seems to have been filled with people who saw parentheses used in other titles and thought that's how all disambiguation should be done. Read User:Jeff02/How we disambiguate on Wikipedia, yes it's an essay written by me, but it's based on existing Wikipedia guidelines so it's worth reading to understand how disambiguation should really be done. Probably the strongest argument of all for the move is that Walter Bright himself requested that the name "D programming language" be used to refer to the language. That certainly qualifies as a more complete name and therefore is a good alternative name for this article than simply "D", which is ambiguous and therefore requires parentheses. I don't plan on moving this article anytime soon, since there doesn't seem to be much support for the move, but if enough people do support it, I'd be happy to move it.-Jeff ^(talk) 04:48, 9 March 2009 (UTC)

Factorial

In the example about templates, sometimes "Factorial!" is written with an exclamation mark, and sometimes it isn't. Is this correct? If so, what does the exclamation mark mean? —Preceding unsigned comment added by 91.115.182.40 (talk) 19:07, 10 January 2009 (UTC)

The exclamation mark means template instantiation. Factorial is declared as a template so it has to be instantiated with the syntax Factorial!(number). The equivalent in C++ would be Factorial<number>. factorial on the other hand, is just an ordinary function so it is called using function call syntax.-Jeff ^(talk) 22:24, 10 January 2009 (UTC)

One other thing, when a template is declared, no exclamation mark is used, so that part is also correct.-Jeff ^(talk) 22:27, 10 January 2009 (UTC)

Future support

Version 2 states "Future support for pure functions which can only access immutable data and call other pure functions." It then goes on to explain what a "pure function" is, which is useful, but mostly irrelevant to this article. What it doesn't explain is what "Future support" means? Does this mean it is not currently supported by the compiler but officially part of the 2.0 spec? Does it mean this is really a version 3 feature of the language? Does it mean it is only for use writing software that enables time travel? —Preceding unsigned comment added by 74.219.122.138 (talk) 13:48, 23 January 2009 (UTC)

Now a moot issue as I understand, D2 now supports pure functions. I'll update the article.-Jeff ^(talk) 16:15, 23 January 2009 (UTC)

Software written in D?

Hi, I cannot find ANY examples of ANY *real* software written in D. Can anyone help shed some light on this? 69.181.105.239 (talk) 03:16, 27 March 2009 (UTC)

There's lots of open-source software on DSource. Some more links are here. --Vladimir (talk) 11:59, 27 March 2009 (UTC)

Difference between D and Objective-C

I'm a bit confused about the differences between these two languages. It looks to me like they are both striving to be object oriented, C-compatible, compiled languages without the complexity of C++. I suppose D provides more emphasis on compile-time correctness?

Even C++ is only mentioned a couple of times in the article. I think it would help a lot to add a comparison section to Objective-C or C++, and perhaps talk about the fundamental design decisions that distinguish all of these languages, for someone who is not so familiar with the specifics. 64.105.136.146 (talk) 07:53, 29 March 2009 (UTC)

No, unlike Objective C, D is incompatible with C; it's a completely different language. The only way to use C code in D is to compile the C code separately and write a D module that declares the functions defined in the C code (like a header file). The intro states that some features in D are completely redesigned, but maybe it should be made clearer that D code is incompatible with C code, and perhaps an example could be added to show the D-C "compatibility" that I mentioned.-Jeff ^(talk) 00:28, 30 March 2009 (UTC)

Vector operations

They are already available in D1 too, so listing them in the section about D2 is wrong. —Preceding unsigned comment added by 79.37.196.221 (talk) 20:34, 28 April 2009 (UTC)

In regards to the preprocessor section that keeps getting added

There are several problems with it, it is unreferenced, uses weasel words, uses second-person pronouns, and even contains a note to the person who has been removing it (such discussions should take place here on the talk page). I would encourage the writer of this section to try and fix these problems, but there is one last issue with this section that makes it impossible to fix; it, by its very nature is not neutral. The lack of a preprocessor is in fact cited as an advantage of D on the Digital Mars site. Anything that can be done with the C/C++ preprocessor can be done with D constructs such as enum, import, alias, and static if, except for the things that the programmer shouldn't be doing in the first place such as redefining syntax. Also the example given in the section of changing a method call into a property can already be done in D as D allows for methods to be called as properties. So it really is unfair to say that D's lack of a preprocessor is a disadvantage.-Jeff ^(talk) 17:20, 23 August 2009 (UTC)

You've taken the words out of my mouth there. 118.173.0.16 (talk · contribs) is a PCTKB, who clearly hasn't written enough D code to be in any position to judge whether D's builtins are adequate for the purpose. Even if they weren't, then without proof that the practical advantages of C's preprocessor cannot be fulfilled by adding features directly into the language, it doesn't make sense to knock a language for not having a preprocessor. At least one troll on the D newsgroups has tried this already. It's also been said about Fortran and, while I agree with most of the points made on that page, this little detail in the middle of point 7 seems to be due to the author's lack of knowledge (as one response begins to explain).

In short, you can't judge the power of a programming language by the presence or absence of a preprocessor. -- Smjg (talk) 18:50, 23 August 2009 (UTC)

Criticism?

Where has the criticism section gone? There has been several controversial features in the history of D. The whole language is constantly in development and lots of unnecessary cruft has been planned to be removed since its birth. Still, almost nothing ever happens and all reddit posts get modded down because the author seems to have no idea what e.g. higher order functions (bright vs harrop) or featuritis means. 130.232.103.149 (talk) 11:40, 24 November 2009 (UTC)

Perhaps you overlooked the still-present "Problems and controversies" section? If you're referring to some other section, it must've been removed quite a while ago (some time last year or earlier, since there was no section titled "Criticism" as of January of this year, which is as far back in the history as I cared to look). --Cybercobra (talk) 12:01, 24 November 2009 (UTC)

creation

"A stable version, 1.0, was released on January 2, 2007." -- but the D language is listed as created in 1999. Which is more accurate? Was there a specification before release on 1/2/2007? 192.12.12.178 (talk) 02:21, 2 March 2010 (UTC)