10
$\begingroup$

I'm relatively new to the field of PL design, and I want to build a language. Before I start, I want to learn from the languages that have come before mine. Syntax seems like it matters, and so I want to look at how they do syntax for feature <X>, and compare the advantages and disadvantages of the various common approaches. I really want to get the syntax "right".

But from a bigger picture, I wonder if doing this is the most fruitful way to spend my time. Is there the possibility that I'm asking the wrong questions? Or that there are "bigger", better, and/or more fruitful questions to ask? (Or at least to start by asking?)

As a reminder, here's how to do "good subjective" (if you have to): explain “why” and “how”, give depth, use a constructive, fair, and impartial tone, and back up any opinions with facts and references.

$\endgroup$
7
  • 1
    $\begingroup$ Meta note: Yes, I know I'm really leading the question hard here, but I think it can take someone leading a question in a certain direction to get to something that might be being overlooked in the overall discourse (which is a bit of what I feel like I'm observing right now during the private beta of this site. Note that I'm NOT trying to say that anyone who asks these questions are missing some greater point. I'm just worried that some people who see the plethora of Q&A we have in these forms and who may have not built an intuition to take a step back might (miss greater points)). $\endgroup$
    – starball
    May 21, 2023 at 10:12
  • $\begingroup$ See languagedesign.meta.stackexchange.com/questions/219/… $\endgroup$ May 21, 2023 at 16:48
  • 1
    $\begingroup$ Given this is a Q & A pair, with a well worded and useful answer, not just a badly worded question, I feel it was wrong to close it. $\endgroup$ May 21, 2023 at 16:51
  • $\begingroup$ @BruceAdams any suggestions on what to improve in the wording of the question? Or even how to improve it? I have tainted eyes as the author and I can't see. $\endgroup$
    – starball
    May 22, 2023 at 2:43
  • $\begingroup$ @starball The only thing that springs to mind is to remove the reference to meta (i.e the as a reminder paragraph). In my limited experience it only seems to upset the mods. We don't talk about Meta except in comments or meta itself. $\endgroup$ May 22, 2023 at 8:02

2 Answers 2

12
$\begingroup$

Let me balance the direction of the question first: It's not a bad thing to care about syntax.

Syntax really matters- but perhaps not in just the ways you might think

For example (and all this really applies to most language features holistically):

  • Syntax matters in relation to its composition.

    Each part of your language's syntax will not act in isolation. It's a language, and a natural part of using any language (programming or not) is to compose usage of its features. (kind of obvious, but easy to forget). The implication is that adding any feature has the potential to have implications for every combination of its usage with the other features it already has. Think about it: How should those combinations work? Would they clash in ways that are undesirable? Would they create new problems?

    For example, say you have syntax for generators, and syntax for loops. Now you want to add syntax for async/await. Okay- how are those all going to work together in ways that make sense and don't create problems? Ex. look at JavaScript.

    Consider also the cognitive load/cost to your users of learning the syntax. Ex. See TC39's "Syntax Budget".

  • Syntax matters over time, and with respect to your language's evolution.

    Building on the previous point about composition, don't forget or don't rule out the happening of your language's evolution. Rarely does a language exist through time without its designers or users wanting it to change, and/or actually trying to change it.

    For example, if you're building a general-purpose, multi-paradigm language, you cannot predict what paradigms may emerge in the future. Or something more down to earth: It may be difficult to notice pain points in a language early on in its design if/when it hasn't been used much- whether in larger projects, or more application-varied ones.

    And don't just think about your language. Think about the code that users of your language will write. How could your design choices make it easier or harder for them to evolve their code if your language evolves? And what can you do to mitigate situations where a later change you might want to make could cause old code to take on different meaning? (dialect bifurcation (think Python 2 and Python 3)). For real-world examples of languages who deeply care about this, see TC39's "Don't break the web" rule, and Bjarne's Stroustrup's "Stability is a feature".

    The choices you make now with respect to syntax can interfere with choices that you may want to make in the future. It is probably impossible to prevent every such kind of unhappy scenario, but there are techniques to design a language for evolution and/or extension (see What techniques have existing languages used or considered using to enable their evolution? Why were they chosen/considered? How have they fared?).

