Syntax is the last thing you should design
I disagree with this intensely.<p>For starters, syntax drives how I interact with a language as much as - maybe more than - semantics. How expressions are laid out is intensely important to me, as it affects how I remember and visualise the code. I can visualise the layout of code I have not worked with in years when the syntax is clear, and the code is well formatted.<p>I can work around painful semantics and find ways to pretend they don&#x27;t exist by avoiding features or picking patterns that work better; but painful syntax usually stares me in the face ever moment I work with a language.<p>I have more than once rejected or picked languages based on syntax. E.g. I can&#x27;t look at a Python program without getting annoyed with the syntax, and I avoid using the language whenever possible over it, and I work with Ruby whenever I can for the same reason (though the language geek in me wants to cry whenever I think about the Ruby grammar)<p>I also reject the idea of avoiding hand written parsers to start with. I sympathise a bit with the idea. I can see quickly testing changes with a parser generator. And certainly, if you hand write a parser, you need to avoid the temptation of adding all kinds of awful exceptions.<p>E.g. I love Ruby as a user of the language, but the MRI parser is beyond awful, and I think the syntax could have had most of the nice aspects and avoided most of the awful syntactical warts with a bit more discipline (&quot;favorite&quot; wart at the moment: &#x27;% x &#x27; parses to the literal string &quot;x&quot; - &quot;%&quot; when not preceeded by an operand that makes it the infix operator &quot;%&quot; starts a quote-sequence where the following character indicates what the quote character should be - with the exception of a few special character, most characters will set the quote character to its identity. So in &#x27;% x &#x27;, the quote character is space).<p>Though MRI uses a Bison parser, but contains thousands of lines of handwritten exceptions, demonstrating both the bad parts of hand writing irregular exceptions into parsers, as well as how easily you can mess things up even if using a parser generator if you have one that isn&#x27;t strict enough.<p>But to me, if your hand written parser becomes big and&#x2F;or problematic to maintain, you&#x27;re designing a language that will be problematic to parse cleanly, and it&#x27;s probably worth revising your grammar (I wish this rule had been adhered to for Ruby).<p>Nice, regular, clean grammars tend to lend themselves very well to small, compact hand-written parsers. In practice I&#x27;ve never run into a situation where a grammar change required major rewrites of a parser in any project I&#x27;ve worked on for this reason, unless the rule deviated majorly from what I&#x27;d consider good practice in language design in ways that would cause problems for most parser generators too.<p>Modularising a hand written parser along the lines of the grammar rules is easy, and few changes cut so deeply across grammar rules to make this difficult.<p>But what a hand written parser tends to get you over a parser generator, is better ability to do clean error reporting, and better ease of introspecting how parser changes actually changes the processing in ways that are meaningful to mortals. To me at least, this is a lot more difficult to do with ever parser generator I&#x27;ve tried (and I keep hoping to be proven wrong; I&#x27;ve tried writing my own too, to try to prove myself wrong, and so far I&#x27;ve failed to come up with something I consider a usable replacement to handwritten parsers - you certainly <i>can</i> come up with something expressive enough, but it tends to end up being verbose enough to lose most of the benefit over clean code in the target language that saves you from having to deal with idiosyncracies of the generator).<p>To me the &quot;solutions&quot; offered demonstrate exactly <i>why</i> syntax matters to me:<p>I deeply admire Forth and Lisp and descendants on a technical level, but the syntax has always been a massive barrier to me for both language classes. I chose a s-expression inspired syntax to kick off my own compiler project by basically treating it as a serialization format for the parse tree, and first adding a parser on top later, but I did that first to be able to toy with semantics of something I didn&#x27;t intend to make into its own language, and then to act as the &quot;guts&quot; of my in-progress Ruby compiler, not because I&#x27;d be willing to work with it more than that.<p>If anything, I&#x27;ve found it incredibly painful to work with, and I&#x27;d never have &quot;held out&quot; for very long without bolting a more human-friendly parser on top very early on. The experience has made me more insistent - not less - on if not starting with the syntax, then at the very least co-evolving semantics and syntax from the outset.