A "programming language features" wiki cataloging such features (and their pros/cons) would be amazing.
In C, the escape character for literal strings, as interpreted by the C compiler, is the backslash. ("\")
Also in C, the escape character for format strings, as interpreted by the printf function, is the percentage sign. ("%")
This is the correct way to do things, for the very obvious reason that neither the compiler nor printf can get confused by the input the programmer provides. Directions to the compiler look nothing like directions to printf.
But for some reason, this knowledge of how to define formats was completely forgotten, and so regular expression parsers were all defined to use a backslash as their escape character. There is no earthly reason you would want to do this. It causes many, many problems, and has no benefits, to use the same escape character for the compiler/interpreter and for the regex engine. But we're doing it anyway.
There are a few books about the history of programming languages, but they are mostly descriptive and contain little comparative analysis of the value of various features. Moreover because due to space limitations they have to mention only a part of the features of the languages that are described, the choice of what to mention and what to ignore in the description of a language may be not the most appropriate from the POV of an experienced programmer.
Therefore I have found more useful the original manuals of various programming languages, from when they have been launched, during the fifties, sixties and seventies of the 20th century. After 1980 the pace of innovations has slowed a lot and most of the languages that introduced those innovations are still used today, so finding documentation about them is no longer difficult.
While C was itself an innovative language, the fact that it included very few of the features of the languages contemporaneous with it ensured that many of those features are not available even today in mainstream languages, while other features have become widely used only after decades after their invention, for instance iterators have already been introduced in 1974, in the same year with C, but they have been revived only a quarter of a century later.
Fortunately now there are a handful of Internet sites dedicated to the preservation of the history of computers and programming languages, from where it is easy to download most of the old documentation.
Program language design is also:
- Performant compiler design
- CPU/GPU hardware optimization
- Programmer ergonomics
- Large software project organization
- Source code hygiene
- Evolutionary flexibility
- Platform management and organization
That's a lot of intersections! And it's reasonable that we get programming languages with flaws in one or more areas simply because their designers weren't experts in yet another needed field.I agree! Those things you listed all interact with eachother.
I am still trying to get my head around orthogonality in design and how to design permutations/combinations that work together well and are flexible.
Start by listing out programming language qualities that are good/bad/intolerable for each of those other interaction categories, then work that backwards into a set of required features for a desired language.
E.g. X makes writing a Y compiler optimization impossible
Structured Interaction Programming: https://github.com/samsquire/ideas5#350-structured-interacti...
Knowledgegraph programming language: https://github.com/samsquire/ideas4#334-knowledgegraph-progr...
On structured iteration programming, it might be a valuable first step/prototype to see if you can generate a fact/association graph from historical discussions about programming language qualities.
Much has been written (and continues to be!) in many high signal:noise sources. And some lower ones.
(1) extracting a relationship graph between all mentioned qualities and (2) generating sentiment analysis on those relationships (even if positive/neutral/negative/unknown) might help bootstrap a more comprehensively-populated version that can then be refined.