Do you see?

In addition to assembler I use the ANSI-C under the MPLAB programming environment for writing code for embedded microprocessors in my work. Whilst 'C' enables me to write code more quickly and is more maintainable than assembler, I contend that the claim that 'C' makes code that is almost as tight and efficient as assembler false. I contend that the 'C' language is unnecessarily convoluted and far from elegant.

For example in an recent project I used the PIC18F67K22, a 8-bitter with a massive 128K of code memory, for a reasonably simple task. In assembler I would have expected my code to fit into less than 32K of memory, but for this project I used 'C' and it filled up about 80K of code.

'C' header files can be hard to find because their path is often implicit, hidden in the compiler configuration. I say that the that MPLAB ought to provide a more intuitive way to find header files.

The 'C' "#define" and user type definition statements are very powerful but lends themselves to hopelessly nested definitions, and an attempt to find out what a label actually means can lead to a long rabbit trail through multiple source and header files that can end in the compiler's own source files. There ought to be a way to display this rabbit trail as a list rather than have to follow it.

I contend that variables in 'C' are too "strongly typed". This often results in the need to prefix a variable passed to an inbuilt function with a non-intuitive cast to stop the compiler generating an error. Which detracts from the whole point of casting and implies another contention - casting is a way to change a variable from one type to another but it is not always clear what information is lost is so doing.  Here is an example from my code: to simplify the main code I have defined a new type "PGMCHAR" and used this rather than the original "const rom char far" to cast a literal string in order to satisfy the use of the inbuilt function "strcpypgm2ram":

typedef const rom char far  PGMCHAR;

strcpypgm2ram(wbuffer, (PGMCHAR*) "Hello world");

Which in any decent sort of language this would read:
wbuffer = "Hello worldd";

I contend that a language like 'C' which claims to give low-level access ought to allow the programmer to do anything that is safe. And yet 'C' does nothing to stop you corrupting memory outside your remit, but does many things to restrict your freedom such as insisting that strings are signed and have to be terminated by a zero. Thus making it impossible to have a string with zero in it, and difficult to use the upper 128 character codes.

IMHO a programming language ought to be intuitive, as close to assembler as is reasonable and with a plethora of simply styled functions and constructs. I have often mused about writing such a language. But it would never be adopted because there is a professional pride thing that makes programmers adhere to 'C' and its many derivatives.