Talk:List of C-family programming languages
|WikiProject C/C++||(Rated List-class)|
|WikiProject Computing||(Rated List-class)|
|This page was nominated for deletion. Please review the prior discussions if you are considering re-nomination:
Narrowing list scope
- Is there any language that's not going to be added to this nonsensical list? Andy Dingley (talk) 16:35, 21 April 2015 (UTC)
- Agreed, there are some ridiculous entries on this list (eg Python); it's useful in principle, but needs a good, strict criteria for inclusion. Celtic Minstrel (talk • contribs)
Nominate for Deletion. (Again)
- The obvious one: It's an infinitely-expandable list, that we shouldn't have to burdon ourself maintaining.
- The more fundamental one: The C programming language is essentially the "model" programming language - upon which we've based all our modern programming languages and programming habbits. So compared to studying their difference, listing their alikeness is quite meaningless. (And by the scope of it, it really should be C-kingdom rather than C-family in the taxonomy)
- Support. At this point it is easier to delete this list and start over if we want one with a more limited scope. Sizeofint (talk) 17:03, 13 July 2015 (UTC)
Further reasons: It's like we breathe air every day that we don't have to make a list of different kinds of airs, while subcategorization such as smell, wind strenghth, foggieness would be useful. And if I didn't say well enought, I guess this is what I mean it's the "model" programming language.
But a little embarassing question here. How do I nominate it for deletion formally? Like, how do I put that red little tag on the page?
- Claiming that all programming languages are based on C is clearly incorrect. Any introductory languages text will disprove this. Fortran, COBOL, Basic, PL/1 and Algol all predate C. C is unrelated to functional programming languages (Lisp, Scheme, ML, Haskell, etc.), logic programming languages (Prolog), early OOP languages (Smalltalk), query languages (SQL, Datalog), assembly languages, etc. The C family of languages is certainly large, but it's nowhere close to being the "model" for all other languages. Pburka (talk) 04:09, 7 December 2015 (UTC)
- Do not support. I think a list like this is very useful, so may be it can be fixed rather than deleted. I just stumbled on it when googling for languages with C-like syntax. While this list is rugged at the edges, as others pointed out, it's pretty much what I wanted. May be we can come up with a basic ad hoc definition of "C-like syntax", and list languages which satisfy. For example, we could say they should be able to compute something (literally!) like this:
var1 = var2 - (1 - function1(var3 - 5, function1(1.2, -5.6))) * 2; /* here vars are defined variables of the same floating point type and function1 is a defined function that takes two floating point arguments and returns one floating point argument of the same type. */
- I know, it is pretty arbitrary, and it will make a distinction based solely on syntax, but it will solve the creep problem, while giving users something very informative. Me, for example, I was looking for a number of languages which share this syntax because I am trying to appraise the value of teaching basic R to math students. And looking at this list (which includes R, as it should) I am very much convinced this is a highly transferable skill. melikamp (talk) 00:21, 19 January 2016 (UTC)
- Do not support. The idea of this list is useful; it just needs a clearer (and clearly-stated) criteria for inclusion. Celtic Minstrel (talk • contribs)
scope of this article , and suggestion for adding some syntax-mimicry-columns and deeper-integration-columns to the table
I actually like this article-topic, and don't believe it needs deleting. However, it could use a cleanup, and an additional column that explicitly indicates the relationship each language has with C. Specifically:
- language X can accept inline C snippets , and compile them. C++ obviously qualifies here, but I would also consider Java JNI to qualify. It's not just the curly-brackets that link these languages.
- language X can, and has always been able to, make 'foreign' function calls to C programs, aka has bindings for C-based library-DotDLLs and/or library-DotSOs. PHP is in this subset, and to a lesser degree, python. They are designed, to a greater or lesser extent, to allow you to call out to C/C++ subroutines as an optimization technique (aka write the code in PHP first, and then speed up the most time-critical bits by rewriting them as C modules). Many parts of the core PHP library are implemented in C, from the earliest days of the language.
- language X can be compiled into C source code. PHP was *not* originally able to do this, but the facebook php compiler project now makes that possible. There are plenty of languages which are in this category at their original stages, however; rather than implement 100% of the programming-language-infrastructure-stack, the languages I'm talking about will just implement a syntax parser-slash-converter, which accepts a textfile foo.X and then spits out another machine-generated-textfile foo.C which can be compiled with regular C/C++ toolchain. Often, but not always, languages like this that become successful eventually abandon the use of C as an intermediate-language. Sometimes, but *definitely* not always, the syntax of these language-X-which-can-be-'compiled'-into-intermediate-C-source-files involves curly braces and such (this is an orthogonal question).
- language X has specific syntax-level similarities to the other C-family languages, including but not limited to the following: the use of curlies for block-delimiters, the use of ++ and -- for increment/decrement, the use of // and the older /*...*/ for comments, the use of += and *= and other arithmetical-assignment-shortcuts, the use of #keyword for preprocessing purposes, the use of argv for the top-level function in an executable, the use of myVar for array-access syntax, the use of zero-based indices for arrays... there are a ton of these, which is perhaps why the list-article seems likely to spiral out of control.
Point being, I do think there is a point to this article. Many languages attempt to imitate one or more features of C-family-syntax, so that programmers trying to use the 'new' language will see familiar constructs when they type code. Compare with the use of Java-syntax (but not Java-compatible standard libraries!) by google when they created android; they didn't re-use Java-syntax for no reason, it was to ease the transition to the new platform by giving programmers a familiar environment. However, syntax-mimicry is not the end of it. Some languages like C++ are actually backwards-compatible with C programs... and Java with JNI, plus to a lesser extent PHP with their tight integration for C-binding-based subroutines, can also be considered partially members of this group. Those languages are designed so that 1) you can still program in C/C++ if you need or want to, and 2) you can switch to the new language for most things, and then switch back to C/C++ when needed. The languages are designed to make it *easy* for programmers to use existing code they have in C/C++ (either their own or third-party-modules from the internetz or whatever). The languages are also designed to make it easy for programmers two switch back and forth between Java and C/C++ , because not only is the C-binding-JNI-stuff easy, the syntax of Java purposefully mimics the syntax of C/C++ , so the mental switchover is not *too* painful. Ditto for the way PHP tries to let you have easy C-bindings, and reasonably-similar C-like-syntax.
So, in order to make the list-article more useful to the readership, I suggest adding one or maybe two columns to the table. I'll assume two added columns, since that makes the most sense for me: one which lists superficial similarities such as the use of curlies and other syntax-things (see somewhat-more-complete list above), and a second column which lists "deeper" features that make the language C-family-friendly, like ability to 'compile' from language X into foo.C intermediate-language-output-files, or the ability of language X to contain embedded inline snippets of C/C++ code. I'd lean towards putting the ease-of-C-bindings-characteristic into the superficial-column, since almost every language has *that* feature (even ones like LISP which don't have any C-family-syntax-mimicry to speak of can make foreign funcalls to C/C++ libraries and executables). Once the two new columns have been populated, I think the languages that don't really belong here ... because the just have curlies and fail to support += and zero-based arrays and other 'standard' features of C-family-languages ... will become far more clear. 220.127.116.11 (talk) 01:23, 22 July 2015 (UTC)
This article is ridiculous in it's inclusion of languages that bear no relation to C. A block structure, such as Python does not equate to the block structure of C. Python strictly enforces indentation whereas C-family languages ignore all white space. AMPL is a modelling language not a programming language. Those two examples alone are enough to force an objective rethink about what is in or out. As for including languages that can call C routines - that is a fatuous criteria, as that capability is determined by the ABI of the target platform and the capability of the involved compilers. There is a logical fallacy in the introduction which states "The family spreads out over several programming paradigms, including procedural programming, object-oriented programming, functional programming, and generic programming, as well as having both native code and virtual machine runtime environments." No! Just because C and C++ and (nearly in every case) Java, can produce compilations that run in these spaces does not mean that everything that runs in any of these spaces is part of the family. It is a clear error in equating programming paradigms with programming languages. Further, I would point out that the reference http://cdn.oreillystatic.com/en/assets/1/event/45/Go%20Presentation.pdf should not be a Wikipedia source. It is a apostolic document, written by one of the authors of the language it propounds, whence we get a lot of unsupported assertions. The first point of call should be this interview Java Report, 5(7), July 2000 and C++ Report, 12(7), July/August 2000.
As for some of the other silly comments regarding additional inclusions - to paraphrase, "PHP can be translated to C therefore it is C like." What a joke. The concrete syntax tree of my home grown context-free grammar can be translated to C so shall we include that. C-Family means looks and smells a lot like C and none of the scripting languages included fit that criteria. Something could be written to parse "Moby Dick" into code that looks like C. It probably wouldn't compile or run but it would meet the low threshold set by some of the comments above.
And most of the other criteria and comments are mistaking "C-family" for "interoperability". No wonder the world is full of bugs with such flawed logic being written.
C, C++, Java, all authored by recognised experts in their field. PHP written by amateurs Most wiki articles on programming written by students.
Verifiable and simple criteria for inclusion
The criteria for inclusion in this list should be very simple: a language is part of the C family if and only if a reliable source has described the language as part of the C family. This is consistent with Wikipedia's core guidelines of verifiability and no original research.
Interoperability with C is irrelevant. A basis in the C specification is irrelevant. Style and choice of braces is irrelevant. Defining what it means to be part of the C family should not be our concern. The only thing we should worry about is whether reliable sources say that a language is part of the C family. Pburka (talk) 19:34, 7 December 2015 (UTC)
- That seems reasonable. Since the AFD seems to be swinging toward "no consensus", I think a purge of all un- and poorly sourced entries (which at this point is the bulk of the list) is in order. Sizeofint (talk) 19:42, 7 December 2015 (UTC)
- After my rant above this, I agree with these suggested criteria and a purge as described.
I agree completely this list needs objective criteria for inclusion, but without deciding right here what we mean by "C-family", even when we lean on "reliable" sources, it's like chasing a ghost. Above, in the deletion request, I described a syntax-based distinction, which would make this article properly a "C-syntax family" list, which is narrower in scope, but still useful (to me at least), so may be better than the pile of loosely related languages we have now. melikamp (talk) 00:28, 19 January 2016 (UTC)
I agree with Melikamp - basing inclusion on external sources is too nebulous a criteria. (I do agree with Pbruka that interoperability with C and basis in the C specification are both irrelevant concerns, though.) There needs to be some strict criteria, even if it means renaming the page, and to me, a syntax-based criteria based on the style of braces makes the most sense. If a reliable source does claim a braceless language is part of the C language family, then maybe that language could be included with a footnote, but a requirement to source every single entry seems a bit too much. Celtic Minstrel (talk • contribs)
- I'm surprised that you think reliable sources are nebulous. If we're not relying on reliable sources then we're violating core Wikipedia policies of WP:V and WP:OR. If we're making up our own definition, how will we argue that this page isn't original research? Pburka (talk) 18:02, 31 March 2016 (UTC)