¿Son significativas las comparaciones de idiomas? [cerrado]

El Dr. Bjarne Stroustrup en su libro D&E dice

Varios revisores me pidieron que comparara C ++ con otros lenguajes. Esto he decidido no hacerlo. De este modo, he reafirmado una visión duradera y firmemente sostenida: "Las comparaciones de idiomas rara vez son significativas e incluso con menos frecuencia son justas". Una buena comparación de los principales lenguajes de programación requiere más esfuerzo del que la mayoría de las personas está dispuesta a gastar, experiencia en una amplia gama de áreas de aplicación, un mantenimiento rígido de un punto de vista imparcial e imparcial y un sentido de justicia. No tengo tiempo, y como diseñador de C ++, mi imparcialidad nunca sería totalmente creíble.

- El diseño y la evolución de C ++ (Bjarne Stroustrup)

¿Están de acuerdo con esta afirmación " Language comparisons are rarely meaningful and even less often fair"?

Personalmente, creo que comparar un lenguaje X con Y tiene sentido porque da muchas más razones para amar / despreciar X / Y :-P

¿Qué piensan ustedes?

¡Me encanta comparar lenguajes de programación!

comparo Java con una brisa cálida con un toque de lluvia

comparo C # con un hermoso día de primavera con suficientes nubes blancas y esponjosas para mantener feliz el cielo

comparo C con un mazo en una habitación llena de vidrio

comparo C ++ con una bolsa de mazos en un mundo de cristal

comparo VB con un viejo juguete de cuerda que se hunde en una bañera

comparo PL / 1 con un yunque oxidado, atornillado al piso

¿Con qué los comparas?

Creo que Stroustrup es completamente correcto. La comparación adecuada de dos idiomas por sus méritos técnicos requiere suficiente familiaridad con ambos para escribir código idiomático y usar los mismos patrones de diseño que normalmente usan los programadores que son muy productivos en ambos idiomas. Alguien que no tenga ese nivel de conocimiento de ambos idiomas puede ver cosas que no están explícitamente provistas por el idioma con el que no está tan familiarizado, y asumir que habrá problemas como resultado.

Por ejemplo, alguien que no usa Python regularmente puede asumir que los usuarios de Python regularmente tienen problemas debido a la sangría. O alguien que no esté familiarizado con Common Lisp puede observar la falta de bibliotecas pulidas, pero no sabe que el FFI es lo suficientemente poderoso como para escribir envoltorios para bibliotecas C con un esfuerzo nominal. Alguien que no esté familiarizado con Ruby puede ver la falta de tipeo estático y asumir que los errores de tipo serían un problema importante. Finalmente, alguien que no esté familiarizado con Haskell puede ver la falta de asignación y asumir que no puede manejar el estado.

Ahora todo esto supone que los idiomas en realidad se comparan solo por sus méritos técnicos.

Un lenguaje es una herramienta. Dicho esto, he visto herramientas realmente muy malas antes. Nadie quiere trabajar con un martillo cuya cabeza puede volar y golpear a otro carpintero en el estómago. Del mismo modo, si notó que el martillo de su compañero de trabajo estaba en esa forma, probablemente se alejaría de ellos cuando lo usaran.

También es importante entender realmente qué herramienta es. No puedes usar un destornillador y un martillo indistintamente (aunque algunos lo intentan desesperadamente). Demonios, ni siquiera puedes usar todos los martillos indistintamente; necesitas un trineo para algunas cosas, un mazo para otras y una tachuela para otras. Si usa la herramienta inadecuada, en el mejor de los casos, hará un trabajo peor, en el peor de los casos, se lesionará a usted mismo o a un compañero de trabajo.

En otras palabras, la comparación de idiomas es útil porque puede prevenir accidentes laborales. Tomando lo anterior de la metáfora; Es difícil saber sin comparar si un idioma dado es un mazo, un destornillador, un dremel o una sierra de mesa, porque (a diferencia de las herramientas físicas) no se puede saber con solo mirar. Debe pensar en las características que ofrece, verlo en acción (tratando de leer piezas significativas de una gran base de código escrita en él) e, idealmente, probarlo usted mismo también. Tenga cuidado de no cometer el error de simplemente escribir Cobol en Python (por ejemplo). Necesitas usar el nuevo idioma idiomáticamente, lo que significa aprenderlo bien. Esta es probablemente la razón por la que Bjarne dice que la mayoría de las personas no se esfuerzan lo suficiente para una comparación útil.

El tipo de comparación que comienza con "Me gusta Blub" y continúa con "Bueno, me gusta Blub ++" es completamente inútil. Si termina seleccionando un idioma, todo lo que realmente le dice es quién es más persuasivo en un grupo determinado y / o qué compañía de idiomas tiene el mayor presupuesto publicitario. Si analiza lo que puede hacer un idioma, para qué tareas es adecuado y cuáles son sus deficiencias sin recurrir a argumentos irrazonables o prejuicios personales, eso puede ser realmente útil.

