Ver la versión completa : ¿Qué pasa con las actualizaciones de Flash?
Hola a todos:
Todos odiamos Flash, pero es necesario en la navegación del día a día (imprescindible para seguir viendo los videos de gatitos), pero llevo tres días con un molesto mensaje de Firefox diciendo que se ha deshabilitado el componente por problemas de seguridad. Sólo es molesto, nada que no se arregle con un "activar ahora", pero es que aun actualizando a la versión de AYER, en Kubuntu me sigue saliendo el dichoso mensajito (aunque la versión indicada en la web de Mozilla como problemática es anterior incluso a la que tenía instalada antes de actualizarla).
Con Windows no ha habido problemas pero ¿con Linux? ¿Hay algún problema con la detección de versiones, es que no se ha solucionado aun o es que definitivamente esta es la patada a los usuarios del pigüino?
No, no estoy enfadado, sólo que me extraña. Sigo viendo mis videos de gatitos con toda normalidad en el sub-sótano de mi guarida.
_Seagal_
17/07/2015, 19:18
Esto:
http://www.elotrolado.net/noticia_mozilla-anuncia-el-bloqueo-de-todas-las-versiones-de-flash-en-firefox_26809
que ya estan cansados que el flash sea un coladero.
Hay por ahi un virus que te encripta TODO el disco duro y todas las unidades que tengas conectadas. Y te dicen que si quieres desencriptarlo mandes 400 dolares al creador del virus y te dirá como hacerlo.
Y no, no es necesario ejecutar exes ni nada de eso. La mayorua de gente se ha infectado a traves de los coladeros del flash.
blindrulo
17/07/2015, 20:52
Pues a mi no me sale ningún mensaj en firefox, donde se mira si está actiavdo o no el flash en firefox?
Un saludo. :brindis:
3XCL4M4t10N
17/07/2015, 21:00
Lo de Flash es que no tiene nombre, lleva siendo una basura eones y aun se sigue usando de forma genérica. A ver si pasa como IE y se paga el ostión padre de una vez.
Pues eso, que los de Mozilla se han cansado de Flash y muy bien que hacen. El sistema operativo da igual, seguramente no tengas actualizado el Firefox en Windows y por eso no se queja.
blindrulo
17/07/2015, 21:13
Pues eso, que los de Mozilla se han cansado de Flash y muy bien que hacen. El sistema operativo da igual, seguramente no tengas actualizado el Firefox en Windows y por eso no se queja.
Pues yo usoes Mac Os X y tengo el firefox actualizado a la versión 39.0. Y no me salta nada.
Un saludo. :brindis:
josepzin
17/07/2015, 21:29
Yo cuando quiero ver algo con Flash abro un Chrome portable, hace años que no tengo el reproductor de Flash instalado.
A mí no me salta nada. Es que tienes que actualizar tanto el navegador como el adobe flash a la última versión. Por supuesto, también disponer de un buen antivirus.
josepzin
17/07/2015, 22:06
Según escuché ayer, a un grupo de hackers italianos los hackearon y ahí descubrieron una vulnerabilidad de Flash que estos estaban aprovechando para vender vender un servicio de espionaje. A ver si lo puedo confirmar.
3XCL4M4t10N
17/07/2015, 22:16
Que gracia, en Chrome desactivaron Java hace un par de actualizaciones.
FlipFlopX
17/07/2015, 22:57
Y Adobe pasa de él olímpicamente
Pues yo lo actualize hace una semana o así y ahora me dice otra vez que esta obsoleto (OS-X y Safari)
GameMaster
17/07/2015, 23:05
Que ponga obsoleto es el plato del dia, yo nunca lo actualizo.
princemegahit
17/07/2015, 23:30
A lo que no os salta nada, es porque no teneis la última versión de Firefox en Linux. Los de Mozilla han decidido que lo desactivan por defecto para evitar males mayores, ya que el flash en linux se ha quedado estancado por la versión 11.2.202.481. Si teneis esa versión de flash, y firefox<39 , en linux, no os saltará. Evidentemente se supone que en windows como se ha seguido desarrollando hasta la versión 18?? está todo bien (si es que a ese consumo de recursos se le puede llamar bien).
Los de Mozilla tenian previsto un plugin sustituto, al estilo de chrome para futuras versiones. Yo creo que ya es hora de sacarlo para la versión 40, aunque esté en fase beta.
http://www.commitstrip.com/wp-content/uploads/2015/07/Strip-La-vie-de-Flash1.jpg
3XCL4M4t10N
18/07/2015, 02:03
http://www.commitstrip.com/wp-content/uploads/2015/07/Strip-La-vie-de-Flash1.jpg
Ostias, no me jodas :quepalmo:.
Pues no es que Java sea mucho mejor, pero ahí lo teneis :D:D:D (responsable de uno de los tres virus que se me han colado).
Siempre lo he pensado: Flash es un traga recursos, y me ralentiza la navegación en Linux. Ya lo de fallos de seguridad ni idea, porque no trabajo con él a ese nivel.
Yo espero que HTML5 sea un buen sustituto, lo que no me queda tan claro es que sea más rápido que flas, porque algún juego estilo flash he visto que se me ha ralentizado un poco.
Yo espero que HTML5 sea un buen sustituto, lo que no me queda tan claro es que sea más rápido que flas, porque algún juego estilo flash he visto que se me ha ralentizado un poco.
En teoría los navegadores interpretan de forma nativa HTML5, ergo, debe ir mucho más rápido.
Otra cosa es el grado de compatibilidad de cada navegador. Aunque eso se va mejorando s con cada versión nueva (hablo de FF y Chrome).
princemegahit
19/07/2015, 00:27
Bueno, pues ya está arreglado, ya veremos lo que dura, por eso.
En teoría los navegadores interpretan de forma nativa HTML5, ergo, debe ir mucho más rápido.
Otra cosa es el grado de compatibilidad de cada navegador. Aunque eso se va mejorando s con cada versión nueva (hablo de FF y Chrome).
"Interpretar" y "de forma nativa" en la misma frase se me antoja "raro".
Es más, un lenguaje de etiquetas, fácilmente compilable/comprimible me extraña que se siga usando en "modo texto". Sé que los parsers hoy día son muy eficientes, pero aun así...
Bueno, pues ya está arreglado, ya veremos lo que dura, por eso.
Cierto, ya le he metido las actualizaciones y de momento no se me está quejando.
Pero a este paso igual no es mala idea poner en "preguntar siempre" tanto flash como java y todo complemento que comprometa la seguridad del sistema (y así nos quitamos problemas con banners, popups y demás morralla que ralentiza la navegación :lol:)
^MiSaTo^
20/07/2015, 19:53
"Interpretar" y "de forma nativa" en la misma frase se me antoja "raro".
Es más, un lenguaje de etiquetas, fácilmente compilable/comprimible me extraña que se siga usando en "modo texto". Sé que los parsers hoy día son muy eficientes, pero aun así...
A qué te refieres con "modo texto"? No he entendido ni papa de esta frase. Tampoco se por qué te suena raro interpretar de forma nativa xD
HTML es un lenguaje de texto, es decir, que se "interpreta" en lugar de "ejecutarse". Será que estoy "cahapado a la antigua" pero para mi, hacer algo de "forma nativa" implica que el procesador es capaz de entender y procesar las órdenes que se les da, y HTML es un lenguaje de muy alto nivel que debe ser parseado previamente y convertido a llamadas de funciones de un lenguaje de un nivel más bajo, que sí se ejecuta usando código binario que entiende el procesador.
El lenguaje de más alto nivel con el que he trabajado que podría llegar a entender que se puede "ejecutar" es Java, y por una razón: Java debe compilarse, y existen CPUs con un juego de instrucciones (Jazelle creo recordar que se llamaban) capaces de entenderlas y ejecutarlas directamente por HW. Ni siquiera Fenix o Bennu, que son similares a la hora de funcionar, considero que sean "ejecutables", pues dependen de una "máquina virtual" programada en C++ y SDL.
Lo del "modo texto" me refiero a que se puede abrir un HTML con el bloc de notas. Un lenguaje basado en etiquetas podría sustituir cada una de ellas por un mnemónico, ya sea un int o una serie de valores binarios (porque admiten atributos y valores) y reducir la necesidad de analizar el texto y convertirlo en una posterior llamada al intérprete (además de reducir el tamaño del fichero, no recuerdo si los actuales protocolos de transmisión añaden la compresión de datos antes de la emisión), reduciendo además el tiempo de ejecución y aumentando la eficiencia del sistema.
Pero ya HTML5 no sé cómo funciona realmente, es demasiado moderno. He supuesto (como hago siempre) que al ser HTMLx sigue con el lenguaje HTML, pero si han incluido dentro del lenguaje zonas de código binario que se pueden enviar a la CPU o a un intérprete, lo ignoro (y lo aplaudiría). Pero ojo, no me vale código incrustado, como veo en algunas páginas con javascript.
No sé si este razonamiento tiene sentido para ti, Misato.
Pero te ahorras el engorro de "compilar" html para pasarlo a binario y en caso de que falle tienes que hacer el proceso de modificar y compilar. Imagínate una pagina compleja con un montón de ficheros html, modificas varios y tendrías que "compilarlos" para asegurarte de que todos estén usando la versión correspondiente. Es lo mismo que hacer un proyecto grande en C++, Java o lo que sea, y supongo que no querían hacer cosas tan complicadas teniendo en cuenta que los que van a usar en html en muchos casos no serán programadores.
De todas formas ¿que ahorras?, ¿que las paginas ocupen menos memoria? da igual, todo el mundo tiene una conexión rápida. ¿Te ahorras el pasear los ficheros html? Da igual, con una CPU moderna se hace rápido.
-----Actualizado-----
¿Cuantos bytes supone la parte de etiquetas respecto al contenido (enlaces, textos, enlaces a los gráficos, etc) en una pagina html?
"Interpretar" y "de forma nativa" en la misma frase se me antoja "raro".
Es más, un lenguaje de etiquetas, fácilmente compilable/comprimible me extraña que se siga usando en "modo texto". Sé que los parsers hoy día son muy eficientes, pero aun así...
HTML es un lenguaje de texto, es decir, que se "interpreta" en lugar de "ejecutarse". Será que estoy "cahapado a la antigua" pero para mi, hacer algo de "forma nativa" implica que el procesador es capaz de entender y procesar las órdenes que se les da, y HTML es un lenguaje de muy alto nivel que debe ser parseado previamente y convertido a llamadas de funciones de un lenguaje de un nivel más bajo, que sí se ejecuta usando código binario que entiende el procesador.
El lenguaje de más alto nivel con el que he trabajado que podría llegar a entender que se puede "ejecutar" es Java, y por una razón: Java debe compilarse, y existen CPUs con un juego de instrucciones (Jazelle creo recordar que se llamaban) capaces de entenderlas y ejecutarlas directamente por HW. Ni siquiera Fenix o Bennu, que son similares a la hora de funcionar, considero que sean "ejecutables", pues dependen de una "máquina virtual" programada en C++ y SDL.
Lo del "modo texto" me refiero a que se puede abrir un HTML con el bloc de notas. Un lenguaje basado en etiquetas podría sustituir cada una de ellas por un mnemónico, ya sea un int o una serie de valores binarios (porque admiten atributos y valores) y reducir la necesidad de analizar el texto y convertirlo en una posterior llamada al intérprete (además de reducir el tamaño del fichero, no recuerdo si los actuales protocolos de transmisión añaden la compresión de datos antes de la emisión), reduciendo además el tiempo de ejecución y aumentando la eficiencia del sistema.
Pero ya HTML5 no sé cómo funciona realmente, es demasiado moderno. He supuesto (como hago siempre) que al ser HTMLx sigue con el lenguaje HTML, pero si han incluido dentro del lenguaje zonas de código binario que se pueden enviar a la CPU o a un intérprete, lo ignoro (y lo aplaudiría). Pero ojo, no me vale código incrustado, como veo en algunas páginas con javascript.
No sé si este razonamiento tiene sentido para ti, Misato.
Creo que por el contexto se entiende con claridad que lo de "de forma nativa" se refiere a que el procesado de ese lenguaje lo realiza directamente el navegador y no un componente adicional. Igualmente, la palabra "interpretar" también habría que entenderla en sentido amplio. Como se sabe, HTML (incluyendo HTML5, si no me equivoco) no es un lenguaje de programación sino de descripción de documentos. Los documentos HTML ni se compilan ni se interpretan, sino que se representan (el término técnico en inglés es "render", como es bien sabido), y el análisis léxico no es desde luego la parte más costosa de ese proceso. Ciertamente tiene sentido comprimirlos para ahorrar ancho de banda en las transmisiones, y para ello ya están las correspondientes opciones en el protocolo HTTP. Si te refieres más bien a JavaScript, que es un lenguaje interpretado, y a por qué no se utiliza un lenguaje intermedio binario como en el caso de Java... pues sí, precisamente eso es lo que pretenden hacer ahora con WebAssembly (http://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly).
Hola. Adobe Flash para Linux se ha quedado en la versión 11.2 (en los demás sistemas van por la versión 18). Ahora mismo está sin soporte, excepto parches de seguridad.
Tienes Pipelight plugin para instalar la versión de Windows de varios complementos (Unity Web, Flash, Silverlight) usando Wine por detrás.
Hazte la idea de que Flash para Linux nunca más, ni parches de seguridad ni nada. Dicen que sacan parches de seguridad pero estoy convencido de que no les durará mucho. No pueden desarrollar parches de una versión obsoleta. Va en contra de cualquier metodología de desarrollo ágil. Supongo que proporcionan parches porque alguna ley comunitaria dice que el software profesional tiene que tener garantía o algo durante X tiempo, por lo que si has estado dando soporte igual lo tienes que dar algún tiempo a la versión antigua.
HTML es un lenguaje de texto, es decir, que se "interpreta" en lugar de "ejecutarse". Será que estoy "cahapado a la antigua" pero para mi, hacer algo de "forma nativa" implica que el procesador es capaz de entender y procesar las órdenes que se les da, y HTML es un lenguaje de muy alto nivel que debe ser parseado previamente y convertido a llamadas de funciones de un lenguaje de un nivel más bajo, que sí se ejecuta usando código binario que entiende el procesador.
El lenguaje de más alto nivel con el que he trabajado que podría llegar a entender que se puede "ejecutar" es Java, y por una razón: Java debe compilarse, y existen CPUs con un juego de instrucciones (Jazelle creo recordar que se llamaban) capaces de entenderlas y ejecutarlas directamente por HW. Ni siquiera Fenix o Bennu, que son similares a la hora de funcionar, considero que sean "ejecutables", pues dependen de una "máquina virtual" programada en C++ y SDL.
Lo del "modo texto" me refiero a que se puede abrir un HTML con el bloc de notas. Un lenguaje basado en etiquetas podría sustituir cada una de ellas por un mnemónico, ya sea un int o una serie de valores binarios (porque admiten atributos y valores) y reducir la necesidad de analizar el texto y convertirlo en una posterior llamada al intérprete (además de reducir el tamaño del fichero, no recuerdo si los actuales protocolos de transmisión añaden la compresión de datos antes de la emisión), reduciendo además el tiempo de ejecución y aumentando la eficiencia del sistema.
Pero ya HTML5 no sé cómo funciona realmente, es demasiado moderno. He supuesto (como hago siempre) que al ser HTMLx sigue con el lenguaje HTML, pero si han incluido dentro del lenguaje zonas de código binario que se pueden enviar a la CPU o a un intérprete, lo ignoro (y lo aplaudiría). Pero ojo, no me vale código incrustado, como veo en algunas páginas con javascript.
No sé si este razonamiento tiene sentido para ti, Misato.
Primero, HTML es un lenguaje de marcado.
Segundo, tu te crees que los juegos HTML5 se programan en HTML??
Como mucho se usa el tag Canvas para tener precisamente un lugar donde poder renderizar las cosas, a partir de ahi todo son APIs de JS
-----Actualizado-----
Hola a todos:
Todos odiamos Flash, pero es necesario en la navegación del día a día (imprescindible para seguir viendo los videos de gatitos), pero llevo tres días con un molesto mensaje de Firefox diciendo que se ha deshabilitado el componente por problemas de seguridad. Sólo es molesto, nada que no se arregle con un "activar ahora", pero es que aun actualizando a la versión de AYER, en Kubuntu me sigue saliendo el dichoso mensajito (aunque la versión indicada en la web de Mozilla como problemática es anterior incluso a la que tenía instalada antes de actualizarla).
Con Windows no ha habido problemas pero ¿con Linux? ¿Hay algún problema con la detección de versiones, es que no se ha solucionado aun o es que definitivamente esta es la patada a los usuarios del pigüino?
No, no estoy enfadado, sólo que me extraña. Sigo viendo mis videos de gatitos con toda normalidad en el sub-sótano de mi guarida.
Imprescindible para que los grupos de hackers que venden herramientas a los gobiernos se ceben con sus infinitos 0 days, diras.
princemegahit
22/07/2015, 15:52
Hola. Adobe Flash para Linux se ha quedado en la versión 11.2 (en los demás sistemas van por la versión 18). Ahora mismo está sin soporte, excepto parches de seguridad.
Tienes Pipelight plugin para instalar la versión de Windows de varios complementos (Unity Web, Flash, Silverlight) usando Wine por detrás.
Hazte la idea de que Flash para Linux nunca más, ni parches de seguridad ni nada. Dicen que sacan parches de seguridad pero estoy convencido de que no les durará mucho. No pueden desarrollar parches de una versión obsoleta. Va en contra de cualquier metodología de desarrollo ágil. Supongo que proporcionan parches porque alguna ley comunitaria dice que el software profesional tiene que tener garantía o algo durante X tiempo, por lo que si has estado dando soporte igual lo tienes que dar algún tiempo a la versión antigua.
No sé donde me pareció leer que era hasta el 2018, pero mirando en las páginas de soporte de adobe no veo ninguna fecha al respecto, igual lo imaginé.
No sé donde me pareció leer que era hasta el 2018, pero mirando en las páginas de soporte de adobe no veo ninguna fecha al respecto, igual lo imaginé.
Ni idea al respecto. 2018 no está tan lejos. Si HP ha mantenido el soporte de HP-UX 11.00 hasta 2013 Adobe puede mantener el soporte de Flash 11.2 para Linux hasta 2018 y seguro que le cuesta menos.
Pero te ahorras el engorro de "compilar" html para pasarlo a binario y en caso de que falle tienes que hacer el proceso de modificar y compilar. Imagínate una pagina compleja con un montón de ficheros html, modificas varios y tendrías que "compilarlos" para asegurarte de que todos estén usando la versión correspondiente. Es lo mismo que hacer un proyecto grande en C++, Java o lo que sea, y supongo que no querían hacer cosas tan complicadas teniendo en cuenta que los que van a usar en html en muchos casos no serán programadores.
De todas formas ¿que ahorras?, ¿que las paginas ocupen menos memoria? da igual, todo el mundo tiene una conexión rápida. ¿Te ahorras el pasear los ficheros html? Da igual, con una CPU moderna se hace rápido.
-----Actualizado-----
¿Cuantos bytes supone la parte de etiquetas respecto al contenido (enlaces, textos, enlaces a los gráficos, etc) en una pagina html?
Creo que por el contexto se entiende con claridad que lo de "de forma nativa" se refiere a que el procesado de ese lenguaje lo realiza directamente el navegador y no un componente adicional. Igualmente, la palabra "interpretar" también habría que entenderla en sentido amplio. Como se sabe, HTML (incluyendo HTML5, si no me equivoco) no es un lenguaje de programación sino de descripción de documentos. Los documentos HTML ni se compilan ni se interpretan, sino que se representan (el término técnico en inglés es "render", como es bien sabido), y el análisis léxico no es desde luego la parte más costosa de ese proceso. Ciertamente tiene sentido comprimirlos para ahorrar ancho de banda en las transmisiones, y para ello ya están las correspondientes opciones en el protocolo HTTP. Si te refieres más bien a JavaScript, que es un lenguaje interpretado, y a por qué no se utiliza un lenguaje intermedio binario como en el caso de Java... pues sí, precisamente eso es lo que pretenden hacer ahora con WebAssembly (http://arstechnica.com/information-technology/2015/06/the-web-is-getting-its-bytecode-webassembly).
Compilar se ha compilado en lenguajes casi toda la vida, y lo dicho, los parsers son tan rápidos que de programar a compilar y ver se tarda la pulsación de un botón, casi el mismo tiempo que tardas de pasar del código HTML a la "vista previa".
En frio es cierto que quizás el ahorro no sea mucho, mientras lo que se programe no haga un uso intensivo de la CPU.
Pero si nos ponemos a pensar que para leer una etiqueta (usando cálculos muy simplificados) usamos 7 ciclos de CPU para cada acceso a memoria... bueno, digamos 2 de media, usando las diversas caches; y que en cada acceso a memoria podemos obtener hasta 4 caracteres (en CPUs de 64 bits, con cada caracter en formato de 16bits, por ejemplo, unicode), podemos tardar tranquilamente 4 ciclos de CPU sólo para la etiqueta <QUOTE>. Si en una parte del programa defines que dicha etiqueta vale el entero 24, en sólo dos ciclos lees esa etiqueta y te sobra espacio para leer 1 o 2 caracteres más.
Si la etiqueta tiene atributos, sólo la lectura podría ser 4 u 8 veces más rápida, y no necesitaría intentar descifrar si la parte del texto que se ha leido es una etiqueta, un atributo, un valor, si está bien o mal escrita, si hay que leer más o menos texto... y esos son varios ciclos más de computación.
Pero claro, no es lo mismo para una web de 300 lineas sin interacción (porque creo que la parte interactiva es javascript ¿no?) que para un programa con 3000 lineas de saltos, bucles y demás :D
Tampoco digo que se hagan las webs en ASM, ni que se deban compilar para X86, ARM, etc, como se menciona en el artículo de webassembly, pero sí usar una sencilla máquina virtual como la de java para "interpretar" los "comandos". Yo lo hice en Venturer y creo que es tremendamente sencillo, incluso una "compilación inversa" es posible.
Primero, HTML es un lenguaje de marcado.
Segundo, tu te crees que los juegos HTML5 se programan en HTML??
Como mucho se usa el tag Canvas para tener precisamente un lugar donde poder renderizar las cosas, a partir de ahi todo son APIs de JS
No lo sé, por eso pregunto.
Sé que se usa HTML, y sé que existe JS con el mismo problema (incluso más grave, si existen estructuras de selección y bucles). Es más, no sé si quiera si la ejecución se realiza al mismo tiempo que se lee, o hay una "pre-compilación", o un híbrido.
En cualquier caso, para programas complejos (un sencillo juego), en mi opinión, un lenguaje "textual" en lugar de "binario" supone muchas más desventajas que ventajas: rendimiento, tamaño, privacidad del código... Pero lo dicho, quizás es que estoy chapado a la antigua, o que simplemente siempre he programado a bajo nivel.
Compilar se ha compilado en lenguajes casi toda la vida, y lo dicho, los parsers son tan rápidos que de programar a compilar y ver se tarda la pulsación de un botón, casi el mismo tiempo que tardas de pasar del código HTML a la "vista previa".
En frio es cierto que quizás el ahorro no sea mucho, mientras lo que se programe no haga un uso intensivo de la CPU.
Pero si nos ponemos a pensar que para leer una etiqueta (usando cálculos muy simplificados) usamos 7 ciclos de CPU para cada acceso a memoria... bueno, digamos 2 de media, usando las diversas caches; y que en cada acceso a memoria podemos obtener hasta 4 caracteres (en CPUs de 64 bits, con cada caracter en formato de 16bits, por ejemplo, unicode), podemos tardar tranquilamente 4 ciclos de CPU sólo para la etiqueta <QUOTE>. Si en una parte del programa defines que dicha etiqueta vale el entero 24, en sólo dos ciclos lees esa etiqueta y te sobra espacio para leer 1 o 2 caracteres más.
Si la etiqueta tiene atributos, sólo la lectura podría ser 4 u 8 veces más rápida, y no necesitaría intentar descifrar si la parte del texto que se ha leido es una etiqueta, un atributo, un valor, si está bien o mal escrita, si hay que leer más o menos texto... y esos son varios ciclos más de computación.
Pero claro, no es lo mismo para una web de 300 lineas sin interacción (porque creo que la parte interactiva es javascript ¿no?) que para un programa con 3000 lineas de saltos, bucles y demás :D
Tampoco digo que se hagan las webs en ASM, ni que se deban compilar para X86, ARM, etc, como se menciona en el artículo de webassembly, pero sí usar una sencilla máquina virtual como la de java para "interpretar" los "comandos". Yo lo hice en Venturer y creo que es tremendamente sencillo, incluso una "compilación inversa" es posible.
Que si, que es mucho mas rápido, pero de todas formas de que te sirve hacer esa parte mas rápida si para ver la pagina completa tienes que esperara a que se descarguen los gráfico que ocupan mucho mas.
Asi es la informatica de ahora, lo importante es que funcione, si va lento, espérate unos meses que ya habrá algun cacharro donde vaya bien.
Nathrezim
22/07/2015, 22:00
Si, lo mejor que se puede hacer es hacer que el código de una página web dependa del procesador y del sistema operativo que ejecute el navegador. Total, todo el mundo usa un X86 sobre un debian-like.
No lo sé, por eso pregunto.
Sé que se usa HTML, y sé que existe JS con el mismo problema (incluso más grave, si existen estructuras de selección y bucles). Es más, no sé si quiera si la ejecución se realiza al mismo tiempo que se lee, o hay una "pre-compilación", o un híbrido.
En cualquier caso, para programas complejos (un sencillo juego), en mi opinión, un lenguaje "textual" en lugar de "binario" supone muchas más desventajas que ventajas: rendimiento, tamaño, privacidad del código... Pero lo dicho, quizás es que estoy chapado a la antigua, o que simplemente siempre he programado a bajo nivel.
Permiteme que te diga que parece que no tienes mucha idea.
Lo que tu llamas textual se interpretado, como muchos lenguajes, no solo JS, y obviamente tiene sus ventajas y desventajas, pero no solo por el hecho de ser interpretado, sino por los propios interpretes, por definiciones de los lenguajes, etc.
Sobre lo que iba esto, que es flash, decirte que a no ser que recuerde mal, funciona con una version de ecma script, es decir, que es primo hermano de JS, lo que pasa es que el interprete no va en el browser, sino en un ejecutable que se llama de forma externa, y lo han extendido como han querido: graficos vectoriales, formatos privados de video, p2p, acceso a camara/microfono/almacenamiento, puerta trasera para cualquier hacker, etc.
Lo que se esta haciendo ahora mismo con HTML5 (HTML5/ECMA2015/CSS3) es precisamente lo que permitia flash, pero de una forma estandar, de forma que cualquiera puede implementarlo en su browser y funcionar.
Por eso hay cosas increibles con WebGL, con CSS3 y con canvas, y que funcionan en las ultimas versiones.
Es mas, creo recordar que la gente de Unreal y Unity estan portando motores a Web, asi que posiblemente todo sea mucho mas grande que lo que flash permitio
masteries
23/07/2015, 14:50
¿Queréis saber que sucede con las actualizaciones de Flash?
Pues que cada vez está más joven, más mozalbete, no tanto más apuesto... mirad y comparad sus actualizaciones:
44208
44209
^MiSaTo^
23/07/2015, 14:55
Permiteme que te diga que parece que no tienes mucha idea.
Lo que tu llamas textual se interpretado, como muchos lenguajes, no solo JS, y obviamente tiene sus ventajas y desventajas, pero no solo por el hecho de ser interpretado, sino por los propios interpretes, por definiciones de los lenguajes, etc.
Sobre lo que iba esto, que es flash, decirte que a no ser que recuerde mal, funciona con una version de ecma script, es decir, que es primo hermano de JS, lo que pasa es que el interprete no va en el browser, sino en un ejecutable que se llama de forma externa, y lo han extendido como han querido: graficos vectoriales, formatos privados de video, p2p, acceso a camara/microfono/almacenamiento, puerta trasera para cualquier hacker, etc.
Lo que se esta haciendo ahora mismo con HTML5 (HTML5/ECMA2015/CSS3) es precisamente lo que permitia flash, pero de una forma estandar, de forma que cualquiera puede implementarlo en su browser y funcionar.
Por eso hay cosas increibles con WebGL, con CSS3 y con canvas, y que funcionan en las ultimas versiones.
Es mas, creo recordar que la gente de Unreal y Unity estan portando motores a Web, asi que posiblemente todo sea mucho mas grande que lo que flash permitio
Unity salió para web desde el principio pero extendieron a móviles y tal. Unreal lo dudo bastante, y no he oído nada al respecto. De hecho Unreal para móviles tampoco es la mejor opción
Compilar se ha compilado en lenguajes casi toda la vida, y lo dicho, los parsers son tan rápidos que de programar a compilar y ver se tarda la pulsación de un botón, casi el mismo tiempo que tardas de pasar del código HTML a la "vista previa".
En frio es cierto que quizás el ahorro no sea mucho, mientras lo que se programe no haga un uso intensivo de la CPU.
Pero si nos ponemos a pensar que para leer una etiqueta (usando cálculos muy simplificados) usamos 7 ciclos de CPU para cada acceso a memoria... bueno, digamos 2 de media, usando las diversas caches; y que en cada acceso a memoria podemos obtener hasta 4 caracteres (en CPUs de 64 bits, con cada caracter en formato de 16bits, por ejemplo, unicode), podemos tardar tranquilamente 4 ciclos de CPU sólo para la etiqueta <QUOTE>. Si en una parte del programa defines que dicha etiqueta vale el entero 24, en sólo dos ciclos lees esa etiqueta y te sobra espacio para leer 1 o 2 caracteres más.
Si la etiqueta tiene atributos, sólo la lectura podría ser 4 u 8 veces más rápida, y no necesitaría intentar descifrar si la parte del texto que se ha leido es una etiqueta, un atributo, un valor, si está bien o mal escrita, si hay que leer más o menos texto... y esos son varios ciclos más de computación.
Pero claro, no es lo mismo para una web de 300 lineas sin interacción (porque creo que la parte interactiva es javascript ¿no?) que para un programa con 3000 lineas de saltos, bucles y demás :D
Tampoco digo que se hagan las webs en ASM, ni que se deban compilar para X86, ARM, etc, como se menciona en el artículo de webassembly, pero sí usar una sencilla máquina virtual como la de java para "interpretar" los "comandos". Yo lo hice en Venturer y creo que es tremendamente sencillo, incluso una "compilación inversa" es posible.
No lo sé, por eso pregunto.
Sé que se usa HTML, y sé que existe JS con el mismo problema (incluso más grave, si existen estructuras de selección y bucles). Es más, no sé si quiera si la ejecución se realiza al mismo tiempo que se lee, o hay una "pre-compilación", o un híbrido.
En cualquier caso, para programas complejos (un sencillo juego), en mi opinión, un lenguaje "textual" en lugar de "binario" supone muchas más desventajas que ventajas: rendimiento, tamaño, privacidad del código... Pero lo dicho, quizás es que estoy chapado a la antigua, o que simplemente siempre he programado a bajo nivel.
Insistes en darle importancia, en términos de eficiencia, a que el formato de un lenguaje sea binario. En cierto modo eso es coherente con que metas a JavaScript y a HTML en el mismo saco, y con ello pases por alto, por el contrario, a algo que sí la tiene: que el primero es un lenguaje de programación y el segundo no. Tendrás que disculparme, pero no sé si sabría responderte sin escribir un tocho XD, y ahora no dispongo de tiempo ni de ganas para ello. Quizá en otro momento...
Unity salió para web desde el principio pero extendieron a móviles y tal. Unreal lo dudo bastante, y no he oído nada al respecto. De hecho Unreal para móviles tampoco es la mejor opción
Yo recuerdo probar hace al menos uno o dos años la demo de Epic Citadel basada en UE3 en Firefox
Creo que la página ha pasado a mejor vida: https://web.archive.org/web/20140210210113/http://www.unrealengine.com/html5_faq/
https://www.youtube.com/watch?t=15&v=BV32Cs_CMqo
^MiSaTo^
23/07/2015, 17:34
Yo recuerdo probar hace al menos uno o dos años la demo de Epic Citadel basada en UE3 en Firefox
Creo que la página ha pasado a mejor vida: https://web.archive.org/web/20140210210113/http://www.unrealengine.com/html5_faq/
https://www.youtube.com/watch?t=15&v=BV32Cs_CMqo
Eso no fue la movida que hizo Mozilla para promocionar asm.js? Que tb salió un Humble Bundle con eso de hecho
Unity salió para web desde el principio pero extendieron a móviles y tal. Unreal lo dudo bastante, y no he oído nada al respecto. De hecho Unreal para móviles tampoco es la mejor opción
https://www.youtube.com/watch?v=P7EUbO4PW-0
Es mas, creo recordar que Mozilla andaba detras de asm.js, que es un subconjunto de JS que su browser puede optimizar casi a nativo, y que unreal para webgl corria sobre el.
Ahora se han aliado todas las grandes (Mozilla, Opera, Google y Microsoft) para crear wasm, que es una evolucion (toma simplificacion radical) de asm.js para poder tener estos motores y mas cosas sobre browsers.
No digo que sean las mejores opciones, digo que esta ahi, esta optimizando todo, y va a ser algo que se va a usar mucho en el futuro.
^MiSaTo^
23/07/2015, 17:45
https://www.youtube.com/watch?v=P7EUbO4PW-0
Es mas, creo recordar que Mozilla andaba detras de asm.js, que es un subconjunto de JS que su browser puede optimizar casi a nativo, y que unreal para webgl corria sobre el.
Ahora se han aliado todas las grandes (Mozilla, Opera, Google y Microsoft) para crear wasm, que es una evolucion (toma simplificacion radical) de asm.js para poder tener estos motores y mas cosas sobre browsers.
No digo que sean las mejores opciones, digo que esta ahi, esta optimizando todo, y va a ser algo que se va a usar mucho en el futuro.
Me refería a que no es un tema de Unreal en sí, sino de Mozilla no?
Y lo de que se va a usar mucho no lo dudo, para juegos de navegador es infinitamente mejor que Flash
Eso no fue la movida que hizo Mozilla para promocionar asm.js? Que tb salió un Humble Bundle con eso de hecho
Creo que si, al fin y al cabo Epic Citadel solo es una demo técnica, la version web de UT3 creo que nunca la hicieron publica. Pues no tenia ni idea de que hicieran un bundle con eso.
Me refería a que no es un tema de Unreal en sí, sino de Mozilla no?
Y lo de que se va a usar mucho no lo dudo, para juegos de navegador es infinitamente mejor que Flash
Creo que era un 50/50, me suena que los de Unreal no podian hacer correr el motor en el estado de los browsers y mozilla se saco asm.js de la manga para permitir el motor y seguir promocionando html/js que es a lo que se dedica la fundacion mozilla, no nos olvidemos (gran labor)
Creo recordar que los ultimos SDK de Unreal permiten exportar a WebGL, ahora bien, yo del mundo de los videojuegos y de WebGL se bien poco, asi que ni idea de si es compatible con todos los browsers, etc.
Sé que se usa HTML, y sé que existe JS con el mismo problema (incluso más grave, si existen estructuras de selección y bucles). Es más, no sé si quiera si la ejecución se realiza al mismo tiempo que se lee, o hay una "pre-compilación", o un híbrido
JavaScript se compila JIT, al menos en los navegadores más usuales. V8 es el motor para chrome (https://en.wikipedia.org/wiki/V8_%28JavaScript_engine%29) y SpiderMonkey para Firefox (https://en.wikipedia.org/wiki/SpiderMonkey_%28software%29), y ambos usan JIT compilation (https://en.wikipedia.org/wiki/Just-in-time_compilation).
HTML no es binario porque es un lenguaje de marcas, y la velocidad de interpretado no es tan importante como que se interprete bien en todos los ordenadores sean de 16bits, 32bits, 64bits, big or little endian o lo que sea. Prácticamente todos los formatos de documento son etiquetados, incluyendo Microsoft Word, LibreOffice y mil más.
^MiSaTo^
23/07/2015, 17:59
Yo no lo se, pero lo que si tengo entendido es que a Unreal le queda bastante para tirar bien en algo que no sea un PC. Lo se porque para movil estuve mirando porque yo si he usado UE3 en su día, y en todos lados para movil siempre recomiendan Unity. Lo mismo para web.
Mientras estaba buscando la pagina de la demo de Epic Citadel, me encontre con esta pagina de Mozilla: https://developer.mozilla.org/de/demos/
Hay un par de demos interesantes que acabo de probar:
Quake 3 Arena: https://developer.mozilla.org/es/demos/detail/ioquake3js
Obviamente usa los archivos de la version shareware y supuestamente incluye soporte multiplayer
BananaBread: https://developer.mozilla.org/es/demos/detail/bananabread
Que es un port web de Cube 2: Sauerbraten, el multiplayer no esta habilitado.
En mi mierda conexion de 6Mb tardan unos cuantos segundos en cargar. Y vale que no son un portento grafico, pero no dejan de ser juegos bastante complejos para la web.
^MiSaTo^
23/07/2015, 18:02
Anda pues teneis razón y en la web de UE4 sí tienen una sección para HTML5: https://docs.unrealengine.com/latest/INT/Platforms/HTML5/GettingStarted/index.html
Eso sí dicen esto:
Disclaimer:
The HTML5 pipeline is currently experimental. Some projects may not run properly when built for the HTML5 platform. Expect some rough edges.
Pero vamos a mi me huele a quien lo ha movido ha sido Mozilla y no Epic en sí
EDIT: Efectivamente es una herramienta de Mozilla lo que usan para sacar la versión HTML5
HTML5 uses the emscripten tool chain from Mozilla to cross compile C++ into javascript
¿Pero estos motores realizan su ejecución en el servidor o de forma local? Me suena que estos motores se ejecutan en el ordenador cliente, pero hace unos años (creo que fue M$) se hablaba de usar juegos por streaming y aprovechar la potencia de los servidores.
Lo gracioso es que aun no he conseguido hacer funcionar el plugin de Unity en el navegador.
Si, lo mejor que se puede hacer es hacer que el código de una página web dependa del procesador y del sistema operativo que ejecute el navegador. Total, todo el mundo usa un X86 sobre un debian-like.
Por si acaso: que conste que yo no he dicho eso ni lo he querido decir :D:D:D
Insistes en darle importancia, en términos de eficiencia, a que el formato de un lenguaje sea binario. En cierto modo eso es coherente con que metas a JavaScript y a HTML en el mismo saco, y con ello pases por alto, por el contrario, a algo que sí la tiene: que el primero es un lenguaje de programación y el segundo no. Tendrás que disculparme, pero no sé si sabría responderte sin escribir un tocho XD, y ahora no dispongo de tiempo ni de ganas para ello. Quizá en otro momento...
Ya lo he dicho: soy teleco, me han enseñado a ser eficiente, a nivel HW y con tecnologías de hace ya años. Por eso hay cosas que me chocan, como que se compliquen tanto para diseñar páginas web usando HTML, CSS, JS, PHP, etc... y que una cosa tan "sencilla" como que un HTML sea un fichero binario que se pueda leer fácilmente con un programa de edición de webs (sigue siendo transparente de cara al usuario, pero es más entendible por la máquina y "mejor" en muchos aspectos), pues no lo entiendo... del todo.
Prácticamente todos los formatos de documento son etiquetados, incluyendo Microsoft Word, LibreOffice y mil más.
Ojo, esos formatos son así desde principios de los 2000, hasta entonces (Office2000) existían formatos privativos. Te lo digo porque yo he trabajado con los ODT a nivel XML, y de ahí parte de mi "asco" a los ficheros de texto. Al menos en aquel entonces usaba librerías de lectura y comandos de búsqueda, cuando programé Venturer no tenía nada de eso.
Por cierto: JS se compila ¿en servidor o en cliente? porque me suena haber visto código JS usando el navegador, así que, si se compila ¿qué sentido tendría enviar al cliente el código sin compilar? Sólo por saberlo.
Carlos24
23/07/2015, 21:55
Pues con typescript + nodejs + webgl un emulador de psp inicial corriendo a full speed con cpus actuales .
https://github.com/jspspemu/jspspemu
http://jspspemu.com/
Nathrezim
24/07/2015, 09:14
Por cierto: JS se compila ¿en servidor o en cliente? porque me suena haber visto código JS usando el navegador, así que, si se compila ¿qué sentido tendría enviar al cliente el código sin compilar? Sólo por saberlo.
Write once, run anywhere. Si se manda un compilado para la máquina X solo funciona en esa máquina X (y me da igual que sea máquina física o virtual).
BTW, si te pareció un infierno tratar con los ODT... no se que te parecería tratar con documentos binarios del antiguo Office XDXD.
Ya lo he dicho: soy teleco, me han enseñado a ser eficiente, a nivel HW y con tecnologías de hace ya años. Por eso hay cosas que me chocan, como que se compliquen tanto para diseñar páginas web usando HTML, CSS, JS, PHP, etc... y que una cosa tan "sencilla" como que un HTML sea un fichero binario que se pueda leer fácilmente con un programa de edición de webs (sigue siendo transparente de cara al usuario, pero es más entendible por la máquina y "mejor" en muchos aspectos), pues no lo entiendo... del todo.
A ver si no me enrollo XD...
La distinción entre formatos de texto y binarios obedece a un aspecto fundamental que sólo tiene sentido para nosotros: la legibilidad. Para las máquinas no existe esa distinción; todos los formatos son binarios, con la diferencia cuantitativa de que unos serán más concisos que otros.
Optimizar un formato para una máquina significa hacerlo para una máquina (arquitectura) concreta. Esas mejoras pueden no ser portables, o peor aún, resultar contraproducentes en otras. Es decir, estás creando un formato dependiente de la máquina, que es justo lo contrario de lo que quieres si lo vas a usar pare el intercambio de información. Los formatos de texto son precisamente los más portables.
Si te preocupa la eficiencia, supongo que te sonarán cosas como la ley de Amdahl o el Principio de Pareto. Tendrás claro que la ganancia total de optimizar una etapa de un proceso está limitada por el coste relativo que tiene esa etapa dentro de él. Siguiendo el ejemplo que pusiste de las etiquetas, si el coste total del proceso por etiqueta es un orden de magnitud mayor que el coste que tiene su lectura, por mucho que optimices la lectura de las etiquetas, la ganancia no será mayor de un 10 %.
Los lenguajes están caracterizados por su gramática (léxico y sintaxis) y su semántica. El proceso de análisis ("parsing") se suele descomponer en dos etapas que se realizan de manera iterativa: el análisis léxico y el análisis sintáctico. El primero es relativamente fácil y su orden de complejidad es lineal. Para el segundo, el orden de complejidad es dependiente de la gramática y la construcción del árbol sintáctico suele ser la parte más costosa (peor en el caso particular del lenguaje HTML, que no está, de hecho, definido como una gramática formal). Como resultado del análisis se obtiene en memoria una representación válida y significativa de la información. Después viene el procesado semántico de esa información, que puede ser mucho más costoso. En el caso de los lenguajes de programación, los intérpretes tienen que realizar las acciones indicadas por el programa, mientras que la tarea de los compiladores es expresarlas en otro lenguaje. En el caso de los lenguajes para estructurar información, la tarea puede ser representarla o utilizarla de algún modo. Volviendo al ejemplo de las etiquetas, si las codificas de forma binaria, lo que estás haciendo es optimizar el análisis léxico, que es la parte menos costosa de todo el proceso.
Cuanto más simple (semántica y gramaticalmente) es un lenguaje de programación, más largos son los programas y más tedioso y complejo resulta desarrollarlos, pero a cambio, más simple y eficiente es el intérprete. La ganancia de eficiencia del intérprete compensa con creces el incremento de tamaño del programa, con lo que la ejecución es más rápida. Evidentemente esa relación se da, como caso extremo, entre un lenguaje de alto nivel y el lenguaje máquina (siendo su intérprete un intérprete físico, el procesador), pero también se da a cualquier otro nivel. Por eso son tan populares las implementaciones híbridas, en las que (dejando a un lado muchos matices) el programa se traduce primero a un lenguaje intermedio y después se interpreta. El programa se ejecuta más rápido en el lenguaje intermedio que si se interpretase en el lenguaje original; no tan rápido cómo si se hubiese traducido a lenguaje máquina, pero a cambio es portable. Es una solución de compromiso.
El lenguaje intermedio suele ser binario. Cada instrucción va a ser decodificada un número arbitrario de veces (mientras que, como tú decías, en HTML no hay bucles ni procedimientos), y el lenguaje intermedio es producido por un programa y leído por otro. Así que tiene todo el sentido optimizar su léxico hasta ese punto. Pero no hay que perder de vista que la mejora de la eficiencia no es sólo por eso, ni mucho menos, sino fundamentalmente por que se trata de un lenguaje de programación más simple.
Pues con typescript + nodejs + webgl un emulador de psp inicial corriendo a full speed con cpus actuales .
https://github.com/jspspemu/jspspemu
http://jspspemu.com/
¿Y en ordenadores de hace 7 años? esos deberían ser capaces de emular una PSP :D:D:D
Write once, run anywhere. Si se manda un compilado para la máquina X solo funciona en esa máquina X (y me da igual que sea máquina física o virtual).
BTW, si te pareció un infierno tratar con los ODT... no se que te parecería tratar con documentos binarios del antiguo Office XDXD.
Java es compilado, funciona en máquina virtual y hasta ahora nadie se ha quejado de la compatibilidad, ya sea Windos, Linux, ARM o Android :awesome:
También te digo que en ODT tenía que buscar secciones, contar el número de tablas y comprobar los nombres de los campos, por decir algo :D Pero bueno, que hae tiempo estuve peleándome para leer el formato GIF usando Fenix, y casi que lo prefiero, porque no tenía que hacer dos "programas" (parser y decodificador) :P
A ver si no me enrollo XD...
Da igual, enróllate, es más, te agradezco MUCHÍSIMO que lo hayas hecho :)
Pero me refiero a que sería más eficiente usar un "lenguaje intermedio" siempre, especialmente si es un lenguaje que se puede revertir de forma sencilla ¿Que no es mucha carga? Ya lo he dicho, pensado en frío, no, no lo es y da igual. Con la potencia actual se parsea la Biblia en menos de un segundo, pero cuando a ti en la tercera clase de programación (sí, tercera, sin saber nada de nada antes) te dicen "desarrolla un programa que haga X y tarde el menor tiempo posible (cada lectura de variable cuesta 7 ciclos)", pues ya vas desde el minuto uno buscando cada ciclo extra. Súmale que he programado para la GP2X usando Fenix y tienes a alguien al que le han inculcado ahorrar cada byte de la máquina :D:D:D
^MiSaTo^
26/07/2015, 21:35
Java es compilado, funciona en máquina virtual y hasta ahora nadie se ha quejado de la compatibilidad, ya sea Windos, Linux, ARM o Android :awesome:
También te digo que en ODT tenía que buscar secciones, contar el número de tablas y comprobar los nombres de los campos, por decir algo :D Pero bueno, que hae tiempo estuve peleándome para leer el formato GIF usando Fenix, y casi que lo prefiero, porque no tenía que hacer dos "programas" (parser y decodificador) :P
Creo que tienes un error de concepto gordo aquí. Un lenguaje compilado es un lenguaje en el que generas un ejecutable que la máquina corre nativamente.
Sin embargo un lenguaje interpretado, es el que necesita de un intérprete para ejecutarse. En el caso de java, compilas a bytecode y el runtime (la máquina virtual de java) es quien interpreta ese bytecode. Por tanto no es compilado como tal.
Se que a día de hoy hay compiladores JIT pero como hace eones que no uso Java para nada, no se si eso realmente necesita de la JVM o no.
A veces mezclo el concepto "lenguaje compilado" con "programa compilado" ^^U
Porque el lenguaje interpretado necesita compilarse ¿no? Pues eso.
Aunque SplinterGU se queja cuando digo que Bennu es un lenguaje pseudo-interpretado :lol: Entonces ¿Cómo se llamaba a un lenguaje que se ejecutaba leyendo, directamente, el código? como HTML.
Java sigue usando la JVM, pero hoy hay dos excepciones: Android, que integra la JVM con el SO, y lo que decía de las instrucciones Jazelle, que se ejecutan de forma nativa en los microcontroladores.
^MiSaTo^
26/07/2015, 22:15
A veces mezclo el concepto "lenguaje compilado" con "programa compilado" ^^U
Porque el lenguaje interpretado necesita compilarse ¿no? Pues eso.
Aunque SplinterGU se queja cuando digo que Bennu es un lenguaje pseudo-interpretado :lol: Entonces ¿Cómo se llamaba a un lenguaje que se ejecutaba leyendo, directamente, el código? como HTML.
Java sigue usando la JVM, pero hoy hay dos excepciones: Android, que integra la JVM con el SO, y lo que decía de las instrucciones Jazelle, que se ejecutan de forma nativa en los microcontroladores.
Es que HTML es un lenguaje de marcas (de hecho es el acrónimo de HyperText Markup Language). En realidad yo no lo llamaría lenguaje de programación pero eso ya es otra discusión.
Bennu también es interpretado, como lo es python por ejemplo también.
En realidad java se traduce a bytecode, pero no se "compila" como tal.
EDIT: Y Android, por mucho que integre la JVM con el SO, sigue habiendo máquina virtual. No se ahora cómo va ART, pero desde luego Dalkiv lo es. Así que no me vale como excepción tampoco xD
Java tiene compiladores para generar ejecutables nativos, pero no se usan mucho (por no decir nada), aunque java a nivel de usuario final tiene poco, a nivel empresarial es el que corta el bacalao, si quieres una arquitectura con bus de servicios va con java, si compras una herramienta para diseño, monitorización o lo que sea corre en java, si montas una aplicacion web el backend va en java, etc.. y para que funcionen en todas tienes que tener el JVM correspondiente. Lo de android era java con unas comillas muy gordas, el lenguaje si es java pero la maquina virtual no es compatible con la maquina virtual de java (ni la antigua ni la nueva), por lo que todo lo que compiles para android solo corre en android. Lo de Jazelle solo lo tienen los ARM de generaciones antiguas y necesistaba una JVM especial que supiera que tenia esas instrucciones en hardware, los nuevos procesadores no lo llevan, ahora montan un juego de instrucciones que se supone que pueden acelerar cualquier MV (java, c#, etc).
Java tiene compiladores para generar ejecutables nativos, pero no se usan mucho (por no decir nada), aunque java a nivel de usuario final tiene poco, a nivel empresarial es el que corta el bacalao, si quieres una arquitectura con bus de servicios va con java, si compras una herramienta para diseño, monitorización o lo que sea corre en java, si montas una aplicacion web el backend va en java, etc.. y para que funcionen en todas tienes que tener el JVM correspondiente. Lo de android era java con unas comillas muy gordas, el lenguaje si es java pero la maquina virtual no es compatible con la maquina virtual de java (ni la antigua ni la nueva), por lo que todo lo que compiles para android solo corre en android. Lo de Jazelle solo lo tienen los ARM de generaciones antiguas y necesistaba una JVM especial que supiera que tenia esas instrucciones en hardware, los nuevos procesadores no lo llevan, ahora montan un juego de instrucciones que se supone que pueden acelerar cualquier MV (java, c#, etc).
La gente de Ruby y de Node JS no estan de acuerdo con que se use Java para todo lo web.
Nathrezim
27/07/2015, 11:39
La gente de Ruby y de Node JS no estan de acuerdo con que se use Java para todo lo web.
Si es algo gordo Java escala mejor por el monton de tecnologias que se han desarrollado apoyandose en el. Pero vamos, que hablo de oidas yo de desarrollo web solo se lo basico.
^MiSaTo^
27/07/2015, 12:14
La gente de Ruby y de Node JS no estan de acuerdo con que se use Java para todo lo web.
De hecho es que ya no es el rey del backend tampoco. Ahora mismo hay mil alternativas a Java (mejores o peores, eso da para otra discusión). No se en España, pero fuera desde luego veo desarrollos de backend hechos en Node.JS, RoR, Go, Python... aparte de J2EE claro
Si es algo gordo Java escala mejor por el monton de tecnologias que se han desarrollado apoyandose en el. Pero vamos, que hablo de oidas yo de desarrollo web solo se lo basico.
Estaba llorando en el baño.
Usar un stack pesado no escala mejor que usar un stack liviano, como puede ser ruby o node.
Al final depende mas del arte de la gente de sistemas que del framework que tengas por delante, aunque obviamente el framework debe de permitir dicha escalabilidad...
Como comentario decir que veo la actitud de siempre, si no lo usais directamente no existe.
Creo que cada lenguaje y cada framework tiene su nicho, su escenario y su momento, pero muchos tenéis una mania de ningunear lo que no conocéis, como si no existiera mas verdad...
Es como si yo dijese que Java, C# o PHP no tienen nicho, simplemente porque donde yo me muevo no se usen tanto, aunque todos esos lenguajes tienen frameworks web super usados y robustos....
saucjedi
27/07/2015, 12:58
Pero... ¿de verdad hay gente que cataloga HTML como lenguaje de programación? Eso no tiene ningún sentido, jamás habría hecho falta JavaScript de ser así.
A veces mezclo el concepto "lenguaje compilado" con "programa compilado" ^^U
Porque el lenguaje interpretado necesita compilarse ¿no? Pues eso.
Aunque SplinterGU se queja cuando digo que Bennu es un lenguaje pseudo-interpretado :lol: Entonces ¿Cómo se llamaba a un lenguaje que se ejecutaba leyendo, directamente, el código? como HTML.
Java sigue usando la JVM, pero hoy hay dos excepciones: Android, que integra la JVM con el SO, y lo que decía de las instrucciones Jazelle, que se ejecutan de forma nativa en los microcontroladores.
Voy a quedar como un pesado y un pedante por comentar cosas que se consideran de conocimiento general, pero como veo que a veces utilizas de forma confusa algunos términos o conceptos...
Puede entenderse el término "compilación" como sinónimo de traducción, e "interpretación", de ejecución. Es decir, un compilador traduce un programa de un lenguaje a otro; y un intérprete, ya sea lógico o físico (procesador), ejecuta las acciones indicadas en el programa. Pero los usos convencionales de esos términos son casos particulares de las definiciones anteriores. "Compilación" y "compilador" se suelen referir a la traducción de un lenguaje de programación (típicamente de alto nivel) a lenguaje máquina (como ya sabes, si el lenguaje de partida es lenguaje ensamblador, entonces se usan los términos "ensamblado" y "ensamblador"). A veces se usan también para referirse a la traducción a lenguaje intermedio, pero eso no hace que el correspondiente lenguaje de partida se considere compilado (sino que se considerará híbrido, de hecho). Por su parte, los términos "interpretación" e "intérprete" se utilizan sólo en el caso de intérpretes lógicos; es decir, el intérprete es otro programa, no el procesador. En particular, los intérpretes de lenguajes máquina se denominan "emuladores" y los de lenguajes intermedios, "máquinas virtuales" (no confundir, evidentemente, con las utilizadas para ejecutar sistemas operativos).
Por cómo se implementan, los lenguajes de programación se clasifican en tres tipos: compilados, interpretados e híbridos. Los compilados y los interpretados son los que se compilan y los que se interpretan, respectivamente, según el uso convencional de esos términos. Los híbridos son los que primero se traducen a lenguaje intermedio y después se interpretan. La clasificación se refiere a la implementación clásica del lenguaje, ya que pueden existir varias, como es lógico. Por ejemplo, Java es un lenguaje híbrido ya que es así como se diseñó y esa es su implementación clásica, aunque existan otras, como comenta Zhorro. Al igual que C es compilado, aunque existan intérpretes de C. Como también lo es Pascal, aunque existiese, además de intérpretes, una implementación híbrida... Que, por cierto, fue la primera, adelantando a Java en casi dos décadas. Y ya es triste que siendo la innovación más relevante asociada a al lenguaje Pascal, sea un hecho poco conocido incluso entre los aficionados a él.
Esta clasificación resultaba clara antes, pero hoy ya no lo es tanto. En la actualidad la implementación más popular es la híbrida, aunque se haga de manera más o menos transparente. Así, en el caso de los lenguajes de script, que tradicionalmente se consideran lenguajes interpretados, la implementación principal de muchos de ellos ahora es híbrida. Por ejemplo, el intérprete de Perl no es un intérprete puro o un intérprete en el sentido clásico, ya que internamente realiza una implementación híbrida: compila a un lenguaje intermedio y lo ejecuta en la máquina virtual incluida en él. Por otro lado, las máquinas virtuales tienden a acelerarse utilizando compilación en tiempo de ejecución (JIT), por lo que ya dejan de ser intérpretes y pasan a ser compiladores dinámicos.
No sé si lo anterior resuelve más o menos tus dudas. Por si no fuese así, en particular, como ya ha dicho: HTML no es un lenguaje de programación y por tanto no tiene sentido considerarlo interpretado. Supongo que la confusión viene de llamarle programar a escribir código HTML y de ahí asumir que es un lenguaje de programación.
Pero... ¿de verdad hay gente que cataloga HTML como lenguaje de programación? Eso no tiene ningún sentido, jamás habría hecho falta JavaScript de ser así.
Creo recordar que una de las propuestas de HTML6 es precisamente hacer todo con Tags HTML, eliminando a JS del mapa.
Supongo que quedara en nada, JS tiene un peso muy grande hoy en dia como para hacer esa rareza.
Pero si, tienes razon, hoy en dia hablar de HTML sin mas es no tener mucha idea, cuando el 99% es HTML(5)/CSS3/JS(6/ECMA2015/Nombre que toque :P)
IronArthur
27/07/2015, 17:01
Por desgracia, para mi sobre todo, se sigue usando una barbaridad java en mundo empresarial. Por poner un ejemplo de donde yo me muevo, en Gipuzcoa el 80% de trabajo que se mueve de informatica es en JAVA/J2EE
Trabajo con casi cualquier cosa excepto con eso :(
Salu2
Tampoco me parece mal, a mi no me gusta y siempre he intentado huir de ese tipo de entornos, pero generan negocio y puestos de empleo.
Por ejemplo, Android se programa (mayormente, fijo que ahora salta pakoito con Android ndk) en Java, y me resulto muy comodo, pero son mundos distintos (Apps vs consultoria)
^MiSaTo^
27/07/2015, 17:52
Por desgracia, para mi sobre todo, se sigue usando una barbaridad java en mundo empresarial. Por poner un ejemplo de donde yo me muevo, en Gipuzcoa el 80% de trabajo que se mueve de informatica es en JAVA/J2EE
Trabajo con casi cualquier cosa excepto con eso :(
Salu2
Dentro de España, matizo. Fuera de verdad que la cosa es distinta. Al menos en Holanda y por lo que tengo entendido en Alemania también.
Que no digo que no se use, pero que no es tan bestia su uso como en España. Que hay otras cosas
Pero... ¿de verdad hay gente que cataloga HTML como lenguaje de programación? Eso no tiene ningún sentido, jamás habría hecho falta JavaScript de ser así.
Creo que viene más de la "tradición" que de la definición del término: HTML es un lenguaje de uso informático, y la verdad es que se parece más (por lo que conozco) a un fichero de (clasificación de) datos que a un programa. Y esto es una teoría mía, HTML es un lenguaje que se "computa", y "lenguaje computacional" no suena bien, así que alguien dijo que era un lenguaje de programación, porque los usan programadores.
Ciertamente no se puede incluir en la definición de "algoritmo".
De todas formas, Trenz, no sé si ha sido un despiste, pero en tu penultimo párrafo has dicho sobre Perl "compila a un lenguaje intermedio y lo ejecuta en la máquina virtual incluida en él", contradiciendo a Misato: "En realidad java se traduce a bytecode, pero no se "compila" como tal". La definición que tengo de compilar (una frase de 10 segundos perdida en una de tantas clases) efectivamente es la de traducir un lenguaje de alto nivel a código máquina, pero la que se usa allá por donde paso es la de generar un archivo binario a partir de código de alto nivel, ya sea código máquina o código para un intérprete/máquina virtual: lo usan los programadores y los propios programas/entornos.
Lo de Jazelle solo lo tienen los ARM de generaciones antiguas y necesistaba una JVM especial que supiera que tenia esas instrucciones en hardware, los nuevos procesadores no lo llevan, ahora montan un juego de instrucciones que se supone que pueden acelerar cualquier MV (java, c#, etc).
Juer, me siento viejo. Cuando pienso que "los ARM de generaciones antiguas" son el que lleva Pandora, el de la Panda Board o el Samsung Galaxy S2 (o el S3, no recuerdo) de hace 5 años (y eran comercialmente de los primeros).
Como comentario decir que veo la actitud de siempre, si no lo usais directamente no existe.
Creo que cada lenguaje y cada framework tiene su nicho, su escenario y su momento, pero muchos tenéis una mania de ningunear lo que no conocéis, como si no existiera mas verdad...
Es como si yo dijese que Java, C# o PHP no tienen nicho, simplemente porque donde yo me muevo no se usen tanto, aunque todos esos lenguajes tienen frameworks web super usados y robustos....
Creo que esto viene un poco a lo de "a ver quién la tiene más grande", más que nada porque, en los sitios donde busco trabajo, necesitan gente que se especialice en un lenguaje en concreto, por lo que los "curritos" que buscan sólo saben uno o dos lenguajes diferentes, y esto provoca que sean ellos los que intenten convencer a los demás de que "su" lenguaje es el mejor... Aunque he visto peleas de ese tipo que no tienen la excusa del puesto de trabajo, la verdad.
A mi me cuesta poco aprender un nuevo lenguaje, y en el foro hay gente que sabe más de 5 y 6 (aunque sólo "dominen" 2), pero a la hora de la verdad la gente usa lo que le piden o lo que les resulta más cómodo, por lo que usar el lenguaje más apropiado para cada momento queda relegado a una utopía.
En España, para trabajar, el lenguaje usado fue Java hasta hace un par de años, hoy día se está sustituyendo todo por aplicaciones web. Lo digo porque he pasado de ver cientos de ofertas para programadores Java a ser programadores web. El uso de J2SE se ha dividido en J2EE y HTML+JS+loquesea.
^MiSaTo^
27/07/2015, 20:04
A mi me cuesta poco aprender un nuevo lenguaje, y en el foro hay gente que sabe más de 5 y 6 (aunque sólo "dominen" 2), pero a la hora de la verdad la gente usa lo que le piden o lo que les resulta más cómodo, por lo que usar el lenguaje más apropiado para cada momento queda relegado a una utopía.
En España, para trabajar, el lenguaje usado fue Java hasta hace un par de años, hoy día se está sustituyendo todo por aplicaciones web. Lo digo porque he pasado de ver cientos de ofertas para programadores Java a ser programadores web. El uso de J2SE se ha dividido en J2EE y HTML+JS+loquesea.
Varias cosas sobre este párrafo:
- Si no se usa el lenguaje más apropiado es porque o bien los programadores no son buenos o bien (en muchísimos casos) porque la empresa es una mierda y el jefe dice que hay que hacer X y eso se hace, aunque no tenga ni idea. Afortunadamente no todos los sitios son así y se pueden hacer las cosas bien.
- Tu última frase... J2SE se ha usado poco, era mayoritariamente J2EE porque es de lo que más había y hay en España. Y esto te lo digo porque hace como 12 años que trabajo programando y lo he visto desde el principio. Era web antes también.
Pues no sé entonces si es que hay muchas empresas que no saben lo que hacen o es que realmente Java era la mejor alternativa en su momento (se ejecuta en local, es multiplataforma, fácil de programar, uso de BBDD...) y ahora han decidido centralizar el trabajo en los servidores.
Conozco un caso en el que se diseñó una interfaz en Swing, que iba a ser sustituido por formularios web (por ser más sencillo de programar, de usar, etc)... y aun así se reportaban los errores con Swing para ser arreglados.
Por cierto, lo que yo nunca he entendido es la diferencia entre J2SE y J2EE, no he encontrado una definición que me lo explique más allá de "J2EE hace uso de herramientas de red y de Bases de Datos", y estudiando J2SE he usado herramientas de ambas cosas (muy por encima, pero he usado tres librerías diferentes de SQL).
Basta de mariconadas, hay que programar en C/C++ nada de tener ayuda para no perder memoria o dejar ficheros abiertos, etc, hay que hacer las cosas bien.
Nathrezim
27/07/2015, 21:16
- Si no se usa el lenguaje más apropiado es porque o bien los programadores no son buenos o bien (en muchísimos casos) porque la empresa es una mierda y el jefe dice que hay que hacer X y eso se hace, aunque no tenga ni idea. Afortunadamente no todos los sitios son así y se pueden hacer las cosas bien.
En la mayoría de los sitios hay plataforma heredada, no se empieza un mega sistema desde cero, con lo que tienes que que adaptarte a su plataforma o buscarte / currarte los conectores para acoplarte a su tecnología.
-----Actualizado-----
Por cierto, lo que yo nunca he entendido es la diferencia entre J2SE y J2EE, no he encontrado una definición que me lo explique más allá de "J2EE hace uso de herramientas de red y de Bases de Datos", y estudiando J2SE he usado herramientas de ambas cosas (muy por encima, pero he usado tres librerías diferentes de SQL).
Si te bajas las librerias de desarrollo web, mensajes y bases de datos J2SE y J2EE es lo mismo.
-----Actualizado-----
Basta de mariconadas, hay que programar en C/C++ nada de tener ayuda para no perder memoria o dejar ficheros abiertos, etc, hay que hacer las cosas bien.
Y cuando hay que machacar matrices grandes de números OpenCL e ya.
En la mayoría de los sitios hay plataforma heredada, no se empieza un mega sistema desde cero, con lo que tienes que que adaptarte a su plataforma o buscarte / currarte los conectores para acoplarte a su tecnología.
Lo malo es que muchas veces el código heredado merecería la pena darle un buen repaso, no digo escribirlo desde cero, pero si dividir las clases tochas en otras mas pequeñas, añadir pruebas automáticas, usar librerías mas estándar en vez de tanto código propio, etc.
Pero claro, eso es echar horas sin añadir nada nuevo y eso lo ven como una perdida de tiempo en vez de una inversión para ser mas productivos en el futuro.
Nathrezim
27/07/2015, 21:30
Lo malo es que muchas veces el código heredado merecería la pena darle un buen repaso, no digo escribirlo desde cero, pero si dividir las clases tochas en otras mas pequeñas, añadir pruebas automáticas, usar librerías mas estándar en vez de tanto código propio, etc.
Pero claro, eso es echar horas sin añadir nada nuevo y eso lo ven como una perdida de tiempo en vez de una inversión para ser mas productivos en el futuro.
El tema no esta en refactorizar y en meter la tijera, que se tarda poco, sino en en hacer las pruebas de regresión, que dependiendo del garito ni hay tiempo, ni sistema para correrlo, ni usuarios que quieran participar en las pruebas.
De todas formas, Trenz, no sé si ha sido un despiste, pero en tu penultimo párrafo has dicho sobre Perl "compila a un lenguaje intermedio y lo ejecuta en la máquina virtual incluida en él", contradiciendo a Misato: "En realidad java se traduce a bytecode, pero no se "compila" como tal". La definición que tengo de compilar (una frase de 10 segundos perdida en una de tantas clases) efectivamente es la de traducir un lenguaje de alto nivel a código máquina, pero la que se usa allá por donde paso es la de generar un archivo binario a partir de código de alto nivel, ya sea código máquina o código para un intérprete/máquina virtual: lo usan los programadores y los propios programas/entornos.
Quizá hubiese quedado más claro con el término "traducir", que es el que siempre utilicé al referirme al lenguaje intermedio, pero verás que es un uso coherente con lo que expliqué antes y que no hay contradicción con lo que dijo Misato. Me cito a mí mismo:
"Compilación" y "compilador" se suelen referir a la traducción de un lenguaje de programación (típicamente de alto nivel) a lenguaje máquina (como ya sabes, si el lenguaje de partida es lenguaje ensamblador, entonces se usan los términos "ensamblado" y "ensamblador"). A veces se usan también para referirse a la traducción a lenguaje intermedio, pero eso no hace que el correspondiente lenguaje de partida se considere compilado (sino que se considerará híbrido, de hecho).
Fíjate que a javac se le llama el compilador de Java, y a su uso, compilar, pero Java no es un lenguaje compilado porque no se compila en el sentido convencional del término. No es raro que haya cierta ambigüedad en la terminología, y eso no es un problema siempre que se sea consciente de ello y los conceptos estén claros. El problema viene cuando sucede lo contrario y por un uso descuidado del lenguaje acaban extendiéndose conceptos erróneos, como el de que HTML es un lenguaje de programación.
La gente de Ruby y de Node JS no estan de acuerdo con que se use Java para todo lo web.
No estoy diciendo que para toda la web se haga en Java, lo que he dicho es que para entornos empresariales se usa mayoritariamente java para la parte de backend, la parte frontend suele ser mas variada y las he visto con framework comerciales java y cada vez mas con framework js.
-----Actualizado-----
De hecho es que ya no es el rey del backend tampoco. Ahora mismo hay mil alternativas a Java (mejores o peores, eso da para otra discusión). No se en España, pero fuera desde luego veo desarrollos de backend hechos en Node.JS, RoR, Go, Python... aparte de J2EE claro
Dentro de España sigue siendo el rey del backend en las empresas, las empresas grandes se resisten a cambiar y mas sus departamentos de producción, solo hay que ver algunas (y no pocas) que todavia trabajan con aplicaciones Cobol y no son solamente Bancos (ECI p.e.). El cambiar cuesta mucha pasta y tiempo y si funciona pues lo mantienen, como ejemplo los bancos han tenido X25 en los cajeros hasta que las empresas que les daban el servicio no pudieron garantizar el servicio por falta de componentes y mientras el resto del mundo trabajando con TCP/IP desde hacia muchos años.
^MiSaTo^
27/07/2015, 23:32
Dentro de España sigue siendo el rey del backend en las empresas, las empresas grandes se resisten a cambiar y mas sus departamentos de producción, solo hay que ver algunas (y no pocas) que todavia trabajan con aplicaciones Cobol y no son solamente Bancos (ECI p.e.). El cambiar cuesta mucha pasta y tiempo y si funciona pues lo mantienen, como ejemplo los bancos han tenido X25 en los cajeros hasta que las empresas que les daban el servicio no pudieron garantizar el servicio por falta de componentes y mientras el resto del mundo trabajando con TCP/IP desde hacia muchos años.
Pues lo que he dicho unos posts más atrás, que en España si lo será pero fuera ya no tanto. No digo que no se use ojo, digo que ya no es el rey indiscutible del backend que desde hace un tiempo hay alternativas y se usan también.
Por desgracia en España vamos muy retrasados en muchas cosas
saucjedi
28/07/2015, 09:03
Creo que viene más de la "tradición" que de la definición del término: HTML es un lenguaje de uso informático, y la verdad es que se parece más (por lo que conozco) a un fichero de (clasificación de) datos que a un programa. Y esto es una teoría mía, HTML es un lenguaje que se "computa", y "lenguaje computacional" no suena bien, así que alguien dijo que era un lenguaje de programación, porque los usan programadores.
Ciertamente no se puede incluir en la definición de "algoritmo".
Pero es que eso la gente se lo saca de la manga. A poco que mires el lenguaje es más que evidente que es de marcado, te etiqueta partes, tablas... vamos, que define qué es cada parte del texto... HTML no tiene bucles, saltos, variables... no tiene flujo de programa, ni nada que se le parezca.
Otra cosa es que el personal toque de oído... ahí no me meto. Pero asumir que es un lenguaje de programación... es no saber lo que es un lenguaje de programación.
No estoy diciendo que para toda la web se haga en Java, lo que he dicho es que para entornos empresariales se usa mayoritariamente java para la parte de backend, la parte frontend suele ser mas variada y las he visto con framework comerciales java y cada vez mas con framework js.
-----Actualizado-----
Dentro de España sigue siendo el rey del backend en las empresas, las empresas grandes se resisten a cambiar y mas sus departamentos de producción, solo hay que ver algunas (y no pocas) que todavia trabajan con aplicaciones Cobol y no son solamente Bancos (ECI p.e.). El cambiar cuesta mucha pasta y tiempo y si funciona pues lo mantienen, como ejemplo los bancos han tenido X25 en los cajeros hasta que las empresas que les daban el servicio no pudieron garantizar el servicio por falta de componentes y mientras el resto del mundo trabajando con TCP/IP desde hacia muchos años.
Para desarrollos nuevos se estudia que se va a utilizar, porque si se va a contratar a un equipo de desarrollo pues se mira que tecnologías convienen y se contrata a un equipo competente con esas tecnologías. Para mantenimiento de lo antiguo pues se suele emplear lo antiguo mientras se hace un reemplazo.
PD: Alguno de mis sistemas aún usa líneas x.25. En cada corporación el Rey de los lenguajes es lo que diga el gurú local. Discutir de lenguajes de programación es una pérdida de tiempo taaaaan grande que es completamente inútil.
PD2: La red IBERPAC UNO (ya apagada, lo que queda es IBERPAC DOS) fue la primera red pública de datos del mundo, para vuestra información.
Offtopic: Ayer iba andando y escuche a un tio hablando con dos tias, le dice algo de que si quiere trabajar con ordenadores o algo de informática (supongo que de secretaria, ofimatica) tiene que tener algun titulo y hacer algun curso donde tendrás que, esto lo dijo literalmente: apagar, encender el ordenador... XDXDXDXDXDXD.
Lo malo es que muchas veces el código heredado merecería la pena darle un buen repaso, no digo escribirlo desde cero, pero si dividir las clases tochas en otras mas pequeñas, añadir pruebas automáticas, usar librerías mas estándar en vez de tanto código propio, etc.
Pero claro, eso es echar horas sin añadir nada nuevo y eso lo ven como una perdida de tiempo en vez de una inversión para ser mas productivos en el futuro.
http://www.nothappypath.es/post/124826119237/si-funciona-no-lo-toques
Basta de mariconadas, hay que programar en C/C++ nada de tener ayuda para no perder memoria o dejar ficheros abiertos, etc, hay que hacer las cosas bien.
Estoy contigo, siempre he pensado que Java es un devora-recursos: vale, las listas son muy sencillas de usar, pero reservan memoria en potencias de dos, y ya sabemos lo que le pasó al Rey que quiso llenar un tablero de ajedrez con los granos de cereal.
Pero estamos en las mismas: las máquinas de hoy son lo suficientemente potentes como para tragar con eso y optimizarlo no sale a cuenta, pese a que Java incorpora herramientas avanzadas para ello.
Lo malo es que muchas veces el código heredado merecería la pena darle un buen repaso, no digo escribirlo desde cero, pero si dividir las clases tochas en otras mas pequeñas, añadir pruebas automáticas, usar librerías mas estándar en vez de tanto código propio, etc.
Pero claro, eso es echar horas sin añadir nada nuevo y eso lo ven como una perdida de tiempo en vez de una inversión para ser mas productivos en el futuro.
El tema no esta en refactorizar y en meter la tijera, que se tarda poco, sino en en hacer las pruebas de regresión, que dependiendo del garito ni hay tiempo, ni sistema para correrlo, ni usuarios que quieran participar en las pruebas.
A mi me cosían a bugs en mi último proyecto, pero todo era "esto no funciona" o "esto no sale". Sólo una decía "falta de rendimiento" ¿En serio? ¿tardaba para cada prueba 5 minutos y eso era un bug menor? Pero poco se puede hacer cuando "desde arriba" te dicen que debes mantener ciertas cosas. Menos mal que uno es creativo y con siete líneas (claro que antes tuve que "memorizar" todo el código) pude reducir los tiempos a 3 minutos.
Es lo malo de la programación: las cosas importantes, las que más tiempo llevan, se hacen por debajo, y los que toman decisiones y marcan los tiempos, sólo admiran la fachada.
Dentro de España sigue siendo el rey del backend en las empresas, las empresas grandes se resisten a cambiar y mas sus departamentos de producción, solo hay que ver algunas (y no pocas) que todavia trabajan con aplicaciones Cobol y no son solamente Bancos (ECI p.e.). El cambiar cuesta mucha pasta y tiempo y si funciona pues lo mantienen, como ejemplo los bancos han tenido X25 en los cajeros hasta que las empresas que les daban el servicio no pudieron garantizar el servicio por falta de componentes y mientras el resto del mundo trabajando con TCP/IP desde hacia muchos años.
En defensa de las empresas hay que decir que es mejor desarrollar aplicaciones con tecnologías ya probadas y estables, que en otras nuevas en las que un bug te puede llevar días hasta darte cuenta de que no es problema del código en sí. Existiendo Java6 se programaba en Java5, cuando salió Java7, los nuevos proyectos dieron el salto a Java6, pero los anteriores permanecieron en Java5 (a menos que alguien se entretuviera en su tiempo libre en comprobar que se podía recompilar en Java6 sin ninguna pega).
De todas formas, tenía entendido que Cobol se usa porque es el sistema más estable y seguro que existe, a pesar de las nuevas tenologías.
^MiSaTo^
28/07/2015, 15:41
Os recomiendo a todos los que programais que os leais el enlace de otto. Es cortito pero desde luego es como se deben hacer las cosas.
Os recomiendo a todos los que programais que os leais el enlace de otto. Es cortito pero desde luego es como se deben hacer las cosas.
Escrito por el que posiblemente sea el desarrollador mas infrautilizado de todo este pais.
^MiSaTo^
28/07/2015, 15:52
Escrito por el que posiblemente sea el desarrollador mas infrautilizado de todo este pais.
No se quién es el autor, no me dice nada lo de "not happy path" :/
Pero sea quien sea, si dice eso no es mal programador
No se quién es el autor, no me dice nada lo de "not happy path" :/
Pero sea quien sea, si dice eso no es mal programador
Le dire que se haga mas autobombo, porque estamos faltos de tios como el.
Casi le meto donde estoy ahora, pero se me escapo por timing xD
Nathrezim
28/07/2015, 16:06
Estoy contigo, siempre he pensado que Java es un devora-recursos: vale, las listas son muy sencillas de usar, pero reservan memoria en potencias de dos
Eso es dependiendo de la implementación de lista que elijas, simpre puedes crearte tu propia implementación de lista que reserve de uno en uno, y funcionará en cualquier circunstancia igual que la implemantación que estabas usando (supongo que la ArrayList que es la suele usar todo el mundo por defecto). Eso si, siempre y cuando programes bien y uses la interfaz en vez de usar la implementacion XD.
...
De todas formas, tenía entendido que Cobol se usa porque es el sistema más estable y seguro que existe, a pesar de las nuevas tenologías.
Las tecnologias antiguas se mantienen porque el coste de migrar los sistemas es mas alto que pagar un paston a un guru.
Si el coste de migrar el HW + SW (horas de desarrollo) fuera mas barato que mantener lo que hay, te aseguro que ahora mismo estarían usando cualquier otra tecnologia.
^MiSaTo^
28/07/2015, 16:20
Las tecnologias antiguas se mantienen porque el coste de migrar los sistemas es mas alto que pagar un paston a un guru.
Si el coste de migrar el HW + SW (horas de desarrollo) fuera mas barato que mantener lo que hay, te aseguro que ahora mismo estarían usando cualquier otra tecnologia.
Aparte de que en muchos casos no entienden el "hay que refactorizar" y similares. Sumado a lo que tú dices hace que haya Cobol aún en los bancos xD
Aparte de que en muchos casos no entienden el "hay que refactorizar" y similares. Sumado a lo que tú dices hace que haya Cobol aún en los bancos xD
Hoy vengo de tener una tocha porque no les entra que estamos usando malas convenciones de código y no me aprueban los PR cuando sigo las estándares.
Ainnnnnns
^MiSaTo^
28/07/2015, 17:06
Hoy vengo de tener una tocha porque no les entra que estamos usando malas convenciones de código y no me aprueban los PR cuando sigo las estándares.
Ainnnnnns
Yo me alegro de estar en una empresa donde quien manda no es el cliente ni los jefecillos de turno sino los curritos (aka mayormente los programadores) ;)
Yo me alegro de estar en una empresa donde quien manda no es el cliente ni los jefecillos de turno sino los curritos (aka mayormente los programadores) ;)
Lo mio ha sido con programadores....
^MiSaTo^
28/07/2015, 17:40
Lo mio ha sido con programadores....
De esas aquí he tenido pocas la verdad. Es raro porque los holandeses pa eso si que tienen la mente muy abierta a negociar y llegar a acuerdos y los españoles somos cabezones. Tus compis de donde son?
Adoble Flash estaba bien al principio, cuando era ligero y sólo para animaciones. Pero lo han llenado de basura, igual que han hecho con el formato PDF, que le han metido Javascript, multimedia, enlaces y mil mierdas. Se les ha ido de las manos totalmente, a final van a poder meter hasta virus en los PDF, si no lo están haciendo ya.
De esas aquí he tenido pocas la verdad. Es raro porque los holandeses pa eso si que tienen la mente muy abierta a negociar y llegar a acuerdos y los españoles somos cabezones. Tus compis de donde son?
Holandeses, pero debe de ser que son de los que no tienen la mente abierta a negociar. Y si, yo soy cabezon, pero es que veo tantas convenciones rotas que me puede xD
Al final para convencerles de algo tengo que trabajar doble, no vale con razonarles, tengo que razonar y aportar pruebas + razonamiento + bibliografia.
Que no esta mal, pero creo que es mucho trabajo para pedir que quiten una regla de un linter o que se use una convención de forma correcta.
^MiSaTo^
28/07/2015, 19:10
Holandeses, pero debe de ser que son de los que no tienen la mente abierta a negociar. Y si, yo soy cabezon, pero es que veo tantas convenciones rotas que me puede xD
Al final para convencerles de algo tengo que trabajar doble, no vale con razonarles, tengo que razonar y aportar pruebas + razonamiento + bibliografia.
Que no esta mal, pero creo que es mucho trabajo para pedir que quiten una regla de un linter o que se use una convención de forma correcta.
Si no lo digo porque seas tú cabezón, que yo también lo soy. Digo que yo lo que he visto por aquí (no sólo en mi empresa, porque tratamos con otras también) suele ser que les gusta sentarse a "negociar". De hecho no he visto nunca el típico caso de cliente quiere X y lo quiere porque para eso es el que paga, tipo en España. Los clientes que tenemos son muy tochos (siendo un banco por ejemplo uno de ellos) y no suelen llevar esa actitud. Por eso me extrañaba.
Por supuesto que ********** hay en todos lados.
No problem, se que no iba por mi, pero si, soy muy cabezon, es uno de mis mayores defectos y otra de mis mayores virtudes, defiendo mi posición razonandola (casi siempre xD)
Aqui parece que se quieren sentar a debatir, pero nunca encuentran el momento.
Cierto es que tenemos un pico de trabajo, pero me encuentro con un no por delante muchas veces. Sin que lo razonen.
Para desarrollos nuevos se estudia que se va a utilizar, porque si se va a contratar a un equipo de desarrollo pues se mira que tecnologías convienen y se contrata a un equipo competente con esas tecnologías. Para mantenimiento de lo antiguo pues se suele emplear lo antiguo mientras se hace un reemplazo.
PD: Alguno de mis sistemas aún usa líneas x.25. En cada corporación el Rey de los lenguajes es lo que diga el gurú local. Discutir de lenguajes de programación es una pérdida de tiempo taaaaan grande que es completamente inútil.
PD2: La red IBERPAC UNO (ya apagada, lo que queda es IBERPAC DOS) fue la primera red pública de datos del mundo, para vuestra información.
Y el TESYS 1 la primera maquina de conmutacion de paquetes del mundo que era la que daba soporte a la red X25 y era Española, fusilada despues por Nortel. Como curiosidad la implementación de Telefonica del X25 se hizo sobre el draft del protocolo, todavia no estaba cerrado y si se mira la documentación actual de x25 se ven cosas como para hacer x se utiliza el valor 25 o el 12 por compatibilidad con Telefonica :).
Ahora solo vendemos playas.
Y el TESYS 1 la primera maquina de conmutacion de paquetes del mundo que era la que daba soporte a la red X25 y era Española, fusilada despues por Nortel. Como curiosidad la implementación de Telefonica del X25 se hizo sobre el draft del protocolo, todavia no estaba cerrado y si se mira la documentación actual de x25 se ven cosas como para hacer x se utiliza el valor 25 o el 12 por compatibilidad con Telefonica :).
Ahora solo vendemos playas.
Nortel quebró (y no la compró nadie) dejando tiradas a un montón de empresas que usaban sus equipos (al quedarse sin un soporte que habían ya pagado) y Telefónica perdura perenne como Jordi Hurtado.
En cuanto al tema de chiringuitos y playas igual cambia el tema. Entre los que han decidido que no quede un metro cuadrado de costa sin construir, y los que han decidido que es mejor hundir a Grecia y convertirles en el hotel barato con playa de Europa parece que esto toca a su fin.
Os recomiendo a todos los que programais que os leais el enlace de otto. Es cortito pero desde luego es como se deben hacer las cosas.
Es más o menos lo que dicen todos los profesores de programación: no copies el código, entiéndelo y escríbelo (justo un minuto antes de que salte alguien diciendo que no le compila y es porque ha hecho copia/pega y el compilador no le admite las comillas).
Hay veces que por mucho que quieras, no hay forma de entender lo que ha escrito otro. Me dijeron un caso en el que un código contenía el siguiente comentario: "esta fórmula es mágica, no tocar". O que te pasan una expresión regular de la leche (tres líneas en el bloc de notas) y tienes que ir entendiéndola parte por parte (hasta que a alguien se le ocurre la idea de fraccionarla y unirla por código, y llevarse una bronca por perder varias horas de "trabajo inutil").
Eso es dependiendo de la implementación de lista que elijas, simpre puedes crearte tu propia implementación de lista que reserve de uno en uno, y funcionará en cualquier circunstancia igual que la implemantación que estabas usando (supongo que la ArrayList que es la suele usar todo el mundo por defecto). Eso si, siempre y cuando programes bien y uses la interfaz en vez de usar la implementacion XD.
Tanto ArrayList como todas las herederas de List tienen un método de reserva de memoria manual, pero había no se qué lio con el recolector de basuras u otro método automático de los que hay por detrás, especialmente para liberar la memoria.
Lo que me llama la atención es que todo el mundo en Java usa ArrayList por defecto, cuando una LinkedList, en el 40% de los casos, es lo más apropiado. Es como si no supieran que existe o cómo funciona... Bueno, yo no he leido la implementación tampoco ^^U
Las tecnologias antiguas se mantienen porque el coste de migrar los sistemas es mas alto que pagar un paston a un guru.
Si el coste de migrar el HW + SW (horas de desarrollo) fuera mas barato que mantener lo que hay, te aseguro que ahora mismo estarían usando cualquier otra tecnologia.
¿Pero no ha habido tiempo en cuanto? ¿40 años? En ese tiempo se ha pasado de C a C++ e incluso a varias versiones de Java ¿Por qué Cobol aguanta tanto?
Y si, yo soy cabezon, pero es que veo tantas convenciones rotas que me puede xD
A veces romper una convención es más fácil de lo que parece.
Caso concreto: el operador "+" en Java con strings NO está recomendado, debe usarse String.concat() (porque el operador "+", por lo visto, internamente, realiza una operación concat por cada caracter de la segunda string), y todo el mundo usa "+" indiscriminadamente.
No problem, se que no iba por mi, pero si, soy muy cabezon, es uno de mis mayores defectos y otra de mis mayores virtudes, defiendo mi posición razonandola (casi siempre xD)
Creo que es una constante en informáticos y electrónicos. Si me apuras, en cualquier tipo de ingeniero. Creo que es la cualidad que consigue que superemos nuestras respectivas carreras :awesome:
^MiSaTo^
29/07/2015, 16:11
Es más o menos lo que dicen todos los profesores de programación: no copies el código, entiéndelo y escríbelo (justo un minuto antes de que salte alguien diciendo que no le compila y es porque ha hecho copia/pega y el compilador no le admite las comillas).
Hay veces que por mucho que quieras, no hay forma de entender lo que ha escrito otro. Me dijeron un caso en el que un código contenía el siguiente comentario: "esta fórmula es mágica, no tocar". O que te pasan una expresión regular de la leche (tres líneas en el bloc de notas) y tienes que ir entendiéndola parte por parte (hasta que a alguien se le ocurre la idea de fraccionarla y unirla por código, y llevarse una bronca por perder varias horas de "trabajo inutil").
Si no entiendes lo que otro ha escrito es porque el código es una mierda, y por tanto quien ha escrito ese código no es buen programador.
¿Pero no ha habido tiempo en cuanto? ¿40 años? En ese tiempo se ha pasado de C a C++ e incluso a varias versiones de Java ¿Por qué Cobol aguanta tanto?
Por lo que hemos dicho más arriba
A veces romper una convención es más fácil de lo que parece.
Caso concreto: el operador "+" en Java con strings NO está recomendado, debe usarse String.concat() (porque el operador "+", por lo visto, internamente, realiza una operación concat por cada caracter de la segunda string), y todo el mundo usa "+" indiscriminadamente.
Las convenciones/reglas de estilo están para seguirlas. Eso va a misa, porque sino el código es el ch0cho de la bernarda.
Creo que es una constante en informáticos y electrónicos. Si me apuras, en cualquier tipo de ingeniero. Creo que es la cualidad que consigue que superemos nuestras respectivas carreras :awesome:
No no lo es. Eso depende de la persona. Además a mi no me importa que discutamos por algo siempre que se haga razonadamente. Yo soy cabezona, pero también cuando me equivoco se reconocerlo.
No no lo es. Eso depende de la persona. Además a mi no me importa que discutamos por algo siempre que se haga razonadamente. Yo soy cabezona, pero también cuando me equivoco se reconocerlo.
Eso es lo que la gente no entiende.
El código que escribía de cuando empece a programar a ahora no se parece en nada, pero tampoco lo hace el codigo de cuatro años a esta parte, y en buena parte es por haber tenido compañeros con los que poder discutir y razonar, habiendo absorbido mucho conocimiento, y habiendo aportado tambien otra buena parte del mismo
En el fondo nuestra profesion va de eso, de no parar de aprender, de quedarte con las mejores partes y de intentar (si se tiene el conocimiento y te dejan) enseñar otras buenas costumbres al resto del equipo
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.