You are not wrong. But, they are not wrong either.

I feel like if you’re designing a language, the activity of producing the spec, which involves the grammar etc., would allow you to design unencumbered by whether your design is easy to implement. Or whether it’s a good fit for the language you are implementing the compiler with.

The OP also correctly identifies that thoughtful design takes a back seat in favor of action when we start writing the code.

The source code does what it does, including bugs.

So unless you want bugs to be your specification, you actually need to specify what you want.

A corollary to the linked article is that a specification can also have bugs. Having a specification means that you can (in theory) be sure you have removed all inconsistencies between that specification and the source code, but it does not mean you can know you have removed all bugs, since both the spec and the source code could have the same bug.

A bug is a difference between specification and its implementation. In no specification exists, there is no bug (strictly speaking). In a more wide sense a bug is a difference between some implementation and user's expectations, but such expectations may be considered to be some sort of non-formal specification.

Maybe this is your point, but the source code of any non-toy compiler is not a usable specification for the language it compiles.

If you want a specification from source code, you need to reverse engineer it. Although that’s a bit easier now, with LLMs.

What do you mean "usable specification"? Usable to produce another compiler implementation for the same language? This IS possible (like clang was designed to match GCC behavior).

Pure specification itself is useless without actual implementation (which does the job), so, trying to write such specification (in a natural language) has no practical sense.

You partly answered your own question by mentioning "implementation". Specification and implementation are two different things, and both are important.

A specification describes the externally observable behavior, constraints, and properties of a system. That's independent of how those properties are implemented.

An implementation is a concrete realization of a specification, that achieves the specified behavior using particular algorithms, data structures, and operational mechanisms.

> Pure specification itself is useless without actual implementation (which does the job), so, trying to write such specification (in a natural language) has no practical sense.

That's a non sequitur, i.e. the part of your sentence after the commas doesn't follow from the first part.

"Pure specification itself" has a purpose, which is to guide implementations. That's the "practical sense".

A programming language is not the compiler. A programming language is, in fact, not software.

Trying to define what a programming language is, is a lost cause anyway :)