Eso, excepto en algunas excepciones raras (y - raras - como "ocurre una o dos veces en la vida útil de un sistema solar"), generalmente conduce a guerras lingüísticas, en una variante más o menos fuerte, y muy raramente deja algo de práctica y conclusiones útiles.

Los idiomas son herramientas, no religiones. No compara un martillo con un destornillador, pero utiliza el que mejor se adapta a su tarea y forma de pensar / educación / nivel de abstracción necesario. Además, dado que quien realiza la comparación está sesgado por el hecho de que conoce al menos uno de los dos, o al menos prefiere uno de los dos, es difícil encontrar un criterio verdaderamente objetivo para compararlos (existen excepciones).

Si tratamos los idiomas como productos y a todos los desarrolladores como el mercado, podemos llegar a algunas conclusiones interesantes:

1. Los productos no siempre compiten. Por ejemplo, Haskell no resuelve los mismos problemas que Java, que no resuelve los mismos problemas que Assembly, que no resuelve los mismos problemas que Prolog. Un desarrollador, en diferentes situaciones, puede usar todos estos idiomas. La comparación implica competencia por la superioridad. Por lo tanto, no tiene ningún sentido comparar idiomas que no compiten.
2. La visibilidad en el mercado significa que el producto ya ha demostrado ser útil para alguien. Es decir, puedes comparar Ruby y Python todo lo que quieras: la gente lo hace todo el tiempo. De alguna manera, eso no parece cambiar la opinión de nadie (o si lo hace, la misma cantidad de personas cambia de opinión en la otra dirección). De la manera que importa, Ruby y Python son equivalentes. Es como dos grandes compañías de refrescos que hacen comparaciones "científicas" de sus productos. Un estudio muestra que Coca-Cola es superior, mientras que el otro muestra que Pepsi es superior. Incluso si los datos son confiables, no significan nada. Todos sabemos que son refrescos perfectamente buenos (lenguajes de programación) y que uno simplemente atrae más o menos a mi gusto personal.
3. Las comparaciones de idiomas son una forma de marketing geek. Si hubiera un lugar perfectamente objetivo para comenzar una comparación, podrían ser útiles. Por supuesto que no. Cualquiera que se moleste en hacer una comparación está tratando de confirmar un sesgo existente. Están tratando de vender un idioma. Nuevamente, si C ++ es tan malo o VB es tan malo o Erlang es tan malo, entonces ¿por qué las personas los usan? Puede hacer todos los reclamos que desee, pero eso no impide que sean útiles. Nuestra suposición es que las personas son demasiado tontas para ver la verdad frente a ellas, pero es probable que el "mercado" sea más complejo de lo que creemos. Las comparaciones nos dicen más sobre la persona que hace la comparación que sobre los productos que se comparan.

Stroustrup es completamente correcto.

La mayoría de las "comparaciones de lenguaje" se realizan con un resultado específico en mente, que es "mostrar" que uno es "superior" al otro.

A menudo, esto significa escribir un fragmento de código en ambos idiomas y medir el rendimiento del ejecutable generado, escribir un idioma altamente optimizado y el otro deliberadamente para un bajo rendimiento. Así es como se perpetúa el mito de "Java es lento". Las "pruebas" para "probar" están escritas deliberadamente para no medir el rendimiento de la ejecución del código Java sino el tiempo de inicio de la JVM. Tome, por ejemplo, una operación matemática simple y repítala 100 veces, hágalo en Java y C ++, compile la versión de C ++ con la optimización activada, la versión de Java sin indicadores de optimización, luego ejecute ambas versiones ejecutables. La clase Java se ejecutará mucho más tiempo que el ejecutable de C ++, simplemente debido al tiempo de inicio de la JVM. Esto no muestra que "Java es lento" pero que el tiempo de inicio de JVM significa que Java no es la herramienta adecuada para procesos de ejecución muy cortos (tampoco lo es un lenguaje interpretado ni nada que requiera cargar un tiempo de ejecución). Si la prueba se escribió correctamente para ejecutarse durante un período de varias horas con bases de código y sistemas de compilación que utilizan niveles equivalentes de optimización, los resultados son bastante diferentes (probablemente mostrando un rendimiento bastante similar).

Y ese es solo un ejemplo (con el que estoy familiarizado).

Como gerente de proyecto, debe hacer algunas comparaciones para elegir el idioma en el que se codificará su software. Los criterios pueden no ser técnicos:

• ¿Es el lenguaje adecuado para la tarea?
• ¿El idioma está disponible en todas las plataformas de destino?
• Calidad, fiabilidad y costo de los compiladores.
• ¿Hay programadores disponibles que conocen ese idioma? ¿Son competentes, caros, creativos?