9
$\begingroup$

Asking this here as it was suggested here. As the highest voted answer said, this is better question for PLDI's meta. So here we are.

$\endgroup$
1

3 Answers 3

18
$\begingroup$

I think we should err on the side of being inclusive, and focus on the issue of relevance instead of trying to draw a hard boundary.


Beliefs vary about what constitutes a programming language. Of course, I have my own opinions about this. Anecdotally, I find that programmers at large tend to be more conservative about it than programming language developers. But regardless, a contentious question isn’t suitable as a standard for what we deem on-topic.

So instead of asking:

Is this question about a programming language?

Which invites debate about what a programming language is, I propose that we ask:

Is this question about the practice of programming language development?

In other words, I think we can find more common ground, and thus a more predictable standard, by setting aside whatever we think a PL is, and assessing only whether a question is relevant to PL development, and whether PL development techniques would inform a useful answer.


Here are a few examples (positive and negative) for illustration.

Some might not consider a text-based data interchange format or markup language such as JSON, Markdown, or CSS to be a programming language, on the grounds that they aren’t generally meant to encode computations. Even if in principle they could do so, they’re intended for static data.

However, if someone is designing such a format, they may have questions about parsing, typechecking, error reporting, and usability design, which are nevertheless on topic, since they’re agnostic to the issue of whether JSON &c. are PLs.

On the other hand, a similar binary data file format might be considered off-topic if it’s not meant for humans to edit directly.

Similarly, special-purpose notations that do express computations—such as a database query language like SQL, or a spreadsheet formula language like Excel—might not be considered programming languages on the grounds that they’re not Turing-complete. (Or, again, even if they are, this is incidental to their primary intended purpose.)

Yet there’s a great deal of PL literature that is relevant to questions pertaining to query-planning optimisation, proof search, logic programming, and language usability for non-experts; therefore such languages would also be considered on-topic.

Whereas, the design and implementation of database and spreadsheet data structures would generally be considered off-topic, unless they were relevant for another reason.

$\endgroup$
10
$\begingroup$

I agree with Jon Purdy's answer that we should be inclusive, but I want to be a bit stronger than that and add a couple of categories.

Visual languages

Not all programming languages are textual: there are many visual languages that are just as much programming languages, and that have their own overlapping set of design and implementation issues. Node-and-wire systems ike LabVIEW or Unreal Blueprints, block-based systems like Scratch, purely image-based systems like Piet, and systems using layout itself to express computation are also programming languages.

Data transfer languages

Languages like JSON, YAML, and XML may not directly have a huge number of interesting questions to ask about them, but merely revolving around one of these should not make a question off-topic. A question about the causes and implications of the "Norway problem" in YAML should be allowed, while "how do I load JSON in Python?" shouldn't be; these are distinctions of the core of the task being about the language design, rather than what the language itself is, which isn't relevant.

Less-traveled language paradigms

There is a whole world of language paradigms out there, and it's easy to cut out everything that isn't fundamentally an imperative or at most pure-functional realisation of the von Neumann architecture. Declarative languages are also programming languages — yes, including SQL and CSS — as are dataflow and self-reactive systems, and there are all sorts of others too. We should be careful not to define out interesting languages just because they don't resemble the "better C" or "better ML" that so many languages aim to be.


I have one final point I want to note: "Is <x> a programming language?" is clearly a relevant question to the scope of this site, and so we need to have an answer to it, but outside of that context it (or more often, "<x> is not a programming language, it's a <markup|data|...> language") is primarily a rhetorical cudgel used to beat and belittle practitioners of that language, or a pre-packaged trick for someone to feel smart with. The site should strongly resist allowing that sort of approach to take hold. Definitions in terms of Turing completeness (what of Agda?) or general-purpose applications (what of shader languages?) are missing the point and giving in to that.

$\endgroup$
6
$\begingroup$

For the purpose of defining what is on-topic for this site, I would say a programming language is a formal language with defined syntax and semantics. That is, there should be formal rules defining what source texts are valid in that language, and formal rules defining the meaning of each valid source text. These rules might be described in a specification document, a reference implementation, or otherwise; or they might not be described yet but it should in principle be possible to write them down.

Typically, the "meaning" will be what a program is supposed to do when it is executed, or what the result of a computation should be. But markup languages like HTML, and data description languages like JSON, also have defined meaning, in the sense that a valid HTML or JSON source text unambiguously describes some kind of structured data according to the rules of the language. I agree with Jon Purdy that it's better to err on the side of inclusivity here.

I don't think we should restrict ourselves to only languages meant to be written by humans. Questions about designing and implementing bytecode languages, for example, should absolutely be on-topic too.

$\endgroup$
5
  • $\begingroup$ You said, "For the purpose of defining what is on-topic for this site, I would say a programming language is a formal language with defined syntax and semantics." Please don't do that! Every time a method is made, an implicit language is being created. And while Martin Fowler has dreamed about language workbenches, they have yet to materialize. Forth, Factor, and other concatenative languages grow by extending the language with many DSL's. Your "formal and defined" requirements prevent discussion about these, and one language I created as well. $\endgroup$ Commented Jul 21, 2023 at 4:26
  • $\begingroup$ @MicroservicesOnDDD Yes, this definition should exclude such languages. The alternative which you propose, would allow all OO design questions that have nothing to do with programming language design or implementation, simply because designing a class in an OO language is considered by OO theorists to be a kind of language design. Whether or not that's a sound or insightful precept, it's not one that should inform what's on-topic for this site. $\endgroup$
    – kaya3
    Commented Jul 24, 2023 at 9:39
  • $\begingroup$ I do want to allow discussion about an embedded OO language, but only as it relates to extracting the de facto language into either a formalized language, or a language in which significant development has been done yet may not have a formal specification, or a de facto implemented textual language (even if not formally specified). My own not-formally-specified language was a gui-supported set-based language for querying HTML elements, so simple that it did not need a specification. $\endgroup$ Commented Jul 25, 2023 at 0:32
  • $\begingroup$ An example of a de facto textual language is colorForth, used to build a VLSI CAD tool, but the language builder made it by himself and for himself, so I don't think that there's a formal specification. But it's a serious and interesting, language. $\endgroup$ Commented Jul 25, 2023 at 0:33
  • 1
    $\begingroup$ @MicroservicesOnDDD I've edited to expand on this point. A language does not need a specification document for there to be formal rules determining the validity or meaning of programs. $\endgroup$
    – kaya3
    Commented Jul 25, 2023 at 13:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .