In my project, the overall goal is to produce a notation that is so compact and precise, that it is shorter than the conventional product specification documents, and thus can be the specification and implementation in one. Certainly in smaller projects it holds true, and we'll see how close it gets on larger projects. Classical UML, and formal system design processes are not practical because you can't execute UML, so you end up with an implementation phase than then needs to be checked against a changing specification document; chaos ensues. Having the spec and the program be one thing should be grasped as a big win.

sounds similar to Language Driven Design approach of Racket

"Having the spec and the program be one thing should be grasped as a big win." agreed!

My understanding is that the spec should be less detailed than the implementation like a map to the territory. If the map is the same size as the territory, it’s not useful. Thus my opinion is that UML is useful only when it’s not the exact code ran as mentioned above with the map vs territory argument.

Function signatures in statically typed languages are much smaller than complete implementation and yet that's often all documentation you need.

In smaller projects all I get is a napkin sketch, so near zero time was spent on the spec in those situations. I was thinking of large company projects. In those environments big money is spent on a requirements document which is typically fed to a system architecture/design team which specializes in identifying in microscopic detail how the system is to operate, then passed to entirely separate team of implementors. The spec in that environment is supposed to completely specify WHAT and WHEN the system accomplishes the task in excruciating detail, but not HOW, although nowadays screen mockups (some call them wireframes) are given and they have a fair amount of HOW in terms navigation and animation specified. The programmers are not tasked with any formulation of business logic or input or output formats. Those are supposed to be nailed down. My point is that if the cost of making the spec was 100 units of money, and the programming is 400 units, if you can use a notation for the spec that is executable maybe the total cost is 120 units. That would be a big savings in time and money. So many of the commercial practices use tools and methodologies that don't generate executable code. Certainly some of the prototyping tool companies are addressing this, but those things don't always work out so well.

I like @Ernest Lee's point. It's nice having views that ignore some details. I would love to ask my software, assuming A, B, and C and ignoring X, Y, and Z, does this complicated implementation reduce to this much simpler specification? And I'd love an automated system that can say, "mostly, except I'm not sure about this 10% of it."

This sounds a lot like the problem in game development. Designers may code badly and inefficiently, but having them being able to code for example visually in Unreal Engine 4 means they can create executable specs, that may be transformed into good code. There is no bottleneck between the spec design and translation into code.

I have often built products from sketches, and paper mockups. For things that are obvious, or the details best left to the programmer, this can be very effective. It also cuts down on the conflict between spec and product because the spec is so loose. But i was thinking about larger systems, where the design is very deliberate and big money was spent on it.

In the industry of game development, interchangable art assets and per engine specific code is common in the asset stores. The use of visual programming languages in both Unreal Engine, Unity and in progress in Godot provide the promise and results of rapid prototyping. The visual languages are good enough to be shipped to release as is without conversion to c++ / c#. I’m agreeing with you, but the future is unevenly distributed.

I find the topic of executable specifications quite exciting. The main reason why people aim for a specification is explainability. Explainability brings with it feedback and this leads to better decisions. A specification is used as a model in that it leaves some details away. Of course, no details are irrelevant in general, but some details can be irrelevant for a specific perspective. For example, security details are not irrelevant in general, but it is irrelevant when I want to evaluate how to model some accounting logic. And when we are interested in penetration tests, the specific accounting model might be irrelevant. Considering this, aiming for a single notation that focuses only on some parts but not on others can be interesting, but it is fundamentally limiting. Solutions like the visual coding in Unity/Unreal Engine, coding in Scratch, or coding in Excel are certainly interesting, but at the end, these specifications sit on top of a huge black box (the actual engine) that everyone takes for granted that it must remain a black box. That black box should not remain a black box. A program is a specification, too. Yet, the explainability power is rather low. So, why don’t we bring explainability into our systems? From my perspective, there is a distinction between the act of creating a specification and the act of understanding an explanation. Most solutions I see focus on the language with which to create. This is important, but it leaves open the other half of the problem. Interestingly, understanding an existing system implies creating a mental model about that system. That model is a projection. The projection is separate from the system, but it allows us to relate to its internals. And this projection is not a language issue. It’s a tool issue. It’s an issue of the environment through which we experience the internals of our system. Nowadays, we typically call it the IDE. The I in IDE stands for integrated, and I believe the ultimate integration involves all stakeholders of our system. It’s not only developers (the typical IDE fails today even on that front - for example, it fails every time the developer has to go on Stackoverflow to ask a question about her/his own system). To reach this integration, the IDE has to offer these projections. As different aspects of our system are interesting from different perspectives, the IDE cannot rely on one single form. It must be moldable. I believe this is fundamental. By molding the way we perceive the internals of our systems, we can bring explainability into our specification and make it accessible to a wider audience.