Autor
Ha, pero si yo nunca dije que QBasic es mejor que cualquier compilador de hoy dia de Cpp. Al contrario, recuerdo haber dicho que use qBasic como ejemplo de lo peor que haya existido.
Te cito:
Es más, invertiendo tiempo se puede hacer que le infame compilador QBasic de Microsoft de los 80 genere codigo más optimizado que VC++ o Intel C++. Pero claro, ¿Quien va a invertir en eso?
¿Entonces a qué te refieres?
Lo que en realidad discuto es que aqui se habló de que Rust es más rápido que Cpp.
Lo cierto es que en el mundo de la programación aparece con demasiada frecuencia la intención de optimizar y hacer todo más rápido cuando lo cierto es que en el 90% de los casos no es necesario. Puedo entender que si un código tiene que ejecutarse en una millonésima de segundo o si resulta que la función en cuestión se llama de forma iterativa millones de veces pueda hacerse necesario algún tipo de optimización... pero una aplicación de escritorio que lee 1000 entradas de una base de datos y presenta una serie de datos, salvo que el programador sea un inutil o surja un requisito específico, no suele necesitar ningún tipo de optimización.
El ser humano mide el tiempo en segundos, minutos y horas y no es por casualidad. No somos capaces de notar la diferencia entre un evento de una milésima de segundo y otro de media milésima... de hecho nuestra vista no suele alcanzar los 100 imágenes por segundo, es decir, no es capaz de distinguir dos eventos que se producen en un intervalo menor a una centésima de segundo. Es más, aunque el evento que se lanza al presionar un botón tardase cerca de medio segundo (que ya es tiempo con los procesadores actuales) el usuario no le daría mayor importancia porque, simplemente, es un tiempo demasiado pequeño para percibirlo.
En cualquier caso, al que le preocupe el rendimiento y la velocidad, que pruebe a programar sistemas distribuidos y a programar los núcleos CUDA de las tarjetas gráficas, pero vamos, que se pueden contar con los dedos de una mano las situaciones en las que hace falta llegar a este extremo: ciencias experimentales, cálculos balísticos... vamos, algoritmos que se suelen aplicar en superordenadores.
Pero vamos, que las peleas en cuanto a la velocidad y rendimiento no es algo nuevo...
E insisto, ¿Como un lenguaje puede ser más rápido que otro en sentido que produce mejores ejecutables?
Cuando en realidad es el compilador de dicho lenguaje que es el encargado de esa tarea.
Cuando en realidad es el compilador de dicho lenguaje que es el encargado de esa tarea.
A ver, un lenguaje, perdón, el código generado a partir de de un lenguaje de programación puede ser por definición más lento que otro diferente, es un echo. Por ejemplo lo dicho, declarar una variable en C++ puede suponer una cantidad indeterminada de llamadas anidadas, mientras que en C tienes más control sobre este mismo proceso.
Como te comenté, los compiladores encargados de lidiar con un lenguaje de programación en completo pueden llegar a hacer maravillas en cuanto a optimización, pero éstas tienen un límite, ya que no pueden impedir, en el caso concreto del C++, las llamadas encadenadas que se producen en los constructores en herencia.
La naturaleza propia de un lenguaje de programación va a marcar la hoja de ruta del proceso de compilación y eso va a limitar la capacidad del compilador para proporcionar código eficiente.
Si se quiere comparar dos lenguajes, pues el parametro a mi criterio es la versatilidad por ejemplo. Pero de ninguna manera velocidad.
Comparar lenguajes de programación siempre es polémico. Generalmente no se pueden comparar... es como comparar dos frutas, cómo catalogas el tamaño? y el sabor? y el color? ... la versatilidad tampoco se libra, ¿cómo se mide?
Se pueden hacer estudios más o menos específicos que apliquen un baremo establecido previamente para intentar dar una nota a cada lenguaje, pero aun así sigue siendo algo totalmente subjetivo. Cada lenguaje se ha creado pensando en satisfacer una serie de necesidades más o menos concretas.
En línea
