<p>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 &lt;X&gt;, and compare the advantages and disadvantages of the various common approaches. I really want to get the syntax &quot;right&quot;.</p>
<p>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 &quot;bigger&quot;, better, and/or more fruitful questions to ask? (Or at least to <em>start</em> by asking?)</p>
<p>As a reminder, here's how to do <a href="/help/dont-ask">&quot;good subjective&quot;</a> (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.</p>

<syntax><language-design>
How can isolated focus on syntax be counterproductive in the earlier stages of a language's design?
CC BY-SA 4.0
2023-05-21T10:12:52.870Z
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)).
starball
CC BY-SA 4.0
2023-05-21T16:48:28.017Z
See https://languagedesign.meta.stackexchange.com/questions/219/are-we-more-like-world-building/220#220
Bruce Adams
CC BY-SA 4.0
2023-05-21T16:51:31.930Z
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.
Bruce Adams
CC BY-SA 4.0
2023-05-22T02:43:12.637Z
@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.
starball
CC BY-SA 4.0
2023-05-22T08:02:42.723Z
@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.
Bruce Adams
CC BY-SA 4.0
2023-05-22T08:08:36.970Z
@BruceAdams well, I added it according to the guidance in [/help/dont-ask](/help/dont-ask) about how to ask "good subjective" questions because I was getting close-votes for this question apparently being opinionated.
starball
CC BY-SA 4.0
2023-05-22T08:49:42.333Z
more related meta discussion: https://languagedesign.meta.stackexchange.com/q/235/251
starball
<p>Let me balance the direction of the question first: It's not a bad thing to care about syntax.</p>
<h3>Syntax <em>really matters</em>- but perhaps not in <em>just</em> the ways you might think</h3>
<p>For example (and all this really applies to most language features holistically):</p>
<ul>
<li><p>Syntax matters in relation to its composition.</p>
<p>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?</p>
<p>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.</p>
<p>Consider also the cognitive load/cost to your users of <em>learning</em> the syntax. Ex. See <a href="https://github.com/tc39/how-we-work/blob/main/terminology.md#syntax-budget" rel="noreferrer">TC39's &quot;Syntax Budget&quot;</a>.</p>
</li>
<li><p>Syntax matters over time, and with respect to your language's evolution.</p>
<p>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.</p>
<p>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.</p>
<p>And don't just think about your <em>language</em>. Think about the <em>code</em> 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 <a href="https://github.com/tc39/how-we-work/blob/main/terminology.md#web-compatibilitydont-break-the-web" rel="noreferrer">TC39's &quot;Don't break the web&quot; rule</a>, and <a href="https://www.stroustrup.com/quotes.html" rel="noreferrer">Bjarne's Stroustrup's &quot;Stability is a feature&quot;</a>.</p>
<p>The choices you make now with respect to syntax <em>can</em> 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 <em>are</em> techniques to design a language for evolution and/or extension (see <a href="https://languagedesign.stackexchange.com/q/924/251">What techniques have existing languages used or considered using to enable their evolution? Why were they chosen/considered? How have they fared?</a>).</p>
</li>
</ul>
<p>TL;DR: Syntax matters, and it <em>does</em> matter in the relatively earlier stages of design,</p>
<p>but perhaps not as early as you'd think. There are other things that people usually put first- and for good reason...</p>
<h3>Syntax is <em>rarely</em> a language's end goal</h3>
<p>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 <em>use</em> syntax to <em>solve a problem</em>.</p>
<p>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 <em>effective</em> 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. <a href="https://youtu.be/Hj5q8uyqGYc?t=1245" rel="noreferrer">ECMAScript</a>, and <a href="https://languagedesign.stackexchange.com/a/737/251">C++</a>).</p>
<p>If you haven't already, take the time- as much as you need- <em>don't rush it!</em>- to figure out what the design goals of your language are, and what problems you want it to solve. <em>This</em> 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?</p>
<p>Here are some examples of goals that tend to have implications for syntactic choices:</p>
<ul>
<li><p>Is it a goal of your language to <em>feel familiar</em> to people who program in existing, well-established languages targeting the same or similar problem/application-domains?</p>
</li>
<li><p>Is it a goal of your language to help people who write and solve problems using non-programming languages (Ex. Mathematical notation)?</p>
</li>
<li><p>Is it a goal of your language to be more &quot;batteries-included&quot;, 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)</p>
</li>
</ul>
<h3>Syntax in isolation is not necessarily the only way to &quot;make simple things simple&quot;™</h3>
<p>I find this worth touching on since one common and usually implicit / unstated goal is that for whatever &quot;core value&quot; a language strives to provide to its users, the way in which it enables its users to access that value should be &quot;simple&quot;.</p>
<p>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 <em>might</em> 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.</p>
<hr />
<p>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.</p>

CC BY-SA 4.0
2023-05-21T10:12:34.473Z
2023-05-26T22:06:31.453Z
2023-05-26T22:06:31.453Z
starball
<p>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.</p>
<p>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:</p>
<ol>
<li>Syntax ambiguities and collisions with other features are hard to discover until a non-neglible amount of work has been done on the language.</li>
<li>Often one will discover later on – if honestly evaluating syntax – that constructs were less useful or less readable than it seemed in isolation.</li>
<li>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.</li>
</ol>
<p>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.</p>

CC BY-SA 4.0
2023-05-21T17:50:21.737Z
2023-05-21T17:50:21.737Z
Nuoji
CC BY-SA 4.0
2023-05-21T17:54:13.930Z
"_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?
starball
CC BY-SA 4.0
2023-05-21T17:59:28.423Z
you [don't need to](/help/how-to-ask), 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.
starball
CC BY-SA 4.0
2023-05-21T18:28:16.017Z
@starball there is a passage in an interview where Bjarne Stroustrup where he discusses this, but my google-fu fails me at the moment.
Nuoji
# How can isolated focus on syntax be counterproductive in the earlier stages of a language's design?
Posted by: username_0 on 2023-05-21
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 , 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"](/help/dont-ask) (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.
**Tags:** syntax language-design
> **Comments:**
> **username_0**: 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)).  
> **username_1**: See https://languagedesign.meta.stackexchange.com/questions/219/are-we-more-like-world-building/220#220  
> **username_1**: 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.  
> **username_0**: @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.  
> **username_1**: @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.  
> **username_0**: @BruceAdams well, I added it according to the guidance in [/help/dont-ask](/help/dont-ask) about how to ask "good subjective" questions because I was getting close-votes for this question apparently being opinionated.  
> **username_0**: more related meta discussion: https://languagedesign.meta.stackexchange.com/q/235/251  
---
## 2 answers
### Answer by username_0 on 2023-05-21. Score: 12
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"](https://github.com/tc39/how-we-work/blob/main/terminology.md#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](https://github.com/tc39/how-we-work/blob/main/terminology.md#web-compatibilitydont-break-the-web), and [Bjarne's Stroustrup's "Stability is a feature"](https://www.stroustrup.com/quotes.html).

  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?](https://languagedesign.stackexchange.com/q/924/251)).

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](https://youtu.be/Hj5q8uyqGYc?t=1245), and [C++](https://languagedesign.stackexchange.com/a/737/251)).

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.
---
### Answer by username_2 on 2023-05-21. Score: 6
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.
> **Comments:**
> **username_0** (2023-05-21): "_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?  
> **username_0** (2023-05-21): you [don't need to](/help/how-to-ask), 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.  
> **username_2** (2023-05-21): @starball there is a passage in an interview where Bjarne Stroustrup where he discusses this, but my google-fu fails me at the moment.  
---