TL;DR: Syntax matters, and it does matter in the relatively earlier stages of design,

but perhaps not as early as you'd think. There are other things that people usually put first- and for good reason...

Syntax is rarely a language's end goal

Even when somebody talks about syntax and it sounds like something to do particularly with syntax is one of their end goals, you'll usually find something deeper by reading or listening more carefully. Often you will discover that they are trying to use syntax to solve a problem.

Thinking and talking about your end goals and the big-picture problems you want to solve are usually a good first step. Starting without a destination in mind is generally not an effective way to get anywhere meaningful. There are several well-known, well-established languages that approach- or wish they would approach- language proposals by starting by first just focusing on defining problems (Ex. ECMAScript, and C++).

If you haven't already, take the time- as much as you need- don't rush it!- to figure out what the design goals of your language are, and what problems you want it to solve. This is something that you'd do well to first look to your predecessors for. What have they tried? How has it worked for them? What have they regretted? Has adherence to their goals helped them to stay relevant and avoid identity crises?

Here are some examples of goals that tend to have implications for syntactic choices:

  • Is it a goal of your language to feel familiar to people who program in existing, well-established languages targeting the same or similar problem/application-domains?

  • Is it a goal of your language to help people who write and solve problems using non-programming languages (Ex. Mathematical notation)?

  • Is it a goal of your language to be more "batteries-included", or instead to back off and let your users build their own abstractions and tools using what the language does provide? (this is a spectrum, and also has a lot of implications for library design)

Syntax in isolation is not necessarily the only way to "make simple things simple"™

I find this worth touching on since one common and usually implicit / unstated goal is that for whatever "core value" a language strives to provide to its users, the way in which it enables its users to access that value should be "simple".

Syntax can have a great deal of power in achieving that. However, (not in all cases, but in more than you might first think,) syntax is not the only tool you have under your belt. For example, you might have any of the following: a standard library, metaprogramming, and the rest of the features (and their syntax) that you've already largely settled on. Don't let your thinking be trapped into just syntax in thinking of ways to achieve this goal.


To summarize, the most important thing in the early stages of designing a language is often to define your end goals and define the problems you want to solve. Isolated focus on syntax can be counterproductive if it distracts from that during those early stages.

$\endgroup$
6
$\begingroup$

The primary reason why not get too bogged down in syntax early on is because syntax cannot be properly evaluated until you're actually sitting down and working in the language solving real tasks.

A general start is essential though, which can be achieved by copying off another language and then writing some imaginary sample code, but this has to be done with the expectation that any new syntax is likely to get discarded because:

  1. Syntax ambiguities and collisions with other features are hard to discover until a non-neglible amount of work has been done on the language.
  2. Often one will discover later on – if honestly evaluating syntax – that constructs were less useful or less readable than it seemed in isolation.
  3. In the beginning more verbose constructs are usually preferred by everyone, including you as the designer, but in the long run these will feel clunky and often need to be streamlined.

So in short, you definitely need some syntax to start from, but expect this to be changed as you iterate on the design. I personally would recommend borrowing as much as possible from other languages in the early stage, as the benefits and drawbacks of those constructs are known. Later, when then language has a compiler, the syntax can be iterated on.

$\endgroup$
3
  • $\begingroup$ "In the beginning more verbose constructs are usually preferred by everyone" - I've never heard of this before. Can you provide some historical examples to back up the claim? $\endgroup$
    – starball
    May 21, 2023 at 17:54
  • $\begingroup$ you don't need to, but as the author of the question here, I encourage you to also address the part of the question which asks: "Or that there are "bigger", better, and/or more fruitful questions to ask? (Or at least to start by asking?)". I think this will improve the long-term value of the Q&A here. $\endgroup$
    – starball
    May 21, 2023 at 17:59
  • $\begingroup$ @starball there is a passage in an interview where Bjarne Stroustrup where he discusses this, but my google-fu fails me at the moment. $\endgroup$
    – Nuoji
    May 21, 2023 at 18:28

You must log in to answer this question.

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