>>5441
No, not brevity. Brevity would be how short program text is. That is not so important until you have those hueg 30+ character identifiers like the Java people seem to love, or perhaps how Pascal once put types and identifiers in the same namespace and you couldn't declare a variable of type "counter" with the name "counter," you had to create a type "Tcounter," so the language forced you to memorize a style and type one more character than a different language would for something many want to do, although the Pascal case isn't something to use a different language over.
I'm talking about how much you can express with how few language features.
As present in the Scheme standards:
>Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
This is one half of where modern languages fail, it's okay (and necessary) to have the language provide you conveniences for expressing whatever you want in a clear, simple manner. However, one language is clearly better than another when it manages to do a task as well as a different language but with less baggage. If you fail hard at it enough, you have a huge language like C++ which isn't a convenient language despite its extreme amount of abstractions and features. The abstractions and features distance it from machine code and have caveats the programmer has to mind, slowing programs down and being inconvenient rather than convenient.
Progress in programming languages would be improving an algorithm that is baked into the language, like list traversal in LISP or the zero-terminated strings in C. Improve the algorithm, and the language performs better with no loss in convenience or expressive power.
Progress would also be removing the cruft, like the register, restrict, and inline keywords in C. Remove them and C retains the same performance and expressive power, but with 3 less features for C programmers to occupy their minds with.
Progress would also be coming up with a way to allow programmers to express themselves better. C doesn't have multiple return values, so we use errno, or overload a return value to both signal error and return results like the return values of printf() and malloc(). C itself already finds a way to return multiple return values even if it lacks the syntax, so adding a more friendly syntax for multiple return values would be a logical improvement. That would probably mean returning values in 2 registers instead of 1 in many cases, so you could say it comes with a performance penalty, but consider it's no worse than using errno and better than returning values through a pointer parameter. Do that, and you gain convenience, with no loss in performance and without truly having added another feature for people to think about.
>the C example
Yes, that would be the C way to do it. Now you have to mind whether you want to pass the address of an object with auto storage duration, or whether you want to call the allocation function, check its return value, pass the pointer, and remember to free it.
LISP sacrifices performance for convenience by having a garbage collector and a single storage duration.
This is why I say that C and LISP are both worth using, but for different reasons. LISP is convenient and of middling performance, C is fast and of middling convenience.
If you take the average of a language A's qualities and it's clearly higher than language B, then there's not much reason to use language B. I can't tell which of C or LISP is better, so either is fine. I can tell Python, C++, and Rust are trash, so it's better to not touch them because they're regressive languages which produce programs that are buggier and/or slower. Let them be buried with COBOL and FORTRAN.