Portada
mis comunidades
otras secciones
#21:
#c-18" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/18">#18 Java es "interpretado" pero generalmente, una aplicación que esta en ejecución en la JVM al final quedan compiladas a máquina las partes más usadas con JIT. Fíjate que al final Android va a volver a compilación JIT.
Y lo de que nadie sabe hacer compiladores, es de una ignorancia tremenda. Esos compiladores, Java, Scala, Haskell, C#, F#, Python, Clojure, Rust, Swift, Javascript, etc... Son de una complejidad mucho mayor que compilador más complejo de C. De hecho, muchos de los lenguajes que nombro compilan a la LLVM y luego esta se encarga de optimizarlos para máquina.
Y te equivocas con lo de que estos lenguajes al contrario no capan los avances, sino que permiten aprovecharlos mejor. El caso de uso más común hoy en día es la programación multinucleo. ¿Como serías capaz de aprovechar un multinucleo con threads de C sin interlocks, sin corromper datos, y además aprovechando al máximo el procesador o cluster? Esa tarea en un lenguaje ensamblador o en C en un programa grande es muy muy difícil. Sin embargo, nos hemos dado cuenta ahora, que el paradigma de la programación funcional encaja mejor en este tipo de sistemas, y todos estos lenguajes soportan Higher Order Functions. Nos hemos dado cuenta, que si hacemos los datos immutables, los dividimos/particionamos y les aplicamos funciones de transformación, y agregación podemos aprovechar eficientemente múltiples núcleos/equipos y además hacerlo de una forma en la que se puede razonar mejor con lo que estamos programando. Consiguiendo no solamente mejor rendimiento, sino que además conseguimos tener menos errores en el código.
Y ahora en 2016, 39 años después desde que el creador de Fortran John Backus en su discurso de cuando gano el Turing abogaba por el uso de un estilo funcional de programación. Ojo, antes de tu 8088 naciera.
Y lo de que nadie sabe hacer compiladores, es de una ignorancia tremenda. Esos compiladores, Java, Scala, Haskell, C#, F#, Python, Clojure, Rust, Swift, Javascript, etc... Son de una complejidad mucho mayor que compilador más complejo de C. De hecho, muchos de los lenguajes que nombro compilan a la LLVM y luego esta se encarga de optimizarlos para máquina.
Y te equivocas con lo de que estos lenguajes al contrario no capan los avances, sino que permiten aprovecharlos mejor. El caso de uso más común hoy en día es la programación multinucleo. ¿Como serías capaz de aprovechar un multinucleo con threads de C sin interlocks, sin corromper datos, y además aprovechando al máximo el procesador o cluster? Esa tarea en un lenguaje ensamblador o en C en un programa grande es muy muy difícil. Sin embargo, nos hemos dado cuenta ahora, que el paradigma de la programación funcional encaja mejor en este tipo de sistemas, y todos estos lenguajes soportan Higher Order Functions. Nos hemos dado cuenta, que si hacemos los datos immutables, los dividimos/particionamos y les aplicamos funciones de transformación, y agregación podemos aprovechar eficientemente múltiples núcleos/equipos y además hacerlo de una forma en la que se puede razonar mejor con lo que estamos programando. Consiguiendo no solamente mejor rendimiento, sino que además conseguimos tener menos errores en el código.
Y ahora en 2016, 39 años después desde que el creador de Fortran John Backus en su discurso de cuando gano el Turing abogaba por el uso de un estilo funcional de programación. Ojo, antes de tu 8088 naciera.
#1:
Porque tiene apoyo, documentación y mucha ayuda, es fácil de encontrar recursos. Pero vamos, que en España seguimos usando COBOL que ya lleva mas de 50 años (a poco de los 60) y no ha avanzado nada de nada.
Comentarios
Porque tiene apoyo, documentación y mucha ayuda, es fácil de encontrar recursos. Pero vamos, que en España seguimos usando COBOL que ya lleva mas de 50 años (a poco de los 60) y no ha avanzado nada de nada.
#1 Si funciona no lo toques.
#1 Yo creo que es más porque cualquiera puede usarlo sin tener mucha idea.
#3 Es más fácil de usar Python
#6 Si, pero por ejemplo hacer aplicaciones gráficas en Python es mas jodidillo. Mientras que en Java tienes JavaFX y mariconadillas varias.
Yo he probado Kivy y es un coñazo.
#24 wxPython
#29 No vale para hacer Apps para móvil.
#1 ¿En España?
https://www.quora.com/Why-are-banks-still-using-COBOL
En toooodo el mundo
Saludos
#5 Mother of god... no sabía que fuese mundial, tenía entendido que era solo aquí
. Deberíamos crear un lenguaje de programación que unifique todo (no encuentro la tira cómica 
).
#9 https://xkcd.com/927/
#36 Gracias
#5 Dí eso en Londres y se están riendo 20 minutos.
En la City todos los bancos se han pasado a python.
#1 Si ha avanzado. microFocus, por ejemplo. Y se usa porque para tratar grandes bloques de información en modo batch, es sencillo, comprensible y supereficiente.
#1 y en RPG-II, no te olvides del pobre RPG-II,
#1 Te invito a que le eches un ojo a Visual Cobol y descubras que Eclipse y Visual Studio han relevado ya a la pantalla negra. Y sí, yo prefiero que el software de mi banco esté en un entorno que lleva décadas siendo probado en lugar de experimentar con lenguajes "mu bonitos" y "mu de moda" que a saber cuántos bugs contendrán.
#22
Los lenguajes no tienen bugs.
#1 Hombre, lo del COBOL no es precisamente por su activa comunidad de usuarios, es más bien porque hay un montón de sistemas funcionando, y hay que mantenerlos.
Más que nada será por el clima.
#27 ni idea, también estaba Jython. Pero no se yo si realmente se puede hacer JIT con Python o cualquier lenguaje dinámico. En un lenguaje con tipado estático supongo que se pueden hacer asunciones a la hora de optimizar a código máquina. Del tipo que determinada variable va a ser siempre un entero y puedas dejar esa parte compilada a código máquina. En cambio en un lenguaje dinámico mi impresión es que ese tipo de asunciones no se pueden hacer ya que en debido a alguna condición esa variable podría pasar de comportarse como un entero a una cadena de caracteres. Aunque supongo que existirá alguna técnica para que se pueda hacer de alguna forma.
No son "lenguajes modernos" así en general. De hecho, habla de Go (que es bastante reciente) en Uber y no lo han abandonado.
Abandonan Ruby y Node, porque son puta basura.
Porque habían empezado con Ruby.
#4 Otros, sin embargo, abandonan Java a favor de Node, que de basura tiene bien poco e IBM lo sabe muy bien: https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
#8 #7 Me corrijo: Ruby + Rails o Node + NPM son basura, o mejor dicho, hacen dificil no producir basura.
#7 Eliminar Java en favor de Node es porque estaban usando JAVA para lo que no era.
Tampoco me creo los números del articulo de PayPal
#11 ¿Y por qué habrían de mentir? ¯\_(ツ)_/¯
Yo he trabajado con Node durante tres años y me creo los números perfectamente, sólo se necesita una buena programación.
#12 Mentir no es la palabra adecuada......dudo que hayan estado usando java adecuadamente para la tarea. Yo he estado trabajando con Java bastante tiempo y he visto de todo
#4 los lenguajes no son basura. Solo tienen diferentes usos. Go tiene su "escena", Ruby tiene su escena, y Java tiene su escena (software empresarial que se lleva muy bien con el paradigma OOP, una gran ingenieria en la JVM y una barrera de entrada minima)
#25 hombre, si buscas rapidamente en google encuentras esto https://github.com/dropbox/pyston
#26 Si, pero me gustaría que alguien de por aquí, me contara su experiencia con este tipo de compiladores JIT en Python.
Y por el coste de licencias si quieres vender aplicaciones de .Net por ejemplo es uno de los puntos clave.
Porque Java es el mejor lenguaje del mundo, por delante de PHP, que aunque mucha gente lo usa, no es un lenguaje fuertemente tipado. JavaScript también está bien, porque lo usa mucha gente.
Antes la gente usaba BASIC, pero ya no mola.
#33 JavaScript es el Visual Basic del siglo XXI
#28 la LLVM da un backend para compilar Ahead of Time o Just in Time. Con o sin Garbage Collector. Es decir, tu puedes definirte un lenguaje y crear un compilador que compile a lenguaje intermedio de LLVM. Y LLVM ya se encarga de compilarlo a código máquina. Y de ahí ya obtienes un binario con tus unos y ceros para que se ejecute directamente. Y ahí esta el compilador https://en.wikipedia.org/wiki/Clang. Que compila C, C++, Objective-C, Objective-C++, OpenMP, OpenCL y CUDA a código máquina usando LLVM. Es el compilador por defecto de FreeBSD, MINIX. Se usa también para compilar con Xcode para dispositivos iOs y Mac Os X. Pero vamos como es una abreviatura de Virtual Machine sera una Virtual Machine.
Pero bueno, una "máquina virtual" tiene que ser más lenta ¿no? Pues no. http://www.javaworld.com/article/2076593/performance-tests-show-java-as-fast-as-c--.html?page=2
En fin, que hablas de cosas que no tienes ni puta idea. Estudia compiladores, infórmate y aprende.
¿Porque son masocas?
Dejan de usar Ruby en favor de Java "porque al ser un lenguaje interpretado es mas lento y consume memoria" ¿y desde cuando no es Java un lenguaje interpretado?, ¿me he perdido algo?.
El hardware avanza a un ritmo endiablado, mientras el software no solo no avanza sino que va para atrás. Los procesadores son miles de veces más rápidos, las memorias que antes se median en kilobytes ahora no en megas sino en Gigas, un factor de multiplicación de un millón de veces y no veas el almacenamiento que pasó de Megas a Teras, sin mencionar tiempos de acceso.
En cuanto a lenguajes, pasamos de ensamblador, rápido y eficiente como ninguno, a C, que ya perdía en ambas características y de repente surgen multitud de lenguajes-caca, a cual peor, que lo único que ofrecen es facilidad de programación para que cualquier incompetente sea capaz de programar sin tener idea de lo que se trae entre manos y encima interpretados que así sobrecargamos bien a la máquina, ¿es que nadie sabe ya hacer compiladores?.
Todos ellos basados en que el incremento de calidad del hardware compensa las enormes ineficiencias de estos lenguajes-caca. ¿Se imaginan ustedes si el hardware no hubiera evolucionado, corriendo en un PC de 8 bits y procesador 8088 a 4,47 MHz, una aplicación gráfica desarrollada en Java, Ruby, Python, etc...?
No soy un nostálgico, yo también uso esos lenguajes-caca, cuya meta parece ser capar todos los avances del hardware, pero que asquito me dan.
#18 ¿y desde cuando no es Java un lenguaje interpretado?, ¿me he perdido algo?.
Te has perdido los 2 años del ciclo formativo de FP en la cafetería jugando a las cartas.
#c-18" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2622277/order/18">#18 Java es "interpretado" pero generalmente, una aplicación que esta en ejecución en la JVM al final quedan compiladas a máquina las partes más usadas con JIT. Fíjate que al final Android va a volver a compilación JIT.
Y lo de que nadie sabe hacer compiladores, es de una ignorancia tremenda. Esos compiladores, Java, Scala, Haskell, C#, F#, Python, Clojure, Rust, Swift, Javascript, etc... Son de una complejidad mucho mayor que compilador más complejo de C. De hecho, muchos de los lenguajes que nombro compilan a la LLVM y luego esta se encarga de optimizarlos para máquina.
Y te equivocas con lo de que estos lenguajes al contrario no capan los avances, sino que permiten aprovecharlos mejor. El caso de uso más común hoy en día es la programación multinucleo. ¿Como serías capaz de aprovechar un multinucleo con threads de C sin interlocks, sin corromper datos, y además aprovechando al máximo el procesador o cluster? Esa tarea en un lenguaje ensamblador o en C en un programa grande es muy muy difícil. Sin embargo, nos hemos dado cuenta ahora, que el paradigma de la programación funcional encaja mejor en este tipo de sistemas, y todos estos lenguajes soportan Higher Order Functions. Nos hemos dado cuenta, que si hacemos los datos immutables, los dividimos/particionamos y les aplicamos funciones de transformación, y agregación podemos aprovechar eficientemente múltiples núcleos/equipos y además hacerlo de una forma en la que se puede razonar mejor con lo que estamos programando. Consiguiendo no solamente mejor rendimiento, sino que además conseguimos tener menos errores en el código.
Y ahora en 2016, 39 años después desde que el creador de Fortran John Backus en su discurso de cuando gano el Turing abogaba por el uso de un estilo funcional de programación. Ojo, antes de tu 8088 naciera.
#21 Una pregunta: ¿Existe LLVM para Python?
Estaría de PM
#21 LLVM, precisamente VM es la abreviatura de Virtual Machine.
Eso no son compiladores, los compiladores generan lenguaje maquina directamente ejecutable, esos son pseudocompiladores que generan un lenguaje intermedio de pseudocodigos pero que sigue necesitando una máquina virtual, que ocupa memoria para interpretar los pseudocódigos, algo que consume tiempo de maquina..
Fíjate si es viejo que ya en la época del Basic se utilizaban y se les llamaba pseudo-compiladores.
Si, desarrollar y mantener código en C es jodido, nadie lo niega, pero aprovechar las nuevas funcionalidades a nivel hardware se hace precisamente en C que es donde eso se hace, en los sistemas operativos, los programas mas grandes y complejos que existen.
Lo dicho no se ha avanzado nada y se ha retrocedido mucho. Los únicos beneficiados, los vagos que quieren resultados rápidos y espectaculares con el mínimo esfuerzo posible.