edición general
11 meneos
532 clics

Comparativa de los principales lenguajes de programación [ENG]

Análisis de los lenguajes de programación mas utilizados

| etiquetas: programación
C++ ¿El peor?
¿Javascript mejor que C#?

A la hoguera con el articulista.
#3 Yo no estoy de acuerdo, pero esta bien expuesto. Merece una lectura
un hipster que acaba de descubrir la programación funcional, y cree que los demás son idiotas. Me aburro.
#6 xD xD xD
Es un modo de verlo, si.
#18 argumento falaz no, ¿si realmente C++ fuera tan malo como dice este artículo como es posible que sea un lenguaje elegido para motores de bases de datos, navegadores web, sistemas operativos, máquinas virtuales, videojuegos, motores gráficos...? Según la teoría de este artículo todo eso debería cambiar a todos los lenguajes que dice que son mejores que c++... pero a la hora de la verdad parece que el rendimiento de C++ es mucho más potente de lo que dice en el articulo... ya sólo decir que en C++ no hay concurrencia y que esta pensado para monothreading... si ya hasta el STL de c++11 en adelante existe el std::thread y std::mutex...
#19 Si. Es un argumento falaz. Que lo use mucha gente, o "los mejores" no demuestra absolutamente nada.

No dicenen ningún lado que en C++ no haya concurrencia. Solo que no es un lenguaje diseñado con SMP en mente. Y tiene razón.

El multiproceso existe desde siempre en C y en C++, pero NO es lo mismo.
El artículo es de alguien que no tiene ni idea de C++... si según el artículo es tan malo no se como se usa en todas las aplicaciones básicas y donde se requiere potencia y eficiencia desde sistemas operativos, videojuegos, motores de bases de datos, navegadores web, etc...
#7 Ni de Java... Pero te has marcado una falacia de campeonato.

El expone su criterio, y lo hace bastante bien, aunque en algunos ejemplos se ve que tiene ideas preconcebidas falsas
#14 Falacia para nada, C++ es el mejor lenguaje de programación de todos los tiempos a pesar de sus detractores y haters...
#17 Ahi no entro. Pero el argumento que das para sostener esa afirmación es falaz.
Artículo malo malo. Pero bueno creo que criticar a C++ debe tener su público.
#5 No. El articulo no es malo. Otra cosa es que no estes de acuerdo.

Yo no lo estoy, por ejemplo
Me pregunto cuál es su solución tan novedosa para reemplazar las excepciones...

Nowadays there are much better mechanisms of error handling. Possible errors should be type-checked at compile-time. Languages that do not use exceptions by default will be ranked higher.
#1 ¿Tratar los errores cuando se producen?

Dejarlos para las excepciones generara estructuras "try" de errores procrastinados curiosas y para, mi gusto, mas difíciles de auditar.
#2 Volver al chequeo del valor de retorno de toda la vida?

No, gracias.

Las excepciones te permiten tratar el error donde debe tratarse

El compilador te avisa. Si el programador quiere ser un incompetente no existe ni existirá en la tierra un lenguaje que lo evite
#2 Los errores no "se dejan para las excepciones", los errores se notifican para que sean tratados donde correspone.
#16 Utilizar las excepciones como flujo de control de errores deja de ser excepcional.

Mi preferencia por los "Códigos de error" frente a las excepciones se basa las siguientes premisas:
- Escribir código seguro utilizando excepciones es mas difícil que utilizando códigos de error y requiere generalmente de mas líneas.
- Las excepciones rompen la estructura del código al crear múltiples puntos de salida invisibles que dificultan la auditoría.
- Si no se dispone de recolector de…   » ver todo el comentario
#21 Utilizar las excepciones como flujo de control de errores deja de ser excepciona
Ese argumento es bueno.... xD xD xD xD . Si les llamamos "avisos" deja de existir ese "problema". Habrá que proponer un cambio de nombre....

