Barrapunto

[...] Lo único que se puede escapar son errores de ejecución.

Claro, los mas simples de corregir ¿cierto?.

Por otro lado, con lenguajes dinamicos + una fuerte politica de testing (que de todas formas vas a necesitar aunque uses uno fuertemente tipado) salvas casi todo el problema de que el compilador te detecte ciertos errores relativamente simples.

Como dirian por ahi, Strong Typing vs Strong Testing ;-)

Creo que mezclar el tipado fuerte o debil, con lenguaje compilado o interpretado es atrevido.

C# es lenguaje pseudo-interpretado porque es pseudo-compilado. Pero si te fijas en python veras que te crea unos ficheros .pyc que son los bytecodes de los .py. Asi que python es tan estatico como C#, o un poco menos porque no hay que ejecutar el comando que plagie al javac.

Lo que si te hace la pseudo-compilacion es un chequeo de errores sintacticos. Puedes probar el comando "perl -c" y leer la siguiente linea:
    -c check syntax only (runs BEGIN and CHECK blocks)

Cierto es que el tipado debil no te encuentra determinados errores de asignacion de tipos. Pero ser tipado fuerte solo te libra de ese nimio detalle. No hay nadie capaz en Python de poner una asignacion en vez de una comparacion de un if. Cosas que pasan cuando no pulsas bien uno de los 2 iguales en java. Y esto no se comprueba y falla, en python repito no.

¿Cuantas veces te ha pasado en curro que han dejado algo en un lenguaje compilado y no sabes cuales son los fuentes que le corresponden? Esto, aparte de una cabronada si que es algo que relentiza el desarrollo. El resto de las cosas, unas veces restan trabajo y otras la dan.

"Con lenguajes rígidamente tipados como C# podemos comprobar que el programa es léxica, sintáctica y semánticamente correcto con sólo compilar."

Dios mio, el compilador sabe mas que el propio programador :O. El compilador solo llega a la parte sintáctica compañero.

¿Utilizas código de test? Pruebas unitarias, funcionales, de sistema, de integración, etc..

El código de test sustituye al compilador, y es la clave que explica la idoneidad o no de los lenguajes dinámicos con respecto a los estáticos

Muy de acuerdo contigo.

Además, diría otra cosa en favor de los lenguajes estáticos: algo que invalidaría por completo muchas de las "supuestas" ventajas que arguyen los defensores de los dinámicos, y es que la ventaja de los lenguajes dinámicamente tipados de que siempre tiene el código fuente (por aquello de ¡¡dónde he dejado el código de este ejecutable/librería!!) puede adquirirla el lenguaje estático con sólo tener un intérprete.

Es decir, podemos convertir lenguajes estáticos en dinámicos, pero no al revés. Creo que está todo dicho.

Muerte a lo dinámico.

Pero en los lenguajes dinámicos esa etapa posterior ocurre... en menos tiempo. Lo que importa es cuando empiezas a encontrar errores, si desde el primer día o a la semana, da igual si esa etapa es posterior en el orden de etapas.