The good news is, that the problem of identifying the ideal programming language can be reduced to only two: Assembly vs. C. It is pretty easy to show, that C code will run slower and needs more RAM than the manual created assembly code. A typical example would be a prime number generator.
The more interesting question is, how much exactly C code will run slower. Somewhere in the internet it was written that without using cc65 optimization techniques the C code will run 5 times slower. On the first look this speaks for replacing C code with assembly. But a closer look will show, that slowdown by the factor 5 is not very much. Suppose there is an algorithm which needs 60 seconds. If the same algorithm was rewritten in Assembly it will need only 12 seconds. In both cases, the algorithm won't run in realtime but the user has to wait in front of the machine.
The main concern with assembly language is, that the sourcecode isn't readable. Even if the programmer is using lots of comments, the code will look messy. This is perhaps one of the reasons, why C has replaced former assembly coding.
Suppose the hardware is a bit faster than the original 6502, suppose some optimizatinon techniqfues in the compiler were activated, then the chance is high, that the C code will be only 2 times slower than the assembly language counter part. This slow down is acceptable because the code is way much easier to read.
Let us make the situation more practical. A naive prime number generator works with two nested loops. Such an algorithm will run in assembly around 5 times faster then the C counterpart. But, a more advanced sieve algorithm will run much faster, no matter in which programming language it was implemented. That means, the sieve prime number generator written in C will outperform the nested loop algorithm written in Assembly language easily.
The problem with coding assembly language is, that it is difficult to write longer and more complex algorithm. Implementing a sieve algorithm in Assembly is an advanced project. That means, even an experience programmer will need many hours in doing so.
It is a known fact that during the 1980s the c language was not very popular for the Commodore 64. All of the demos were written in pure assembly code. This fact is known, because the sourcecode of the demos is available and it is normal 6502 assembly code. But what if the demo competation has the contraints, that the code has to be written in C?
since a while the C64 community has discovered the cc65 cross compiler again. They are trying to use this environment to write games from scratch. The resulting games are look not impressive as the Assembly demos, but they are easier to read and it takes less effort to code them.
A list of some games written in cc65 are available at https://wiki.cc65.org/doku.php?id=cc65:cc65-apps The quality of these games is low. They are looking like the early c64 games from the 1984 year.
An interesting side question which remains unanswered in this blog post is, if Forth can outperform the C language on the C-64. the problem with Forth is, that most existing Forth systems are only interpreters, they are not converting the code into assembly instructions so the resulting program will run slow. What is known from the MS-DOS PC is, that compiled Forth code can reach the same speed like compiled c code.[1] That means, compiled forth code will run slower than hand coded assembly code.
[1] Almy, Thomas. "Compiling Forth for performance." Journal of Forth Application and Research 4.3 (1986): 379-388.