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
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.
C/C++ al poder...
Genial...
Seguid con el Java ese, seguid... Los hombres de verdad programan en C
Flame en 3,2,1...
¿Alguien se acuerda del logo?
imaginais algún proyecto grande programado con una salída gráfica hecha con la tortuga? 
En Basic, salvo los juegos, que se programan en DIV.
Ensamblador...para hombres con pelo en el pecho y poco en la cabeza.
En tarjeticas perforadas programan en Bilbao.
Chuck Norris programa en binario.
Yo programo el vídeo.
El Cobol iba a morir en el 2000, 0aja;)
#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)
Corregidme si me equivoco, pero a mi me explicaron en su día que el compilador-interprete de java estaba hecho en C++.
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)
#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.
#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
#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++.
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.
#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
Que no esté Python en esta comparativa cuando cosas importantísimas como YouTube están escritas con Python...
#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.
#20 Y desde cuándo se ha preocupado micro de los consumos?
#23 Los hombres de verdad están practicando sexo mientras vosotros discutís sobre lenguajes de programación
#20 ¿C/C++ han llegado a su límite tecnológico? ¿No adecuados para la programación multicore? ¿Mande?
#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++
#23 Positivo por la referencia xkcdiana
Mayor uso no implica mejor, la mayoría de gente usa explorer y windows y vota a PPSOE, me parece que está claro
Tenía entendido que Android estaba hecho en Java...
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.
#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.
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.
#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.
#22 No solo si ponen Python (En otros), sino que también ponen lo de que YouTube está en Python
#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
#22 Asegúrate bien
#36 #38 Argh, me he columpiado. Mis disculpas.
#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++
#22 Revisa la noticia porque tanto Youtube como Python aparecen en la comparativa.
Programadores, echarle un vistazo a esta especificación: http://goo.gl/ZZnsj
#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.
#27 ¿Bloc de notas? Pero... peroperopero... Tú no conoces el vi, no?
#9 Y el único comando de terminal que gasta es `kill -9`.
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
#44 ¿Vi? ¿Qué mariconada es esa? Los hombres de verdad escriben con `cat`.
#30 La API para desarrollar aplicaciones sí. El sistema operativo está, lógicamente, escrito en C (es Linux).
#4 los hombres de verdad programan con tarjetas perforadas y una manivela para dar luz
#44 Estamos hablando de hombres, al que le guste el vi, sinceramente, que se mire el adn por que eso no es humano.
#37 buen intento de flame
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++
Perl.
Hoy día, el tiempo de un programador importa más que los recursos de la maquina.
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!!!
Por lo que veo C# no se usa para nada...
#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...
Los hombres de verdad programan con escritura cuneiforme en tablillas de arcilla.
#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
#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
#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
#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.
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.
#56 La pregunta es de coña no?
#15 Yo programo en D
#8 que en tarjetas perforadas no se programa, se almacena!
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.
#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?
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
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
#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).
No sé para qué queréis lenguajes más eficientes que otros si luego haceis programas tremendamente ineficientes
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.
#67 Ah, ¿pero Microsoft usaba antes java para sus desarrollos?
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
hostia, ya sabemos la profesión predominante entre de los meneantes!
#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).
#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.
#37 Pero que dices, insensato, los ingenieros no tiempo para eso
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.
#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/
#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
#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.
#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.
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.
#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#
#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.
#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.
Los hombres de verdad no programan, modifican sus propias neuronas para que realicen tareas de programación
#75 Mira los primeros meneos de Menéame: http://www.meneame.net/?page=5400
hombre soy del periodo que se programaba con 0 y 1, as veces solamente con 0...
#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
#85 No, si yo lo decía en serio http://dlang.org/
Nah, si aprendes Banksphere te conviertes en el fucking master, lo demás son zarandajas
.
#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.
#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...
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...
#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
#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...
Chuck Norris programa en assembler y guarda el código fuente en /dev/null
#98 Joder, pues es una diferencia moderada, si te parece poco...
Y no se qué importa la idea que tenga de Java.