Portada
mis comunidades
otras secciones
#4:
Genial...
Seguid con el Java ese, seguid... Los hombres de verdad programan en C
Flame en 3,2,1...
Seguid con el Java ese, seguid... Los hombres de verdad programan en C
Flame en 3,2,1...
#16:
#14 Evidentemente es así. C/C++ es la madre de todo, pero la informática moderna estaría en el Pleistoceno sin lenguajes que aportan una capa de abstracción, de hecho C/C++ no es más que otra capa de abstracción del código nativo de una arquitectura. Hoy en día estaríamos en pañales si no fuera por Java, ECMAScript, COBOL, PHP, etc... C/C++ contruye lenguajes no por que sea mejor, sino porque necesitamos usarlo para construir mejores lenguajes multipropósito.
Lo mismo ocurre ya con Java, que ya no es tanto lenguaje como palataforma, y vía JVM se usa para 'elevar' otros lenguajes como Clojure o Scala.
Lo mismo ocurre ya con Java, que ya no es tanto lenguaje como palataforma, y vía JVM se usa para 'elevar' otros lenguajes como Clojure o Scala.
#15:
Lo importante no es cuál se usa más, sino que los que se usen sean son los correctos para ese tipo de aplicación.
Ya sigo yo con el flame:
- Hey, yo hago drivers con Javascript.
- Buah, yo envío patches del kernel escritos en COBOL y me la sopla que Linus me escupa en la cara.
- Bah, yo reinvento la rueda todas las semanas haciendo en C/C++ cosas que son más eficientes en Java, coz I'm worth it.
- Para huevos lo míos, que compilo Java en nativo para usarlo en entorno CGI... menudos blandengues los que piensan más en la arquitectura que en la escalabilidad.
- Muahaha, no tenéis ni idea, hay que seguir el hype y hacerlo todo con lenguajes funcionales... ya veréis cuando convierta el API de Windows y haya que usar functors en todas las llamadas. Sus váis a cagar.
- Milongas. Yo estoy creando un compilador inline para poder sustituir ECMAScript por C... Estoy seguro de que acceder directamente a la memoria hará a los navegadores más seguros. Muahahaha, los tengo cuadraos!
...
Yo propongo que usemos todos el mismo lenguaje. Basta ya de independentismos, ¡Muerte al disidente! Lo podemos llamar C!++U (Convergencia Sin Más Mas Unión)
Ya sigo yo con el flame:
- Hey, yo hago drivers con Javascript.
- Buah, yo envío patches del kernel escritos en COBOL y me la sopla que Linus me escupa en la cara.
- Bah, yo reinvento la rueda todas las semanas haciendo en C/C++ cosas que son más eficientes en Java, coz I'm worth it.
- Para huevos lo míos, que compilo Java en nativo para usarlo en entorno CGI... menudos blandengues los que piensan más en la arquitectura que en la escalabilidad.
- Muahaha, no tenéis ni idea, hay que seguir el hype y hacerlo todo con lenguajes funcionales... ya veréis cuando convierta el API de Windows y haya que usar functors en todas las llamadas. Sus váis a cagar.
- Milongas. Yo estoy creando un compilador inline para poder sustituir ECMAScript por C... Estoy seguro de que acceder directamente a la memoria hará a los navegadores más seguros. Muahahaha, los tengo cuadraos!
...
Yo propongo que usemos todos el mismo lenguaje. Basta ya de independentismos, ¡Muerte al disidente! Lo podemos llamar C!++U (Convergencia Sin Más Mas Unión)
#1:
Un amigo programador del Linus me dijo que en Mubutu lo hacen en Putón o algo así
#101:
#97 NO, no es muy lento para el 99% de las aplicaciones que se hacen.
Ademas si hay alguna parte que haga de cuello de botella puedes hacerla en C y usarla en python.
Y tardas la decima parte en programar....
PYTHON ES POESIA
Es arte. La vida de los programadores es una mierda pq utilizan basuras como C++ o java que no hacen mas que joderles la salud.
Ademas si hay alguna parte que haga de cuello de botella puedes hacerla en C y usarla en python.
Y tardas la decima parte en programar....
PYTHON ES POESIA
Es arte. La vida de los programadores es una mierda pq utilizan basuras como C++ o java que no hacen mas que joderles la salud.
#129:
Hola a todos! #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27, #28, #29, #30, #31, #32, #33, #34, #35, #36, #37, #38, #39, #40, #41, #42, #43, #44, #45, #46, #47, #48, #49, #50, #51, #52, #53, #54, #55, #56, #57, #58, #59, #60, #61, #62, #63, #64, #65, #66, #67, #68, #69, #70, #71, #72, #73, #74, #75, #76, #77, #78, #79, #80, #81, #82, #83, #84, #85, #86, #87, #88, #89, #90, #91, #92, #93, #94, #95, #96, #97, #98, #99, #100, #101, #102, #103, #104, #105, #106, #107, #108, #109, #110, #111, #112, #113, #114, #115, #116, #117, #118, #119, #120, #121, #122, #123, #124, #125, #126, #127
(Programado en Excel)
(Programado en Excel)
#35:
#4 #21 #23 #25 #34 #33 #27 Los hombres de verdad programan en Cobol en monitores de letras verdes sobre fondo negro. Las pantallas desarrolladas para el usuario no tienen colorcitos, ni botones, ni listas ni mariconadas de esas. Solo tienen opciones (1,2,3,4) y solo puedes escribir letras y números. Los accesos a base de datos se rascan a pelo, nada de frameworks para nenazas. Y no sigo porque no quiero provocar pesadillas.
#83:
#56 En los tiempos que corren se mezcla la eficiencia con la efectividad y la productividad, apesar de la incorreción. Todo depende de si analizas, modelas o codificas.
¿Quieres hacer un programa de escritorio o una librería que implemente funciones y algoritmos troncales (como por ejemplo BTrees)? Hazlo en C, será más eficiente.
¿El diseño se puede contemplar como una simulación? Hazlo en C++, será más eficiente en diseño aunque su ejecución lo sea menos. En efecto, incuso entre C y C++ existen diferencias, sean de diseño, mantenimiento o codificación (que le pregunten a Torvalds por qué rechaza el uso de C++ en Linux).
¿Quieres diseñar una arquitectura completa, desde cero, compleja, distribuida y con uso extensivo de estructuras con acceso concurrente? Usa Java (o similares), será más eficiente.
¿Qué es más eficiente, Apache MPM Prefork o un servidor Java NIO? El segundo.. efectividad en el tratamiento de instrucciones no significa efectividad de la arquitectura; aunque la diferencia la hace el diseño, no el código o la herramientas.
Te pongo u ejemplo que he sufrido las últimas semanas:
Un servidor que moría por trashing y lo que lo mataba era el motor V8 (Javascript Engine programado en C++). V8 es sumamente eficiente y una fantástica pieza de software, pero un leve goteo de memoria que pasaría desapercibido tras días de uso en el navegador Chrome, es un killer en un entorno exigente con la gestión de memoria. Tras cambiar el motor y usar Rhino (de Mozilla, en Java) el servidor sobrevive sin problemas. La eficiencia en ejecución es menor, obviamente, aunque no sobrepasa el 7% dado que las llamadas JNI no son eficientes si la librería no está pensada para ese fin, como es el caso. Así que incluso una librería C++ perfecta puede ser ineficiente en ese entorno. En efecto: el entorno en el que trabaja cada uno, no es el entorno en el que trabajan los demás. En este caso, un servidor con trashing no es eficiente, ni efectivo, ni productivo.
Ya, vale, el problema es el goteo, no C++. Evidente, pero es que incluso un recolector de memora estilo Java puede ser más eficiente a largo plazo que la asignación manual: más eficiente porque conserva tus recursos, a costa de consumir más de ellos (paradoja) y de hacer más lenta la asignación y direccionamiento.
En resumen: ya sabemos la asignación manual de memoria es más eficiente en C/C++, pero deja de serlo cuando te olvidas del concepto 'programa' y piensas en las 'arquitecturas' actuales. No hablo de eficiencia en el ciclo de producción, sino en eficiencia efectiva de ejecución y despliegue.
El tema de la 'comodidad' del código (codificación, diseño, análisis...) ya es otro asunto. Llevo toda la vida programando en C y C++, incluso formando profesionales en su uso, así que, como comprenderás, C++ no me resulta más complejo que Java, como dices en general. Ese es otro de los mitos, si usas una cosa es porque no sabes usar la otra (o no la usas bien). Si dictaminas a favor o en contra, igual.
Ahí está el problema. Parece que los todos programadores se dedican a lo mismo que nosotros pero con una herramienta incorrecta. Afortunadamente no es así. Me he hartado de desarrollar programas de gestión en C++, pero ahora diseño arquitecturas C/S completas y uso la que considero mejor herramienta para ese fin, en este caso es Java, aunque sigo sacando parte de la lógica a C para rutinas de bajo nivel o procesos offline desacoplados del servidor. No soy racista con el código.
No se trata de demostrar que implementar el algoritmo de generación de números de Fibonacci es más eficiente en Java (que lo es, con truco), el problema -al menos el mío- es lo difícil que resulta encontrar un programador C/C++ que sepa que detrás de esa afirmación hay truco.
¿Quieres hacer un programa de escritorio o una librería que implemente funciones y algoritmos troncales (como por ejemplo BTrees)? Hazlo en C, será más eficiente.
¿El diseño se puede contemplar como una simulación? Hazlo en C++, será más eficiente en diseño aunque su ejecución lo sea menos. En efecto, incuso entre C y C++ existen diferencias, sean de diseño, mantenimiento o codificación (que le pregunten a Torvalds por qué rechaza el uso de C++ en Linux).
¿Quieres diseñar una arquitectura completa, desde cero, compleja, distribuida y con uso extensivo de estructuras con acceso concurrente? Usa Java (o similares), será más eficiente.
¿Qué es más eficiente, Apache MPM Prefork o un servidor Java NIO? El segundo.. efectividad en el tratamiento de instrucciones no significa efectividad de la arquitectura; aunque la diferencia la hace el diseño, no el código o la herramientas.
Te pongo u ejemplo que he sufrido las últimas semanas:
Un servidor que moría por trashing y lo que lo mataba era el motor V8 (Javascript Engine programado en C++). V8 es sumamente eficiente y una fantástica pieza de software, pero un leve goteo de memoria que pasaría desapercibido tras días de uso en el navegador Chrome, es un killer en un entorno exigente con la gestión de memoria. Tras cambiar el motor y usar Rhino (de Mozilla, en Java) el servidor sobrevive sin problemas. La eficiencia en ejecución es menor, obviamente, aunque no sobrepasa el 7% dado que las llamadas JNI no son eficientes si la librería no está pensada para ese fin, como es el caso. Así que incluso una librería C++ perfecta puede ser ineficiente en ese entorno. En efecto: el entorno en el que trabaja cada uno, no es el entorno en el que trabajan los demás. En este caso, un servidor con trashing no es eficiente, ni efectivo, ni productivo.
Ya, vale, el problema es el goteo, no C++. Evidente, pero es que incluso un recolector de memora estilo Java puede ser más eficiente a largo plazo que la asignación manual: más eficiente porque conserva tus recursos, a costa de consumir más de ellos (paradoja) y de hacer más lenta la asignación y direccionamiento.
En resumen: ya sabemos la asignación manual de memoria es más eficiente en C/C++, pero deja de serlo cuando te olvidas del concepto 'programa' y piensas en las 'arquitecturas' actuales. No hablo de eficiencia en el ciclo de producción, sino en eficiencia efectiva de ejecución y despliegue.
El tema de la 'comodidad' del código (codificación, diseño, análisis...) ya es otro asunto. Llevo toda la vida programando en C y C++, incluso formando profesionales en su uso, así que, como comprenderás, C++ no me resulta más complejo que Java, como dices en general. Ese es otro de los mitos, si usas una cosa es porque no sabes usar la otra (o no la usas bien). Si dictaminas a favor o en contra, igual.
Ahí está el problema. Parece que los todos programadores se dedican a lo mismo que nosotros pero con una herramienta incorrecta. Afortunadamente no es así. Me he hartado de desarrollar programas de gestión en C++, pero ahora diseño arquitecturas C/S completas y uso la que considero mejor herramienta para ese fin, en este caso es Java, aunque sigo sacando parte de la lógica a C para rutinas de bajo nivel o procesos offline desacoplados del servidor. No soy racista con el código.
No se trata de demostrar que implementar el algoritmo de generación de números de Fibonacci es más eficiente en Java (que lo es, con truco), el problema -al menos el mío- es lo difícil que resulta encontrar un programador C/C++ que sepa que detrás de esa afirmación hay truco.
#74:
Se están mezclando churras con merinas. Eficiencia y tiempo de desarrollo están inversamente relacionados. Hay 3 grupos bien diferenciados:
1. Ensamblador
2. Lenguajes compilados
3. Lenguajes interpretados, de los cuales:
3a. Pseudocompilados que usan máquinas virtuales ejecutando byte codes.
3b. Que usan JIT o compilación al vuelo.
3c. Con un intérprete clásico.
Pues bien con respecto a esta escala 1>2>3a>3b>3c en eficiencia y 1
1. Ensamblador
2. Lenguajes compilados
3. Lenguajes interpretados, de los cuales:
3a. Pseudocompilados que usan máquinas virtuales ejecutando byte codes.
3b. Que usan JIT o compilación al vuelo.
3c. Con un intérprete clásico.
Pues bien con respecto a esta escala 1>2>3a>3b>3c en eficiencia y 1
#23:
#21 Los hombres de verdad programan manipulando mariposas(o aún más hardcore mosquitos) para que provoquen microalteraciones en las corrientes de aire que a su vez causen microalteraciones del clima que logren que los rayos cosmicos atraviesen la atmosfera, golpeen la superficie del disco duro y alteren el valor de un bit.
#7:
Ensamblador...para hombres con pelo en el pecho y poco en la cabeza.
Comentarios
#23 Los hombres de verdad están practicando sexo mientras vosotros discutís sobre lenguajes de programación
#4 #21 #23 #25 #34 #33 #27 Los hombres de verdad programan en Cobol en monitores de letras verdes sobre fondo negro. Las pantallas desarrolladas para el usuario no tienen colorcitos, ni botones, ni listas ni mariconadas de esas. Solo tienen opciones (1,2,3,4) y solo puedes escribir letras y números. Los accesos a base de datos se rascan a pelo, nada de frameworks para nenazas. Y no sigo porque no quiero provocar pesadillas.
#35 #4 #21 #23 #25 #34 #33 #27 los hombres de verdad no programan, ni miran meneame, salen a la calle, conocen gente, conocen personas del otro sexo (o del mismo) se aparean, tienen hijos, etc etc
#37 buen intento de flame
#37 Pero que dices, insensato, los ingenieros no tiempo para eso
#37 de lo que se deduce que tu no eres un hombre de verdad.
#25 eso no es nada, los hombres de verdad tienen sexo mientras programan. Ambos con magnificos resultados.
Genial...
Seguid con el Java ese, seguid... Los hombres de verdad programan en C
Flame en 3,2,1...
#4 Los hombres de verdad programan con un interruptor que genera señales eléctricas que producen cambios en la superficie magnética del disco duro, creando los 1s y0s necesarios para producir el código máquina de sus programas
#21 Los hombres de verdad programan manipulando mariposas(o aún más hardcore mosquitos) para que provoquen microalteraciones en las corrientes de aire que a su vez causen microalteraciones del clima que logren que los rayos cosmicos atraviesen la atmosfera, golpeen la superficie del disco duro y alteren el valor de un bit.
#23 Positivo por la referencia xkcdiana
A mí me la suda. Yo enchufo un telégrafo al micro y ya le paso las órdenes que me apetecen sobre la marcha.
#23 Mierda. Me superaste.
#4 #21 #27 Los hombres de verdad programan sobre un chip, y no necesitan software.
#21 Falso. Los hombres de verdad programan con mariposas.
https://xkcd.com/378/
Y por supuesto que hay un comando de Emacs que ya lo hace.
#15 #21 #4 ni puta idea..
los hombres de verdad programan en asm#4 Los hombres de verdad programan en ensamblador, saben identificar la cabecera de un gif en hexadecimal y usan el bloc de notas en lugar del Notepad++
#27 ¿Bloc de notas? Pero... peroperopero... Tú no conoces el vi, no?
#44 ¿Vi? ¿Qué mariconada es esa? Los hombres de verdad escriben con `cat`.
#44 Estamos hablando de hombres, al que le guste el vi, sinceramente, que se mire el adn por que eso no es humano.
#44 Yo si conozco el vino… ¡HICS!
#4 los hombres de verdad programan con tarjetas perforadas y una manivela para dar luz
El sitio en general no me convence porque está muy escorado hacia aplicaciones grandes de escritorio. De esas es cierto que la mayoría están hechas en C++ pero todo el software a medida que se desarolla en el mundo (que es muchísimo más que estas pocas aplicaciones de escritorio) casi nunca se escribe en C++. Hay mucho Java, los bancos siguen usando COBOL, .NET, ...pero C++ poquito.
#4 Sé que el comentario es con intención trolera pero: Cuantas más facilidades da el lenguaje más productivo es el programador. Obviamente, para desarrolladoras comerciales esto es muy importante. Si lo haces por hobby seguramente no te importe tanto. Además ¿C?, es bastante primitivo y poco practicable para aplicaciones grandes. Tiene su sitio pero cada vez es más pequeño.
#52 Los lenguajes a los que haces referencia son de tipado dinámico/débil. ¿Qué quiero decir con esto? Básicamente que al hacer que el programador tenga que pensar menos haces al ordenador pensar más y esto hace que su rendimiento sea peor que el de los lenguajes de bajo nivel tipo C.
Al final lo que tienes que preguntarte es cuál es el mejor lenguaje para lo que deseas hacer. Para una aplicación de escritorio generalmente no hace falta utilizar C o C++, para algo de muy alto rendimiento (muy pocas: juegos, SO, aplicaciones web de millones de usuarios, etc.) no es una buena idea utilizar Python o Ruby.
Hola a todos! #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27, #28, #29, #30, #31, #32, #33, #34, #35, #36, #37, #38, #39, #40, #41, #42, #43, #44, #45, #46, #47, #48, #49, #50, #51, #52, #53, #54, #55, #56, #57, #58, #59, #60, #61, #62, #63, #64, #65, #66, #67, #68, #69, #70, #71, #72, #73, #74, #75, #76, #77, #78, #79, #80, #81, #82, #83, #84, #85, #86, #87, #88, #89, #90, #91, #92, #93, #94, #95, #96, #97, #98, #99, #100, #101, #102, #103, #104, #105, #106, #107, #108, #109, #110, #111, #112, #113, #114, #115, #116, #117, #118, #119, #120, #121, #122, #123, #124, #125, #126, #127
(Programado en Excel)
#4 Los hombres de verdad escriben en binario directamente.
C/C++ al poder...
Un amigo programador del Linus me dijo que en Mubutu lo hacen en Putón o algo así
#1 el Putón es BasiC, muy Visual, sobre todo en Java.
#1 Supongo querrás decir en Plutón, un lejano y frío lenguaje verbenero.
Lo importante no es cuál se usa más, sino que los que se usen sean son los correctos para ese tipo de aplicación.
Ya sigo yo con el flame:
- Hey, yo hago drivers con Javascript.
- Buah, yo envío patches del kernel escritos en COBOL y me la sopla que Linus me escupa en la cara.
- Bah, yo reinvento la rueda todas las semanas haciendo en C/C++ cosas que son más eficientes en Java, coz I'm worth it.
- Para huevos lo míos, que compilo Java en nativo para usarlo en entorno CGI... menudos blandengues los que piensan más en la arquitectura que en la escalabilidad.
- Muahaha, no tenéis ni idea, hay que seguir el hype y hacerlo todo con lenguajes funcionales... ya veréis cuando convierta el API de Windows y haya que usar functors en todas las llamadas. Sus váis a cagar.
- Milongas. Yo estoy creando un compilador inline para poder sustituir ECMAScript por C... Estoy seguro de que acceder directamente a la memoria hará a los navegadores más seguros. Muahahaha, los tengo cuadraos!
...
Yo propongo que usemos todos el mismo lenguaje. Basta ya de independentismos, ¡Muerte al disidente! Lo podemos llamar C!++U (Convergencia Sin Más Mas Unión)
#15
Te has olvidado de la almohadilla
#17 Y me he acordado, no te creas. Llamémoslo .NET, a secas. El viejo Visual Basic cumplió muy bien su cometido en su momento y es otro de esos lenguajes que ayudaron bastante a salir de la caverna. El Framework .NET sigue la misma línea de Java y es por ello igualmente válido, úsese el lenguaje 'almohadillado' que se use
#15 Me he leido todos los comentarios y aún le estoy dando vueltas a: "...haciendo en C/C++ cosas que son más eficientes en Java...". ¿Hay algo que se pueda hacer mucho más eficiente en C/C++ que en Java? ¿El qué?
¿O te refieres a eficiencia en tiempo de programación? Porqeu Java es increíblemente más fácil que C++, ahí sí que lo entendería...
#53 Si lo que vas a implementar no es crítico en tiempo de ejecución, vale. Pero mira lo que pasó con el front-end de búsquedas de Twitter, que utilizaba Ruby on Rails (muy sencillo de programar, muy bonito, etc.) y al final tuvieron que ir a morir a Java...
De todas formas coincido contigo, para aplicaciones comunes, lo mejor es apostar por el lenguaje que permita los desarrollos y mantenimientos más rápidos, siempre teniendo la vista en el horizonte por lo que pueda surgir.
#56 Absolutamente todos los algoritmos y estructuras de datos más comunes funcionan mucho más rápido si son programados en lenguajes compilados. Imagínate cosas más complejas. La máquina virtual de Java simplemente no puede competir con eso.
#61 "Absolutamente todos los algoritmos y estructuras de datos más comunes funcionan mucho más rápido si son programados en lenguajes compilados. Imagínate cosas más complejas. La máquina virtual de Java simplemente no puede competir con eso. "
No siempre. De hecho una optimización prematura puede dar peor resultado que una optimización dinámica como la de Python con Psyco en ia32.
http://psyco.sourceforge.net/
http://speed.pypy.org/
#56 La pregunta es de coña no?
#56 En los tiempos que corren se mezcla la eficiencia con la efectividad y la productividad, apesar de la incorreción. Todo depende de si analizas, modelas o codificas.
¿Quieres hacer un programa de escritorio o una librería que implemente funciones y algoritmos troncales (como por ejemplo BTrees)? Hazlo en C, será más eficiente.
¿El diseño se puede contemplar como una simulación? Hazlo en C++, será más eficiente en diseño aunque su ejecución lo sea menos. En efecto, incuso entre C y C++ existen diferencias, sean de diseño, mantenimiento o codificación (que le pregunten a Torvalds por qué rechaza el uso de C++ en Linux).
¿Quieres diseñar una arquitectura completa, desde cero, compleja, distribuida y con uso extensivo de estructuras con acceso concurrente? Usa Java (o similares), será más eficiente.
¿Qué es más eficiente, Apache MPM Prefork o un servidor Java NIO? El segundo.. efectividad en el tratamiento de instrucciones no significa efectividad de la arquitectura; aunque la diferencia la hace el diseño, no el código o la herramientas.
Te pongo u ejemplo que he sufrido las últimas semanas:
Un servidor que moría por trashing y lo que lo mataba era el motor V8 (Javascript Engine programado en C++). V8 es sumamente eficiente y una fantástica pieza de software, pero un leve goteo de memoria que pasaría desapercibido tras días de uso en el navegador Chrome, es un killer en un entorno exigente con la gestión de memoria. Tras cambiar el motor y usar Rhino (de Mozilla, en Java) el servidor sobrevive sin problemas. La eficiencia en ejecución es menor, obviamente, aunque no sobrepasa el 7% dado que las llamadas JNI no son eficientes si la librería no está pensada para ese fin, como es el caso. Así que incluso una librería C++ perfecta puede ser ineficiente en ese entorno. En efecto: el entorno en el que trabaja cada uno, no es el entorno en el que trabajan los demás. En este caso, un servidor con trashing no es eficiente, ni efectivo, ni productivo.
Ya, vale, el problema es el goteo, no C++. Evidente, pero es que incluso un recolector de memora estilo Java puede ser más eficiente a largo plazo que la asignación manual: más eficiente porque conserva tus recursos, a costa de consumir más de ellos (paradoja) y de hacer más lenta la asignación y direccionamiento.
En resumen: ya sabemos la asignación manual de memoria es más eficiente en C/C++, pero deja de serlo cuando te olvidas del concepto 'programa' y piensas en las 'arquitecturas' actuales. No hablo de eficiencia en el ciclo de producción, sino en eficiencia efectiva de ejecución y despliegue.
El tema de la 'comodidad' del código (codificación, diseño, análisis...) ya es otro asunto. Llevo toda la vida programando en C y C++, incluso formando profesionales en su uso, así que, como comprenderás, C++ no me resulta más complejo que Java, como dices en general. Ese es otro de los mitos, si usas una cosa es porque no sabes usar la otra (o no la usas bien). Si dictaminas a favor o en contra, igual.
Ahí está el problema. Parece que los todos programadores se dedican a lo mismo que nosotros pero con una herramienta incorrecta. Afortunadamente no es así. Me he hartado de desarrollar programas de gestión en C++, pero ahora diseño arquitecturas C/S completas y uso la que considero mejor herramienta para ese fin, en este caso es Java, aunque sigo sacando parte de la lógica a C para rutinas de bajo nivel o procesos offline desacoplados del servidor. No soy racista con el código.
No se trata de demostrar que implementar el algoritmo de generación de números de Fibonacci es más eficiente en Java (que lo es, con truco), el problema -al menos el mío- es lo difícil que resulta encontrar un programador C/C++ que sepa que detrás de esa afirmación hay truco.
#15 Yo programo en D
#c-64" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1581948/order/64">#64 Sí, habría que llenar el hueco desde C hasta F#
#85 No, si yo lo decía en serio http://dlang.org/
#92 Ya, ya, si lo conozco (de oídas). Pero me ha salido mal el chiste al poner "habría" en lugar de "había". Ahora que sabes mi intención me puedes poner aquí el negativo
Ensamblador...para hombres con pelo en el pecho y poco en la cabeza.
Yo programo el vídeo.
En tarjeticas perforadas programan en Bilbao.
#8 que en tarjetas perforadas no se programa, se almacena!
#20 ¿C/C++ han llegado a su límite tecnológico? ¿No adecuados para la programación multicore? ¿Mande?
Se están mezclando churras con merinas. Eficiencia y tiempo de desarrollo están inversamente relacionados. Hay 3 grupos bien diferenciados:
1. Ensamblador
2. Lenguajes compilados
3. Lenguajes interpretados, de los cuales:
3a. Pseudocompilados que usan máquinas virtuales ejecutando byte codes.
3b. Que usan JIT o compilación al vuelo.
3c. Con un intérprete clásico.
Pues bien con respecto a esta escala 1>2>3a>3b>3c en eficiencia y 1
#74 Toda la razón. Aunque lo que más me preocupa es la cantidad de gente que no conoce esto y defiende que Java es igual de rápido que C, por ignorancia o por querer ir a lo fácil. Cuando veo juegos en Java o Flash me jode un montón, en Symbian por ejemplo es un infierno encontrar cosas que no estén en Java y eso lastra muchísimo (y todos sabemos lo que ha pasado con symbian).
#c-76" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1581948/order/76">#76 Toda la razón. Aunque lo que más me preocupa es la cantidad de gente que no conoce esto y defiende que Java es igual de rápido que C, por ignorancia o por querer ir a lo fácil.
Java ES comparable a C o C++ en velocidad, asumelo de una vez.
Java is often Just-in-time compiled at runtime by the Java Virtual Machine, but may also be compiled ahead-of-time, just like C++. When Just-in-time compiled, its performance is generally:[36]
moderately slower than compiled languages such as C or C++,[37]
similar to other Just-in-time compiled languages such as C#,[38]
much faster than languages without an effective native-code compiler (JIT or AOT), such as Perl, Ruby, PHP and Python.
http://en.wikipedia.org/wiki/Java_performance
Es mas: a veces es mas rapido:
Java is in some cases equal to C++ on low-level and numeric benchmarks.[40]
Benchmarks often measure performance for small numerically-intensive programs. In some real-life programs, Java out-performs C. One example is the benchmark of Jake2 (a clone of Quake 2 written in Java by translating the original GPL C code). The Java 5.0 version performs better in some hardware configurations than its C counterpart.[41] While it's not specified how the data was measured (for example if the original Quake 2 executable compiled in 1997 was used, which may be considered bad as current C compilers may achieve better optimizations for Quake), it notes how the same Java source code can have a huge speed boost just by updating the VM, something impossible to achieve with a 100% static approach. For other programs the C++ counterpart runs significantly faster than the Java equivalent
#91 Si quieres argumentar hazlo en el idioma de Menéame por favor. Y no es más rápido, no sin librerías hechas en C al menos, como creo que es el caso de OpenGL. Si pierdes tiempo en traducir código lo pierdes y punto, eso no tiene vuelta de hoja.
"Java is often Just-in-time compiled at runtime by the Java Virtual Machine, but may also be compiled ahead-of-time, just like C++. When Just-in-time compiled, its performance is generally:[36]
moderately slower than compiled languages such as C or C++,[37]"
Con frecuencia (es decir, en la mayoría de los casos que conozco, con sus máquinas virtuales) es moderadamente más lento. No hay más preguntas.
#94 Con frecuencia no significa siempre ni nunca... Yo te digo que es comparable y hay pone que es moderadamente mas lento de modo que dice lo mismo que yo: no hay mucha diferencia.
Otra cosa es que no tengas ni idea de java... entonces si, todo sera mucho mas lento...
#98 Joder, pues es una diferencia moderada, si te parece poco...
Y no se qué importa la idea que tenga de Java.
#100 Mira el link de #97:
Fortran Intel 1.00
C++ GNU g++ 1.27
C GNU gcc 1.30
Java 7 -server 1.76
Un 30% mas lento que C++... y C++ es aproximadamente un 30% mas lento que fortran y nadie va dando la barrila con que fortran es super guay comparado con C++...
Son comparables, algo mas rapido C++, innegable, pero tampoco hay tanta diferencia como para que se tenga que notar a nivel usuario.
#91 Java NO ES comparable a C o C++ en velocidad, supéralo de una vez.
Que en un 5% de los casos pueda llegar a tener un rendimiento parecido o incluso ligeramente superior no lo convierte en comparable. Punto.
#74 Yo pienso que el tiempo de desarrollo, usando frameworks, librerías y más recursos que hay disponibles para los entornos 1 y 2 ayuda mucho. Lo que no entiendo es ¿qué aportan que no puedan aportar, a los programadores, un entorno y un lenguaje (semi)interpretado? ¿Y a las máquinas donde se va a correr? ¿Y a los usuarios? ¿No son más desventajas? ¿Y los problemas? Porque que sea cool por tener "recolector de basura" (tapadera de un signo de mal programador, descuidado, despreocupado o como quiera llamarse) o funcionar bajo cualquier plataforma son cosas muy diferentes y afectan de maneras muy distintas... y los defensores lo ponéis siempre en la misma bolsa.
#42 Hay que tener cuidado con publicar estos artículos antes de que se revisen a fondo por un equipo experto en la materia. Aun así, si alguien quiere comentar algo respecto a esto, que se ponga en contacto con la agrupación firmante.
#70
import psyco
i = 1000000000
while i!=0:
...i=i-1
time python test.py
real 0m0.096s
user 0m0.072s
sys 0m0.020s
talk is free
#81 No se lo que es psyco y no me lo admite (sólo se de phyton por Udacitym donde el bucle que te dico tarda 50 segundos, en mi PC incluso más). Phyton tal cual es lo que hace, desde la consola:
i=1000000000
while i!=0:
i=i-1
Eso me tarda un cojón.
#86 Paginas de mierda como reddit o una tal youtube estan hechas en python...
Que TU no seas capaz de utilizarlo mas que para 4 scripts no quiere decir que no se pueda usar mas que como scripts...
Asume que no tienes ni idea de lo que se puede y lo que no se puede hacer con python...
Vamos, que no sabes ni que es psyco... Podios... hazle caso a #81 que sabe de que habla...
Es mas, mira este ejemplo de java vs python y mira el comentario que le ponen....
Y sin psyco ni pypy ni fostias...
#95 No se apenas de Phyton, pero es muy lento no le des más vueltas: http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gpp=on&gcc=on&java=on&python3=on&calc=chart
#97 NO, no es muy lento para el 99% de las aplicaciones que se hacen.
Ademas si hay alguna parte que haga de cuello de botella puedes hacerla en C y usarla en python.
Y tardas la decima parte en programar....
PYTHON ES POESIA
Es arte. La vida de los programadores es una mierda pq utilizan basuras como C++ o java que no hacen mas que joderles la salud.
#97
http://psyco.sourceforge.net/
sudo apt-get install python-psyco
y que dije antes, en python haces el scripting, la gui, la lógica del programa etc, lo demás lo haces en c o usas librerías que ya están hechas en c o c++ optimizadas depuradas y requete probadas
#142 Phyton es lento.
Y he aportado datos:
#124 #97
Que maldita manía tienen algunos de agarrarse a un lenguaje joder...
En Basic, salvo los juegos, que se programan en DIV.
#20 Are you kidding me? http://en.wikipedia.org/wiki/OpenMP y a otro nivel C11 incorporará soporte nativo en la STL de multihilo, el modelo de memoria y la variables globales de hilo en el standard.
Realmente, yo tengo la esperanza de programar en Google Go dentro de un par de años, pero hoy por hoy no hay alternativa para muchos ámbitos. Y mira que C++ tiene arcaicismos heredados de C.
Chuck Norris programa en binario.
#9 Y el único comando de terminal que gasta es `kill -9`.
#9 Chuck Norris no programa, acojona bits.
global _start
section .data
mene db "En meneame somos todos h4x0rz", 24
length equ $-mene
section .text
_start:
mov eax, 4
mov ebx, 1
mov ecx, mene
mov edx, length
int 80h
xor ebx, ebx
mov eax, 1
int 80h
#20
Desde que Microsoft hace sus desarrollos en .NET todo va más lento y se consume mucha más memoria....La estrategia más acertada es desarrollar librerias en C y enlazarlas con lenguajes de más alto nivel como JAVA...
¿es .net lento en conparación a java?, LOL?
#67 Ah, ¿pero Microsoft usaba antes java para sus desarrollos?
Queda demostrado que un informático debe DOMINAR C/C++ si quiere hacer un programa importante y de uso masivo.
Para programillas freelance y scripts todo lo demás.
El otro día me tachaban de loco por decir ésto, hoy los datos me avalan. Gracias al que lo posteó, era de cajón.
Hasta las webs se hacen en C/C++ cuando han de rendir.
Los hombres de verdad no programan, modifican sus propias neuronas para que realicen tareas de programación
Mientras unos van discutiendo qué lenguaje es el mejor, compitiendo por algo sin mucho sentido, otros trabajan con sus respectivos lenguajes pensados para sus respectivos ámbitos de actuación, sin desmerecer a ninguno de ellos.
¿Alguien se acuerda del logo?
imaginais algún proyecto grande programado con una salída gráfica hecha con la tortuga? 
#5 Es un lenguaje funcional, no creas que no son potentes,aunque no creo que Logo este planteado para hacer grandes proyectos.
#12 Bueno era broma, el logo es un lenguaje cuco para aprender (yo lo aprendí en el instituto hace la tira de años) dibujar con la tortuga es absurdo para cosas grandes pero muy educativo para aprender programación (uno empieza con las ordenes básicas y haciendolo todo 'a lo bruto' y luego aprende a hacer procedimientos o bucles para tareas repetitivas etc)
Yo solo digo que los de Java tenemos que saber mil movidas y estar contínuamente estudiando y renovándonos.
Nuestros compañeros de Cobol, esos sí que lo tienen guapo, pueden dormir tranquilos. Con lo que saben tienen curro asegurado hasta que se mueran.
Por lo que veo C# no se usa para nada...
El Cobol iba a morir en el 2000, 0aja;)
Los hombres de verdad programan con escritura cuneiforme en tablillas de arcilla.
Mayor uso no implica mejor, la mayoría de gente usa explorer y windows y vota a PPSOE, me parece que está claro
Programar en lenguajes como Java es programar un programa de ordenador, no un ordenador en si mismo, es una pequeña diferencia que algunos se empeñan en no ver.
Nah, si aprendes Banksphere te conviertes en el fucking master, lo demás son zarandajas
.
Yo lo veo así: Empresa con un programador que cobra 1200 y un servidor de hace varios años, si programa en C necesita otro programador, si lo hace en java le basta con mejorar el servidor, conclusión, les sale mejor escoger Java.
Ahora, si se está haciendo una aplicación de escritorio para millones de usuarios nada da java, c o c++ o similar, aunque la aplicacion sea ligera. En ese caso lo primero es el usuario y si le obligas a comprar más RAM o procesador (puede que tu aplicación por si sola no lo necesite pero si tiene varias o si ejecuta muchas instancias si) le estás haciendo una putada (o para que quede más bonito y a la moda "estás afectando la experiencia de usuario").
Si es para la empresa que hagan lo que quieran, ellos verán, pero para el usuario por favor, código compilado.
También está el tema de si un código se repite mucho (un servidor atendiendo millones de consultas) o poco (un código para calcular algo que se ejecuta una vez cada 15 minutos), en el primer caso elegir java implica probablemente el doble de potencia para los servidores, phyton ni os cuento, y en el segundo da prácticamente igual.
El problema es cuando se usan las cosas para lo que no son, por ejemplo Machinarium, un juego que les habría costado poco más hacerlo en C y por hacerlo en flash exige mucho más PC, o Minecraft, que en algunos PC va a tirones pudiendo ir mucho más suave.
Corregidme si me equivoco, pero a mi me explicaron en su día que el compilador-interprete de java estaba hecho en C++.
#14 Evidentemente es así. C/C++ es la madre de todo, pero la informática moderna estaría en el Pleistoceno sin lenguajes que aportan una capa de abstracción, de hecho C/C++ no es más que otra capa de abstracción del código nativo de una arquitectura. Hoy en día estaríamos en pañales si no fuera por Java, ECMAScript, COBOL, PHP, etc... C/C++ contruye lenguajes no por que sea mejor, sino porque necesitamos usarlo para construir mejores lenguajes multipropósito.
Lo mismo ocurre ya con Java, que ya no es tanto lenguaje como palataforma, y vía JVM se usa para 'elevar' otros lenguajes como Clojure o Scala.
Desde que Microsoft hace sus desarrollos en .NET todo va más lento y se consume mucha más memoria.
#16 La estrategia más acertada es desarrollar librerias en C y enlazarlas con lenguajes de más alto nivel como JAVA o Phyton. En cualquier caso, el C/C++ ha llegado a su límite tecnológico. No es el lenguaje más apropiado para los nuevos procesadores multicore. Supongo que en los próximos años veremos una pequeña revolución.
#20 Y desde cuándo se ha preocupado micro de los consumos?
#20 Los videojuegos se crean en C++. Las consolas actuales son multicore y desde hace ya tiempo el "estandar" para juegos en PC son procesadores multicore y GPU con shaders unificados. Conozco pocas aplicaciones más exigentes que un videojuego y todas han sido creadas en C++.
Linux se programa en C y Linux siempre ha sido vanguardia en todo lo relacionado con aprovechamiento del hardware.
Salu2
#14 Es bastante irrelevante el lenguaje de programación en que esté programada la máquina virtual de Java, que al fin y al cabo es un binario. Los propios compiladores de C o C++ también están programados en C o C++.
No sé para qué queréis lenguajes más eficientes que otros si luego haceis programas tremendamente ineficientes
Tenía entendido que Android estaba hecho en Java...
#30 Está basado en Linux (por extensión en C) y ejecuta el código java en su propia máquina virtual. Véase http://es.wikipedia.org/wiki/Dalvik
Yo me imagino que hoy por hoy sólo Google podría hacer una alternativa a C/C++, habrá que estar al tanto de Go.
Por cierto no sabía que gcc está hecho en C++
#30 La API para desarrollar aplicaciones sí. El sistema operativo está, lógicamente, escrito en C (es Linux).
Lo mejor es ver a todos esos dioses de la eficiencia y la optimizacion programando algoritmos de ordenacion en O(N^2). Eso si, en C++ ehhhhh
#69 ¿Qué sentido tiene programarse uno sus propios algoritmos de ordenación (o cualquier otro común), cuando casi todos los lenguajes los llevan en sus librerías estándar? Por ejemplo, para C++, en la STL, el algoritmo de ordenación por defecto es mergesort O(n* log n). Y aquí puedes ver su implementación en la libstdc++ de GNU: http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01027.html
No reinventemos la rueda por favor.
#69 No creas, la ordenación por inserción es O(n2), pero también es o(n) (nótese la sutil diferencia entre O y o). Esto significa que si los datos que recibes ya están casi ordenados, o lo único que tienes que hacer es asegurarte de que vienen ordenados, el coste es lineal, algo con lo que ningún algoritmo de coste O(n * log2 n) puede competir. Quicksort, por ejemplo, suele tardar más precisamente cuando los datos ya están ordenados. Y algunas implementaciones del mismo primero realizan una ordenación parcial para después dar la última pasada usando ordenación por inserción.
Ah, y la ordenación por selección, que también es O(n2), resulta que es más eficiente que la mayoría de algoritmos O(n * log2 n) para conjuntos de datos pequeños.
hostia, ya sabemos la profesión predominante entre de los meneantes!
#75 Mira los primeros meneos de Menéame: http://www.meneame.net/?page=5400
Que no esté Python en esta comparativa cuando cosas importantísimas como YouTube están escritas con Python...
#22 No solo si ponen Python (En otros), sino que también ponen lo de que YouTube está en Python
#36 #38 Argh, me he columpiado. Mis disculpas.
#22 Asegúrate bien
#22 Revisa la noticia porque tanto Youtube como Python aparecen en la comparativa.
Sí, sí, mucho mediros la picha para ver que lenguaje la tiene más larga, pero os ponen un CSS por delante y no sabéis ni por donde empezar...
Por favor alguien experto que me explique porque a dia de hoy no es posible tener un lenguaje con sisntaxis facil y alta expresividad como Python/Ruby y que sean eficientes como c/c++
#52
Es posible
Tienes cython, tienes psyco
Y de todas maneras hay una máxima que dice que el 99% de la velocidad de un programa depende del 1% de dicho programa.
Ese 1% lo programas en c, y el resto en python
#58 Y así pierdes todo lo logrado. Phyton para scripts y cosillas bien, pero para aplicaciones no, por que es lo más lento que he visto en mi vida, eso si, comodísimo y muy fácil. Como anécdota en Udacity te hacían medir el rendimiendo de un simple loop while de 1000000000 iteraciones y tardaba... 50 segundos. En C no tarda ni 1 (lo probé yo después en ambos).
#70: No tienes ni idea de lo que estás hablando. 50 segundos dice jajajaja
#70 Hablar es gratis. Sobre todo cuando no tienes ni puta idea de lo que cuentas sobre cosas que no conoces y ni siquiera te molestas en demostrar tus afirmaciones.
Decir que Python "es lento" y que sólo sirve "para scripts y cosillas" y quedarse tan ancho, cuando el mismo intérprete de Python escrito en Python ya le anda a la par en algunos benchmarks al intérprete de Python escrito en C, es hacer el idiota y hablar por hablar.
Eso sí, queda superguay decir que tal o cual lenguaje de programación "es una mierda comparado con C o C++", muy de machotes que saben mucho de programación a bajo nivel, aunque luego ni siquiera sepas cómo demostrar esas afirmaciones gratuitas.
http://speed.pypy.org/
"Lo más lento que he visto en mi vida", dice. A saber qué coño habrás hecho o en qué máquinas y condiciones estabas ejecutando qué cosas escritas por quién y de qué manera en Python para decir que anda lento un lenguaje en el que se implementan sistemas en la empresa donde trabajo, en YouTube y en Google que dan servicio a miles y millones de personas, respectivamente. Me recuerda bastante a la típica charlatanería de "Java es muy lento", dicha por supuesto por los mismos personajes que no habrán tirado ni cien líneas seguidas de código en Java en su vida.
Bueno, yo voy a dejar testimonio aquí de que algunos programamos en ABAP, un poco para nenazas, mezcla de C y sentencias SQL más algunas cosillas que SAP se saca de la manga a la hora de programar formularios, pantallas y web
Que lenguaje de programación usas: Una discusión tán estúpida como que equipo de fútbol es peor, si los que usan windows son mas tontos que los que usamos linux o si es mejor tener gatos o perros..... cada uno para lo que necesite y con lo que se maneje mejor, coña!!!
#54 Claaaro, no hay lenguajes mejores y peores, ni tampoco equipos mejores ni peores... el Barsa esta al mismo nivel que el Villareja FC, solo es cuestión de gustos...
La mente de algunos debe de ser un infierno para tener que montarse esas peliculas y autojustificar que estan encadenados a un lenguaje de mierda.
#77 He dicho que es una discusión estúpida, no que sea mejor ni peor... ¿Ves? Caes en el mismo tema....
Si en tu trabajo trabajas bien con visual basic y, te es facil y cómodo y te pagan por ello... ADELANTE!!... mientras consiga el objetivo para el que se programa.....
Yo programo en Java para hacer aplicaciones de escritorio.... ¿Las podría hacer en C/C++?... pues si... y algunos me crucificareis... pero me da para lo que quiero... puedo usarlo tanto en los PC como en los MAC y los LINUX de mi curro y cumple su objetivo...
Hay quien usa Access para hacer aplicaciones y quien usa scripts de visual basic.....
Otra cosa es que hagas aplicaciones para megaservidores que tengan que estar optimizadas y tal.. si no, esto de los lenguajes de programación no es más que mero talibanismo....
hombre soy del periodo que se programaba con 0 y 1, as veces solamente con 0...
Chuck Norris programa en assembler y guarda el código fuente en /dev/null
Perl.
Hoy día, el tiempo de un programador importa más que los recursos de la maquina.
#53 Excepto cuando el rendimiento importa más que el tiempo de desarrollo, que es más veces de lo que te van a reconocer en la universidad.
Vincent Lextrait, el de la web, es manager en Amadeus IT, donde prácticamente todo el núcleo de negocio es (sorpresa) C++, precisamente para poder digerir decenas de miles de transacciones por segundo. Amadeus ya tiene el datacenter civil más grande de Europa, así que imagina si cambiaran a Perl.
Y eso que soy Perl Monk desde hace muchos años
Programadores, echarle un vistazo a esta especificación: http://goo.gl/ZZnsj