OTOH, flowcharts and such are still in widespread use.
Flowcharts and other types of diagrams are indeed in widespread use, but as design documents to be understood by humans, not as executable specifications. Being made to describe the high-level design of a system to humans, these diagrams are highly abstract and omit most of the details that would be required for an executable specification.
You can define executable graphical languages, as listed in the link I provided, but once you try to use them for anything but a toy example, your diagrams become excedingly large and complicated, essentially unusable.
And that a graph (mathematical sense) can be as precise as you like.
You can define executable graphical languages, as listed in the link I provided, but once you try to use them for anything but a toy example, your diagrams become excedingly large and complicated, essentially unusable.
There are entire management chains of my acquaintance on whose eyelids I could wish that sentence engraved.
There is research being done in improving abstractions for graphical languages. For instance, this applies to graphical representations of monoidal categories (so-called “string diagrams”), which can be used to represent functional programming, monad-based programs (at least to some extent), data-flow, control flow and the like.
It is still the case that textual syntax has a higher information density, though.
By the way, natural language generation could also be used to make programming closer to the cognitive style of humans, and thus more stimulating. I’m not talking about primitive efforts like COBOL here: we could take inspiration from linguistically-inspired formalisms such as Montague grammar to map commonly used calculi and programming languages to natural language in a fairly straightforward way.
OTOH, flowcharts and such are still in widespread use. And that a graph (mathematical sense) can be as precise as you like.
Flowcharts and other types of diagrams are indeed in widespread use, but as design documents to be understood by humans, not as executable specifications. Being made to describe the high-level design of a system to humans, these diagrams are highly abstract and omit most of the details that would be required for an executable specification.
You can define executable graphical languages, as listed in the link I provided, but once you try to use them for anything but a toy example, your diagrams become excedingly large and complicated, essentially unusable.
Irrelevant.
There are entire management chains of my acquaintance on whose eyelids I could wish that sentence engraved.
There is research being done in improving abstractions for graphical languages. For instance, this applies to graphical representations of monoidal categories (so-called “string diagrams”), which can be used to represent functional programming, monad-based programs (at least to some extent), data-flow, control flow and the like.
It is still the case that textual syntax has a higher information density, though.
By the way, natural language generation could also be used to make programming closer to the cognitive style of humans, and thus more stimulating. I’m not talking about primitive efforts like COBOL here: we could take inspiration from linguistically-inspired formalisms such as Montague grammar to map commonly used calculi and programming languages to natural language in a fairly straightforward way.