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)