Category talk:Programming Languages

Isn't this covered by Category:Solutions by Programming Language? Everything except SQL derivatves is in the solutions category. --Mwn3d 23:25, 4 December 2007 (MST)

This category, as well as SQL derivatives, should probably be merged back with the "Solutions by" category. --Short Circuit 09:33, 5 December 2007 (MST)

Maybe we could leave this category and subdivide the solutions category similarly to solutions by task and programming tasks? We're up to an awful lot of languages. It'd be nice to get some categories in for extra encyclopedic knowledge too. --Mwn3d 02:33, 28 April 2009 (UTC)

Just to say, SQL derivatves are not programming languages, just servers. (MySQL, Oracle), programming languages are PL/SQL, T-SQL and etc.

SQL should be a "standard", but it is not: dialects may exist. So as far as I know, MySQL is yes a server, but also understand an "SQL" that can be called simply "MySQL"; I don't know how it relates to PL/SQL, T-SQL and so on... However on Wikipedia I read MySQL understand a broad subset of ANSI SQL 99, as well as extensions... --ShinTakezou 11:22, 28 April 2009 (UTC)

I would be more comfortable grouping all such solutions under SQL (or perhaps PL/SQL or T-SQL) and then using the {works with} template to distinguish quirks that are specific to a particular implementation, such as MySQL. --IanOsgood 17:22, 28 April 2009 (UTC)

I like this idea too. But the dialects would have to become implementations(?) rather than languages. --Mwn3d 18:00, 28 April 2009 (UTC)

If we're going to start seriously distinguishing between dialects, I don't think we should lump them in with "implementation". Rather, Template:dialect ought to be created and used for the purpose. Different implementations can be absolutely code-compatible in the sense that each of a pair of implementations' support for a language has a one-to-one mapping with the other, with the same output. Clones and reverse engineering efforts are one place where this is strived for. When you start talking about dialects, you're explicitly making a distinction between the nature of inputs.

The only bit I'm worried about is how one draws the line between different dialects of a language and different languages. There is an SQL standard that came out in 1992, but many of today's SQL implementations which are equally compatible(No implementation that I'm aware of completely implements the standard) with that standard are incompatible with each other. I believe this is largely a result of different decisions in expressing the same syntax. (I don't like putting it that way, exactly, but consider the difference between building an SQL query for Access or MS SQL Server and building the same query for Oracle or MySQL.).

As a side-benefit, this allows us to identify language extensions as dialects of a language; Code that uses gcc extensions can be identified as using the GCC dialect of the language, while code that uses MSVC extension can be similarly categorized. the works with template is a horrible hack that resulted from needing to organize data without being able to properly define that organization. If we can obviate it without necessitating forty different templates per code example, I'd be really, really happy. --Short Circuit 18:35, 28 April 2009 (UTC)

This would mean also that all Pascal examples "working with" this or that "implementation" (gpc, FreePascal, TurboPascal...) should become dialects of...? With Pascal, the template works with sufficed, or at least so it seemed to me. Maybe SQL after all fell in the same trap? --ShinTakezou 18:51, 28 April 2009 (UTC)

I think BASIC has the same kind of thing going on. We need to work to distinguish dialects from implementations (if we want a distinction) if we want this to work. --Mwn3d 19:17, 28 April 2009 (UTC)

works with is particularly unsatisfactory to me because it provides information about a programming example without an effective way to organize that information in navigable categories. With separate dialect and implementation templates, the dialect category can be made a subcategory of the parent language, while at the same time being listed as supported by particular implementations. In this sense, one can identify C++98 as a dialect of C++, and identify which C++ implementations support the C++98 dialect. An implementation's nonstandard extensions or definition of a standard's undefined behavior (i.e. gcc C and C++ language extensions, or a Brainfuck compiler's particular interpretation of BF's rather loose standard) would count as their own dialect. (It's notable that such dialects don't necessarily have only one implementation; ActiveState Perl and the official Perl distribution, for example, both implement the same dialect of the language, as far as I'm aware.) --Short Circuit 22:09, 28 April 2009 (UTC)

Although the site contains the page 'Category:BBC_BASIC' that language does not appear on the main Programming Languages page. How can that be resolved? --Richard Russell 09:28, 15 May 2011 (UTC)