Escribir código seguro utilizando excepciones es mas difícil que utilizando códigos de error y requiere generalmente de mas líneas.
FALSO. Es mucho más seguro el control mediante excepciones aunque simplemente sea porque el…   » ver todo el comentario
#23 Es mucho más seguro el control mediante excepciones aunque simplemente sea porque el compilador te OBLIGA a que hagas algo al respecto y no te permite dejar el resultado de la llamada "a lo que salga", como ocurre con los códigos de error.

====== test.cpp ====
#include <iostream>
#include <fstream>
using namespace std;

int main () {
ofstream f("test.txt");
f << "Hello world!";
f.close();
return 0;
}
====== fin ==========

¿Cree usted que el compilador dirá algo sobre mi temeraria despreocupación por la gestión de errores?
#25 Prueba en Java.

No soy experto en C++, pero en Java a no ser que sea una unchecked exception estas obligado a tratarla, de un modo u otro.

Si el C++ no lo hace el problema no es de la gestión de errores mediante excepciones. Por cierto, si gestionas el error con códigos de retorno el problema es el mismo
#25 Como dije, no uso C++, pero parece ser que precisamente los streams no lanzan excepciones y es necesario gestionar los errores mediante el valor de retorno...

Aunque se pueden habilitar.

stackoverflow.com/questions/10337915/ofstream-exception-handling
#29 Todo depende de los entornos de los que estemos hablando. Cada cosa tiene su nicho.
Los contenedores no se usan "para paliar los problemas de dependencias", tienen otras enormes ventajas mucho más allá de eso, y desde luego tienen muchos menos problemas de seguridad que una aplicación monolítica ejecutada en el propio sistema.

Y otra vez estamos hablando del tiempo que ahorra el desarrollador frente a la calidad y velocidad del sistema desarrollado en explotación. Da igual que…   » ver todo el comentario
#33
Hombre esa comparativa dice que Go viene usando el doble de RAM en prácticamente todas las pruebas... incluso hay una que usa un 5 veces más....

¿No es en la columna que pone "mem" ?

Y en cuanto a velocidad de ejecución bastante más lento. En reparto de trabajo entre CPU si que están parejos... esperaba mucho más de Go en eso.

Me dan exactamente igual las opiniones de Linux Torvalds. ¿Eres capaz de razonar por qué es mejor el tratamiento de errores con valores de retorno en…   » ver todo el comentario
Me ha gustado el artículo, aunque difiero en muchas cosas .....
No veo ningún inconveniente a la gestión de errores con excepciones, por ejemplo. Me parece un gran avance.

Tampoco veo ventajas en los objetos inmutables en aplicaciones "normales" que superen los inconvenientes.

Valorar la velocidad de compilación igual que la de ejecución me.parece directamente una idiotez.

Un articulo muy interesante, si.
#38 Pues depende lo que se quiera gastar en hardware y de la tarea a realizar.

Que no se me entienda mal. No estoy criticando a Go, seguro que es un gran lenguaje y tiene su nicho, como todos. Pero algunas razones para poner unos lenguajes por encima de otros del artículo me parecen profundamente equivicadas.

Go sera un gran lenguaje. Pero prefiero un Kernel de Linux en C.
Si es por eso...:

$cat 100mb.c
#include <stdio.h>

void main(void) {
 printf("Hola Mundon");
}

$gcc 100mb.c -o 100mb
$./100mb
Hola Mundo
$ls -ltra 100mb
rwxrxr-x 1 xavi xavi 16600 dic 12 21:01 100mb
#24 Ciertamente estoy un 2% mas cerca de los 100MB que usted. :troll:

Esta claro que usted enlaza en "dinámico". Las ventajas del estático en mi caso es un despliegue muy sencillo y carente de contratiempo.

Por ejemplo, un aplicativo con servidor http/s, tls, cliente postgresql, plantillas html, traducciones, validaciones de formularios, etc se queda el binario en 16 MB. La compilación de todo tarda 2 segundos y los únicos requisitos de este binario para funcionar son: github.com/golang/go/wiki/MinimumRequirements
#27 La unica ventaja del enlace estatico es la no dependencia de librerías externas. Y tiene muchos inconvenientes, como el parcheo de bugs o el uso de RAM.
#28 Usted conoce como son los usos modernos, para paliar los problemas de las dependencias en los despliegues se utilizan contenedores que tienen los mismos o mayores problemas de mantenimiento y seguridad.

