10
$\begingroup$

Especially standard library design, which is fairly related to the language itself, yet not directed related to 'language design'.

$\endgroup$

4 Answers 4

17
$\begingroup$

A standard library is part of the programming language, so yes, standard library design should be on-topic.

A non-standard library is not part of the programming language, but is added separately just like a non-library program, so no, regular library design should not be on-topic.

$\endgroup$
4
  • 3
    $\begingroup$ Non-standard libraries often inspire other languages though, such as this question, where Julia has built-in features clearly lifted from the popular Numpy library. $\endgroup$
    – kouta-kun
    Commented May 16, 2023 at 21:01
  • 4
    $\begingroup$ @kouta-kun yes, supposing that this site existed when Julia was being developed, a question from the developers of Julia about how to include a feature from Numpy in the language would be on-topic, as it is about developing Julia's standard library, not about developing Numpy. $\endgroup$
    – Someone
    Commented May 16, 2023 at 21:15
  • 1
    $\begingroup$ How's "standard" defined here? My language Rabbit has a set of "core" modules which are part of the interpreter and a larger collection of "standard" modules which are maintained by me but are otherwise normal in form; are both included, or just the core ones, or neither? $\endgroup$
    – Ginger
    Commented May 17, 2023 at 15:37
  • 1
    $\begingroup$ @Ginger are the "standard" modules typically included when Rabbit is distributed? $\endgroup$
    – Someone
    Commented May 17, 2023 at 16:07
4
$\begingroup$

Some library designs are in effect internal domain-specific languages, or even further. These should be on-topic. As a few general examples, I'd point to implementations of F# computation expressions, "languages as libraries in Racket", extreme cases of fluent interfaces, and the sorts of instance_eval DSLs people build in Ruby, but there are many others too. Questions about those that treat language-design aspects should be permitted.

I would not include general libraries outside of the very tightly-coupled standard library as part of language design. Some "standard libraries" are very large (e.g. batteries-included Python has a Telnet client) and most of that is not really part of the language design.

$\endgroup$
2
  • 1
    $\begingroup$ I agree with your first point but less with your second. API design and "battery includedness" are part of the ecosystem. The telnet client of python is perhaps a step too far but there are also things which a language can consciously choose to think about or not. For example: logging, command line parsing and controlling external processes. Python had to go through several iterations to get its process library decent with abominiations like popen2 & popen3. I feel that is definitely relevant as discussion of language design. $\endgroup$ Commented May 26, 2023 at 8:56
  • 1
    $\begingroup$ See also languagedesign.stackexchange.com/questions/983/… $\endgroup$ Commented May 26, 2023 at 8:56
3
$\begingroup$

The line between “language” and “library” is very blurry. There's a continuum from things that are fundamental and indivisible (e.g. the basic concept of function/procedure/method), to special cases that can't be implemented from the fundamental concepts alone (e.g. integer calculations), to more ad hoc domain-specific libraries.

If libraries are off-topic, where do you draw the line? Let's take the example of the Python standard library. Surely such topics as the exception hierarchy, and string representations (1) are on-topic. What about ? Going into detail involves several library modules. Or ? Python has a few built in (e.g. map) and more from modules. Concurrency? Mixes language considerations such as what operations are atomic, and synchronization primitives provided by the library. If you rule out anything that isn't “built in” (in the terminology of the Python documentation), you're making an arbitrary distinction based on how Python's standard library is designed, and so that doesn't give you criteria that apply to other languages. For example variable-sized integers 1 are a built-in feature in Python, but not in many programming languages. If you include anything that is in the standard library, that includes things like email parsing and turtle graphics — again an arbitrary line that doesn't generalize usefully to other languages.

Libraries define a domain-specific language. Strictly speaking all libraries define a DSL, but few define an interesting DSL. Where do you draw the line?

The real question is, where are the experts? Expertise in designing a library is somewhat different from expertise in designing other parts of a programming language, like a parser, a type checker, an optimizer or a debugger. But expertise in designing a parser is somewhat different from expertise in designing a type checker, an optimizer or a debugger… Libraries are not fundamentally different. As long as the question is primarily about the design of the library interface, and not how the library is implemented under the hood, the question calls from this site's expertise and should be on-topic.

(Questions asking how to use a library are of course off-topic, just like questions asking how to use a programming language's fundamental features are off-topic.)

$\endgroup$
1
$\begingroup$

While non-standard libraries are not part of a programming language, there could be questions oriented towards how libraries can be implemented, such as the recent C++20 modules feature, or even builtin package managers like R's.

$\endgroup$

You must log in to answer this question.

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