"whatever format most people immediately understand at first glance"
Certainly that's a useful starting point. The problem is in figuring that out when there are multiple, roughly similar representation.
But it also depends on the goal. Sometimes it's better to learn a new format (Einstein notation, bra-ket notation, copy editing and proofreading symbols, modern staff notation for music, shorthand, etc.) than to use a system that a larger subset of people will understand immediately.
Forth is an example of a programming language which is developed for programmer productivity, on the assumption that the programmer will put in the effort to be proficient in the language.
I was speaking in terms of the 'eventual' case, not a starting point.
While optimizing syntax/form makes sense in highly specialized domains where no useful alternative exists, I'd argue that the opposite holds true in domains where more 'natural' alternatives are abundant.
Can't say I'm familiar with all of those. For proofreading, meta chars are necessary to indicate edits without the ability to mutate the original text. Musical notation has widely been replaced by tabs for guitar. Shorthand may be useful for writing that isn't consumed by others.
Cursive is a perfect example of a form of language that was created for efficiency. Which, arguably, held true for handwriting. But it didn't add enough of a benefit above/beyond plain handwritten text and was very difficult to duplicate digitally.
Not to rag on Fourth, I'm sure it's probably a very good language but how widely is it used today?
Like I said, no amount of research proving that programmers choose languages based purely on their technical merits can disprove the writing on the wall.
People choose what feels natural to them based on previous experience and/or common convention. Whatever choice requires the least amount of context switching overhead and allows the lowest barrier of communication between devs will win in the end.
That's why Typescript is immensely popular for developers with a strong OOP background that prefer writing code in an IDE.
For C, the low level support for types and memory access make it a natural fit for systems development. I have written low level network code in C#, it's an extremely awkward and verbose mess.
Python wins when it comes to simplicity and the ability to write really powerful functionality with a minimum amount of code. The list slicing as well as comprehensions are easy to understand and increase productivity dramatically.
Certainly that's a useful starting point. The problem is in figuring that out when there are multiple, roughly similar representation.
But it also depends on the goal. Sometimes it's better to learn a new format (Einstein notation, bra-ket notation, copy editing and proofreading symbols, modern staff notation for music, shorthand, etc.) than to use a system that a larger subset of people will understand immediately.
Forth is an example of a programming language which is developed for programmer productivity, on the assumption that the programmer will put in the effort to be proficient in the language.