Comment by estebank

> while you cannot get a compiler out of the door withot a parser, you can indeed leave all the fancy optimization features out, don't you? And if you want to get a MVP out of the door, do you focus your effort in developing optional features or the basic, critical part that ensures that your language exists?

> And then there's developer experience. Syntax/grammar errors? You need the parser for that, don't you agree?

These two statements are at odds with each other as having great developer experience is indeed a "fancy optimization" that you shouldn't spend too much time on when starting a project (and I say that as someone spending their time every day thinking about making compiler errors better), and part of the reason the literature around parsers is problematic is because graceful error recovery isn't explored in detail.

> And this is a parser optimized for speed.

Parse time is never the bottleneck. It is a waste of time to focus on optimizing parse speed at the beginning. It is worth it to eventually measure and tune it, and to think about the implications when designing your grammar, but beyond that the slowness of compilers is never driven by their parsers.

> you cannot get a compiler out of the door withot a parser

Technically, you can: you make your compiler something that consumes an already existing bytecode (like the JVM's or .Net's CLI) or only implement an AST parser that isn't intended for humans to actually write while you nail down the specifics.

> Syntax/grammar errors? You need the parser for that, don't you agree?

Error recovery in a parser is a tricky thing: it is intimately tied to the choices you've made in your grammar. The more redundancy and uniqueness between scopes you can have, the easier it can be for your parser to identify where things have gone badly. For example, in python if you write

    if foo = bar:
        print(foo)

you have little information but can still infer that you likely wanted to compare equality instead using ==. But because Python has a very flexible grammar and semantics, the following is valid but likely not what was intended:

    class Foo:
        def bar(self):
            print("hi!")

    foo = Foo()
    foo.bar = "hi!"

If you make different more restrictive decisions on both grammar and semantics you can still provide tools to allow people to do this, by being more verbose, but people who do this by accident can be given excellent diagnostics.