El siempre verborreico Steve Yegge acaba de publicar un excelente y larguísimo artículo (en inglés) en el que afirma que el peor enemigo del código es su tamaño. Las razones -segun el- son: el uso de lenguajes estáticos como Java o C#, el abuso de los patrones de diseño y de la refactorización y los modernos IDE's como Eclipse o Visual Studio. La solución que ofrece es utilizar lenguajes dinámicos que soporten templates, expresiones lambda y closures para escribir código. Original http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
Es muy simplista lo que dice. El peor enemigo del código? pues es un tradeoff entre eficiencia y mantenimiento. A mayor eficiencia, más optimo uso de los recursos y mayor velocidad, peor es el mantenimiento ya que la programación orientada a objetos resulta demasiado costosa en términos de recursos, pero por otra parte es la única que permite separar claramente la implementación del código de su interface.
Por otra parte, esto de los lenguajes dinámicos y estáticos, el estático puro y duro es el C++ con su gran ventaja el fuerte chequeo de tipos en tiempo de compilación. Lenguajes más dinámicos, con enlace en tiempo de ejecución, son mucho más difíciles de depurar y generan una cantidad de código brutal.
Y tercer y último punto, lo importante son los algoritmos y como se implementen. El éxito de Google y de todas las companias de primera, reside aquí y eso exige un conocimiento más allá de lenguajes como Java, y más del tipo C++, un conocimiento profundo de punteros y recursividad (a ver quien es capaz de resolver estos sencillos ejercicios en C: http://www.joelonsoftware.com/articles/TestYourself.html ;)), que se ha perdido con la irrupción de estos modernos lenguajes que no son sino una colección de libraries que aumentan monstruosamente el tamano final del código como resultado
Probablemente la utilización de lenguajes dinámicos redujese la cantidad de código, pero probablemente también terminaría por reducir su legibilidad.
Los IDEs como Eclipse o Visual Studio ahorran horas y horas de depuración y testeo facilitando enormemente la tarea al programador.
Conclusión: lo que lo que ganaríamos por un lado, lo perderíamos por el otro. Así que como todo, sería cuestión de gustos. Llamadme inmovilista, pero personalmente me quedo con Java y C#, por muy "estáticos" que sean.
Lo que el autor sugiere es absurdo, los lenguajes de tipado dinámico son para hacer chapucillas rápidas, no los veo yo para un proyecto grande y serio. Tipado débil ==> Un montón de errores de tipado
También podemos usar lenguajes funcionales como Haskell que
1) Son tremendamente expresivos
2) Debido a 1) reducen enormemente la cantidad de código que necesitas
3) Son de tipado estático, no fuerte como Java etc, no hay error de tipos posible en Haskell u OCaml (u otros).
#2 La OO la única que permite separar implementación e interfaz? Conoces algo más que C, Java y C++?
Programar en C en general es debido a una falta de sentido común, no suele merecer la pena, primero porque un código C siempre está plagado de errores, incluso en programas con muchísimo testing encima y muchísimos usuarios usandolos se encuentran decenas y decenas de errores cada vez que se hace una auditoría del código (vease el caso de gcc), imaginate los programas que usa menos gente (da miedo pensarlo), etc podría dar muchas más pero hay más cosas que hacer
Comentarios
Es muy simplista lo que dice. El peor enemigo del código? pues es un tradeoff entre eficiencia y mantenimiento. A mayor eficiencia, más optimo uso de los recursos y mayor velocidad, peor es el mantenimiento ya que la programación orientada a objetos resulta demasiado costosa en términos de recursos, pero por otra parte es la única que permite separar claramente la implementación del código de su interface.
Por otra parte, esto de los lenguajes dinámicos y estáticos, el estático puro y duro es el C++ con su gran ventaja el fuerte chequeo de tipos en tiempo de compilación. Lenguajes más dinámicos, con enlace en tiempo de ejecución, son mucho más difíciles de depurar y generan una cantidad de código brutal.
Y tercer y último punto, lo importante son los algoritmos y como se implementen. El éxito de Google y de todas las companias de primera, reside aquí y eso exige un conocimiento más allá de lenguajes como Java, y más del tipo C++, un conocimiento profundo de punteros y recursividad (a ver quien es capaz de resolver estos sencillos ejercicios en C: http://www.joelonsoftware.com/articles/TestYourself.html ;)), que se ha perdido con la irrupción de estos modernos lenguajes que no son sino una colección de libraries que aumentan monstruosamente el tamano final del código como resultado
Como todo, existen ventajas e inconvenientes.
Probablemente la utilización de lenguajes dinámicos redujese la cantidad de código, pero probablemente también terminaría por reducir su legibilidad.
Los IDEs como Eclipse o Visual Studio ahorran horas y horas de depuración y testeo facilitando enormemente la tarea al programador.
Conclusión: lo que lo que ganaríamos por un lado, lo perderíamos por el otro. Así que como todo, sería cuestión de gustos. Llamadme inmovilista, pero personalmente me quedo con Java y C#, por muy "estáticos" que sean.
Lo que el autor sugiere es absurdo, los lenguajes de tipado dinámico son para hacer chapucillas rápidas, no los veo yo para un proyecto grande y serio. Tipado débil ==> Un montón de errores de tipado
También podemos usar lenguajes funcionales como Haskell que
1) Son tremendamente expresivos
2) Debido a 1) reducen enormemente la cantidad de código que necesitas
3) Son de tipado estático, no fuerte como Java etc, no hay error de tipos posible en Haskell u OCaml (u otros).
#2 La OO la única que permite separar implementación e interfaz? Conoces algo más que C, Java y C++?
Programar en C en general es debido a una falta de sentido común, no suele merecer la pena, primero porque un código C siempre está plagado de errores, incluso en programas con muchísimo testing encima y muchísimos usuarios usandolos se encuentran decenas y decenas de errores cada vez que se hace una auditoría del código (vease el caso de gcc), imaginate los programas que usa menos gente (da miedo pensarlo), etc podría dar muchas más pero hay más cosas que hacer