Barrapunto

Usando indices de arrays, daría "error te has salido", corregirías el bug y ya está.

Pero eso incluye la sobrecarga de hacer que el ordenador compruebe en cada acceso, además de tener que guardar el valor dentro de la estructura de datos.

Quizás el problema es que no exista una biblioteca estándar como en C++ o Java (quizás no tan extensa) que te resuelva los problemas más comunes.

Segurísimo. ¿puedes asignar byte a un char sin error?. ¿Puedes asignar un puntero a un int a un puntero a un char?. ¿Puedes asignar un float a un int?

Me pillas un poco oxidado en teoría de los lenguajes, pero yo entiendo tipado débil cuando, por ejemplo, una variable almacena distintos tipos sin problemas o puedes pasarle un int a una función que espera un float (eso seguro que no ocurre).

Las cosas que pones tienen sentido en el mundo C. En el orden que me conviene:

• Al asignar un float a un int se toma la parte entera. Es como realizar una conversión.
• Un byte se puede asignar a un char porque al fin y al cabo char es el nombre bonito que en C se da a los bytes. De hecho, el tipo byte creo que no forma parte del lenguaje de por sí.
• Dos punteros se pueden asignar porque son del mismo tipo: el tipo puntero (dirección de memoria). El tipo del puntero sólo sirve para saber cómo tiene que hacer los incrementos. Aún con eso el compilador te saca un warning: no es un error porque estás haciendo algo válido, pero te avisa.

Lo que me lleva a una nueva concesión para ti: es una basura que no esté establecido qué tamaño tienen un short, un int, un long, etc, y dependa de la máquina y el compilador.

Si te empeñas porque lo consideras necesario, le fuerzas la conversión explícitamente, y ya está.

Si haces eso en C el compilador te suelta un warning como una catedral. Puedes ajustar el compilador para que considere errores los warnings o bien proponerte a ti mismo dejarlo todo sin warnings.

El 99.9% de los casos en una condición quieres hacer una comparación, no una asignación

No estoy de acuerdo. En C y derivados es muy común sustituir:

f = fopen("archivo", "r");
if (f!=null) {
...
} else {
  error("No se puede abrir el archivo");
  exit(1);
}

por

if (f = fopen("archivo", "r")) {
...
} else {
  error("No se puede abrir el archivo");
  exit(1);
}

Entiendo tus reticencias, yo lloré sangre en mis primeras prácticas de C por un error debido a eso mismo, pero una vez te acostumbras no ocurre. ¿Una vez en el kernel ente cuántas miles de líneas contribuídas?

Evidentemente no se puede hacer una ejecución en cascada como en C (si se cumple B, ejecuta B, si se cumple A ejecuta A y B) ¿Pero quién quiere esto? ¿cuántas veces se necesita?

No es que no tengas parte de razón, pero yo he usado esta característica varias veces.

ada estructura debería cerrarse de una manera, p.ejm. en for/next while/wend case/cend funcion/eif.

Puede, pero a mí se me antoja incómodo de leer, nunca me ha ayudado mucho esta sintaxis. Admito que debe ser por costumbre.

En este aspecto la sintaxis que me parece genial es la de python, que se hace mediante la tabulación de las sentencias, aunque con la gran pega de la confusión espacios vs tabuladores (aspecto que parece imposible de llevar bien para alguna gente).

me repatea no acordarme si este identificador es MiFuncionInt o MiFuncionINT o miFuncionInt o miFuncionINT

Por eso decía yo lo de seguir un criterio coherente. Por ejemplo en Java sería miFuncionInt() (o más bien miMetodoInt), y en el estándar de C++ sería mi_funcion_int().

Es lamentable que otro lenguaje compilado no se haya convertido en un estándar de facto como el C/C++.

Aparte de la inercia, imagino que cuando necesitas un fuerte rendimiento la desnudez y crudeza del C tienen su utilidad. Y cuando los requisitos no son fuertes, la multiplataformidad y otras ventajas de los lenguajes interpretados se imponen.