Con Go actualizar todas las dependencias y generar un nuevo binario puede llevarte entre 2 y 5 minutos en proyectos grandes (siempre utilizando librerías nativas en GO, no enlazando a librerías C), un tiempo similar a actualizar las librerías de todo el sistema si hablamos de "Como…   » ver todo el comentario
#30 Estas comparando un lenguaje de máquina virtual contra un lenguaje compilado. No es una comparación justa. Si comparas con lenguajes "de su segmento" como C/C++ te encontrarás con un uso de RAM muy superior a veces más del 100% superior.
#32 ¿esta usted seguro?

benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.htm

Podemos venirnos arriba y rememorar las "llameantes" opiniones de Linus Tolvards en LKML sobre las excepciones en C++ y su "seguridad".
#35 Dudo que pueda dejarlo en 1kb como estático. Eso solo lo creo posible en asm y utilizando solo llamadas al kernel.

Deben ser proyectos con muchas librerías incluidas o una cantidad importante de símbolos.
Es el precio a pagar por disminuir las dependencias. ¿Pero eso influye en el rendimiento?
#36 Hombre, menos de 1kb, no pero en un simple hola mundo se consigue un ahorro apreciable en C (en C++ supongo que ocupará algo más)

xavi@jupiter:~$ cat 100m.c
#include <stdio.h>

void main(void) {
 printf("Hola Mundo!n");
}
xavi@jupiter:~$ gcc --static 100m.c -o 100m
xavi@jupiter:~$ ./100m
Hola Mundo!
xavi@jupiter:~$ ls -ltra 100m
rwxrxr-x 1 xavi xavi 782736 dic 13 01:33 100m
xavi@jupiter:~$
#37 Sería increíble que con el recolector y el "runtime" ocupara menos el binario de Go.

Las realidades que no le voy a discutir son:
Compilación rápida != optimización extrema
Recursos con recolector > recursos sin recolector
Tamaño binario estático > tamaño binario dinámico

Pero lo interesante creo que es:
¿afecta negativamente el tamaño del binario en sus proyectos al rendimiento, a las funcionalidades?
¿son tamaños inasumibles?
Why is C++ so bad? In my opinion, the biggest reason is its age. C++ was designed long ago, in 1979. At that time the designers lacked experience and had no idea what to focus on. Ahi dejé de leer
En fin, menudo despropósito xD

Creo que estamos ante el típico programador al que solo le importa su tiempo, y no el de sus usuarios. Decir que C++ es lento, o que el “startup time” de Go, con sus binarios de 100MB, su modelo de inicialización y su runtime, es mejor que C++.

Creo que en general solo ha leído un poco sobre los lenguajes que compara y se ha montado su película. Sobra teoría y falta experiencia en este artículo.
#8 Si. Eso me llamó la atención. Que valore el "tiempo en compilar" y la velocidad de ejecución o el uso de RAM le de igual...

Debe ser de esos programadores de "si te va lento, compra una máquiina más potente" de hoy en día. Tenemos ordenadores órdenes de magnitud más potentes para hacer lo mismo a la misma velocidad.... Si se optimizara como antes....
#8 Vamos a por los 100MB.

$ go version
go version go1.15.6 linux/amd64
$ cat 100mb.go
package main

import (
 "fmt"
)

func main() {
 fmt.Println("Hello world!")
}

$ go build 100mb.go
$ ./100mb
Hello world!
$ ls -ltra 100mb
rwxrwxrx 1 luser luser 2034781 dic 12 19:58 100mb

Me he quedado corto. <:(

Go no esta tan lejos de C++ en rendimiento con algunas ventajas importantes como la portabilidad sin lineas adicionales.
benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.htm
#22 un hello world por encima de 2MB te parece poca cosa? Eso mismo en C++ lo puedes dejar en menos de 1KB.

Trabajo profesionalmente con Go y tenemos binarios que se van hasta los 80MB.
comentarios cerrados

menéame