Samsung prepara su Exynos de 64 bits para el Galaxy S5

[Harry]

Samsung prepara su Exynos de 64 bits para el Galaxy S5

http://img12.imageshack.us/img12/7132/cj4b.jpg

Leemos en elchapuzasinformatico.com


http://www.htcmania.com/images/smilies/q.gif Samsung anunció que se encuentra dando los toques finales a la próxima generación de SoC Exynos, el cual cuenta con cuatro núcleos ARM de 64 bits basados en la arquitectura big.LITTLE Cortex-A57 de alto rendimiento acompañados de otros cuatro núcleos Cortex-A53 de bajo consumo con HMP habilitado, informando que el desarrollo del Galaxy S5 está en pleno apogeo. Cuando esté listo, el chip Exynos de 64 bits será el primero en dar vida a un smartphone Android de 64 bits, esperando que esta responsabilidad recaiga sobre el Galaxy S5 que seguirá los pasos de la arquitectura de 64 bits del iPhone 5S. http://www.htcmania.com/images/smilies/q2.gif

leer más: elchapuzasinformatico.com (http://elchapuzasinformatico.com/2013/09/samsung-prepara-su-exynos-de-64-bits-para-el-galaxy-s5/)

[Harry]

http://elchapuzasinformatico.com/2013/09/samsung-prepara-su-exynos-de-64-bits-para-el-galaxy-s5/

http://elchapuzasinformatico.com/2013/09/samsung-prepara-su-exynos-de-64-bits-para-el-galaxy-s5/

[AdriANS620]

Com si quieren introducir un procesador de 128 bits y 16 Gb de ram. Si Android no se optimiza y evoluciona poco va a cambiar la cosa

[santinhos]

Estos de Samsung que eficientes son: se han puesto a investigar el tema de los 64 bits justo después de la keynote de Apple y ya lo tiene casi hecho?
:D:D:D:D:D

[LCBSeGiO]

:facepalm:

[Mr.Backup]

Hace falta mucha más optimización para poder sacarle jugo a esos 64 Bits. Claro que, desde el punto de vista mercadotécnico, los 64 bits venden. Se usen o no.

[eepeep]

Normal.... A. Ver si google y los fabricantes optimizan mejor el sistema con la llegada de la nueva arquitectura del procesador

[Pleomax]

Que optimicen el consumo de la batería de paso.

[FINTA96]

No hay apps 64 bits, con las de 32 sobra. Puro marketing por parte de apple y samsung

[DaSound]

La de tonterías que hay que leer... los 64bits sirven, entre otras cosas, para poder direccionar 4Gb de RAM, que será lo que posiblemente traiga el S5 o el Note4... no es por otra cosa!!! mañana lo será, hoy es básicamente por eso!!

¿Quién ha dicho que sea para Android?... quizá los fabrican pensando en Tizen que puede ser que sí los aproveche, así como el multihilo... y los montan en los 2, para qué fabricar 2 distintos.


Mañana será Qualcomm quien los presente, y será el DIOS!! se celebrarán fiestas, se ofrecerán presentes, se esculpirán estatuas y compondrán canciones y sonetos. Y sino, al tiempo.

[frkhtcmania]

Estos de Samsung que eficientes son: se han puesto a investigar el tema de los 64 bits justo después de la keynote de Apple y ya lo tiene casi hecho?
:D:D:D:D:D

Supongo porque antes les habrán dicho los de Samsung a los de la manzanita que su A8 estará listo sin problemas...ya que Samsung es la encargada de fabricar el corazón del iphone 5S...el A7

¿que no lo sabías? :silbando:

[rafarodri04]

y todo para que siga habiendo lags... android necesita mejorar el software, no el hardware...

[DaSound]

Supongo porque antes les habrán dicho los de Samsung a los de la manzanita que su A8 estará listo sin problemas...ya que Samsung es la encargada de fabricar el corazón del iphone 5S...el A7

¿que no lo sabías? :silbando:

Realmente Samsung ya no fabricó el A7... se quedó en el A6, el A7 lo fabrica TSMC.

[Sr_Lobo]

Estos de Samsung que eficientes son: se han puesto a investigar el tema de los 64 bits justo después de la keynote de Apple y ya lo tiene casi hecho?
:D:D:D:D:D

Que lo estaban estudiando: Sin duda.

Que lo sacan ahora porque lo sacó Apple la semana pasada: Sin duda también.

En ambos casos es marketing puro y duro, pero es aplicable a las dos por igual.

Aquí ni hay santos ni demonios... Son empresas y punto.

[santinhos]

Que lo estaban estudiando: Sin duda.

Que lo sacan ahora porque lo sacó Apple la semana pasada: Sin duda también.

En ambos casos es marketing puro y duro, pero es aplicable a las dos por igual.

Aquí ni hay santos ni demonios... Son empresas y punto.
No lo sacan ahora, lo sacan supuestamente con el S5. Y el motivo es el que señala DaSound: los 4 gbs de RAM.
Personalmente no le veo sentido a darle más vueltas al asunto...

[htc4ever]

Com si quieren introducir un procesador de 128 bits y 16 Gb de ram. Si Android no se optimiza y evoluciona poco va a cambiar la cosa



Eso mismo digo yo . De que sirve poner un Hardware muy potente si Android no optimiza su SO . Lo que no puede ser que Apple con menos Hardware vaya bastante mejor que Android :loco: , no entiendo nada

[juliohdl]

Pedazo de pepinaco que será el Galaxy 5. jajajaja, y la batería va a durar 2 horas y se va a calentar tanto que vas a hacer palomitas en ella.

[DaSound]

Eso mismo digo yo . De que sirve poner un Hardware muy potente si Android no optimiza su SO . Lo que no puede ser que Apple con menos Hardware vaya bastante mejor que Android :loco: , no entiendo nada

Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.

iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo.

Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C.

Saludos.

[MDLSoft]

Realmente Samsung ya no fabricó el A7... se quedó en el A6, el A7 lo fabrica TSMC.

Pues creo que te equivocas, parece que el A7 vuelve a estar fabricado por Samsung:

http://www.chipworks.com/en/technical-competitive-analysis/resources/blog/inside-the-iphone-5s/

No lo sacan ahora, lo sacan supuestamente con el S5. Y el motivo es el que señala DaSound: los 4 gbs de RAM.
Personalmente no le veo sentido a darle más vueltas al asunto...

En Android es probable que el objetivo de los 64 bits sea aumentar la RAM, en iOS lo dudo, más bien será mejorar la eficiencia del sistema, algo que por desgracia en Android parece que no se sabe lo que significa. El compañero DaSound lo ha expuesto muy bien en el anterior post.

[frkhtcmania]

Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.

iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo.

Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C.

Saludos.

otro problema añadido es que desde que Oracle se hizo con Java, el mundo java ya no es lo que era, Java debería quitarse de encima a Oracle....:risitas::risitas::risitas:

[groche97]

Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.

iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo.

Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C.

Saludos.

Yo también creo que c++ es una gran alternativa para escribir aplicaciones en android, pero asta ahora no a sido el momento, ya que los smartphones tenían poca memoria y eso java lo solucionaba, y todavía deveria seguir siendo asi en los móviles de gama baja y algunas aplicaciones más genéricas como whasap ya que estas las siguen usando móviles viejos. Eso si, las aplicaciones de sistema deverian estar escritas en su malloria en java para aprovechar mejor la RAM, añ igual que los juegos, el navegador o aplicaciones pesadas, pero la variedad siempre está bien.
Por cierto, ya se pueden compilar aplicaciones en c++ para android desde hace tiempo, asi que se deverian poner las pilas los desarrolladores de aplicaciones.
A y ios no usa un kernel Linux como as puesto arriba, sino que deriva de unix, el padre de Linux.

Por cierto, estos procesadores hoy en día son inútiles, haber si empieza a moverse esto de los 64 bits y en un par de años ya son algo útil en móviles.

[juanche007]

Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.

iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo.

Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C.

Saludos.

Android es como un ferrari llevado por un bebe de 1 año mientra ios y windows phone un panda llevado por fernando alonso. mientra siga java ese ferrari no tendra otro piloto.:grin:

[santinhos]

En Android es probable que el objetivo de los 64 bits sea aumentar la RAM, en iOS lo dudo
Yo sólo estoy hablando de Android/Samsung.

[DaSound]

Pues creo que te equivocas, parece que el A7 vuelve a estar fabricado por Samsung:

http://www.chipworks.com/en/technical-competitive-analysis/resources/blog/inside-the-iphone-5s/



En Android es probable que el objetivo de los 64 bits sea aumentar la RAM, en iOS lo dudo, más bien será mejorar la eficiencia del sistema, algo que por desgracia en Android parece que no se sabe lo que significa. El compañero DaSound lo ha expuesto muy bien en el anterior post.

Sí, es que no queda muy claro finalmente quién lo ha fabricado... he encontrado en muchos sitios referencias a ambos fabricantes. Desde el principio tenía claro que fue Samsung quien los fabricó, pero sí que encontré mucha info sobre que era TSMC quien los fabricaba... TSMC fabrica también para nVidia entre otras, así que no sería raro.

Pero creo que tienes razón... al final puede que haya sido Samsung.

[DaSound]

Yo también creo que c++ es una gran alternativa para escribir aplicaciones en android, pero asta ahora no a sido el momento, ya que los smartphones tenían poca memoria y eso java lo solucionaba, y todavía deveria seguir siendo asi en los móviles de gama baja y algunas aplicaciones más genéricas como whasap ya que estas las siguen usando móviles viejos. Eso si, las aplicaciones de sistema deverian estar escritas en su malloria en java para aprovechar mejor la RAM, añ igual que los juegos, el navegador o aplicaciones pesadas, pero la variedad siempre está bien.
Por cierto, ya se pueden compilar aplicaciones en c++ para android desde hace tiempo, asi que se deverian poner las pilas los desarrolladores de aplicaciones.
A y ios no usa un kernel Linux como as puesto arriba, sino que deriva de unix, el padre de Linux.

Por cierto, estos procesadores hoy en día son inútiles, haber si empieza a moverse esto de los 64 bits y en un par de años ya son algo útil en móviles.

Sí, sé que desde hace tiempo se pueden escribir en C++, pero esto tiene ventajas y virtudes, por ejemplo...
Ventajas:
- C++ te permite entrar hasta la cocina... con su código puedes acceder a cualquier parte del dispositivo.
- Es rápido como el viento... es una arquitectura sólida y rapidíiiiiiiiisima.
- Es nativo, comunica directamente con el kernel de Linux (escrito en c).

Desventajas:
- Es muy tedioso de programar, ya que no hay tanta API escrita para C++ sobre todo en el mundo smartphone.
- Controlar la gestión de memoria. Me ha tocado muchas veces, sobre todo cuando programaba en Visual C++, pero manejar los punteros es una p*t*d* como un templo... si hay que hacerlo se hace, pero nada como un gestor automático de memoria como el de .NET o Java.
- No es un lenguaje en alza... lo fue, pero la gente que lo maneja no está por la labor de meterse con dispositivos móviles... el pool de programadores es muy escaso.

[DaSound]

Android es como un ferrari llevado por un bebe de 1 año mientra ios y windows phone un panda llevado por fernando alonso. mientra siga java ese ferrari no tendra otro piloto.:grin:

Pues sí, podría decirse así... por eso hablo siempre de que se subestima a sistemas emergentes como Ubuntu Touch o Tizen... estos SOs tendrán un framework nativo respecto al kernel y se instalarán en smartphones con hardware Android... si le sacan el jugo esos sistemas volarán!!

[Birutas]

La de tonterías que hay que leer... los 64bits sirven, entre otras cosas, para poder direccionar 4Gb de RAM, que será lo que posiblemente traiga el S5 o el Note4... no es por otra cosa!!! mañana lo será, hoy es básicamente por eso!!

¿Quién ha dicho que sea para Android?... quizá los fabrican pensando en Tizen que puede ser que sí los aproveche, así como el multihilo... y los montan en los 2, para qué fabricar 2 distintos.


Mañana será Qualcomm quien los presente, y será el DIOS!! se celebrarán fiestas, se ofrecerán presentes, se esculpirán estatuas y compondrán canciones y sonetos. Y sino, al tiempo.

Con un procesador de 32 bits se pueden direccionar 4 gb de ram, ese es su tope.

No es necesario un procesador de 64 para manejar 4 gb de ram a menos que se quiera superar esa cantidad.

[gustavoacm]

Estos de Samsung que eficientes son: se han puesto a investigar el tema de los 64 bits justo después de la keynote de Apple y ya lo tiene casi hecho?
:D:D:D:D:D

Es que si se trata de copiar...

http://www.tecnogeek.com/verpost.php?id_noticia=2102

Esto de los 64 bits es algo evolutivo, siempre hay alguien que lanza primero algo y el hecho de que seas primero no te hará mejor ni peor... desgraciadamente muchos piensan que no es así.

Lo molesto es como se juega con la mente de las personas, sobre todo apple, que su manera de vender es siempre "somos los primeros y nos copian" y cuando alguien presenta algo similar se le ataca como perro rabioso. Y cierto, también se hace con apple, pero ellos fueron los que empezaron con este jueguito, son las consecuencias de esto... :silbando:

El copiar, o imitar, genera competitividad y opciones, y que el mercado progrese con el tiempo. Si prosperaran de más las estrategias comerciales nefastas de la manzanita, de demandar por cualquier estupidez e impedir "copias o imitaciones", el mercado estaría estancado, no habría la cantidad de opciones a elegir que hay, desde xiaomi hasta lg, sony o samsung, o el wp8 de ms.

Hay una delgada linea roja entre el copyright, defender la innovación y abusar de esto para querer monopolizar el mercado, y aunque muchos digan que no, lo que es apple tiende más a estar del segundo lado... por lo que se ha visto anteriormente.

Dicho sea de paso este tema de 64 bits no se trata de ser el primero, y menos cuando la empresa que hace el diseño para todos ya lo presentó el año pasado, sino de aprovechar bien las cosas, y no presentarlo como un alarde para estrategia de venta... porque prácticamente está siendo así.

Las consolas cambiaron la guerra de bits por la de los cores hace años... y es de las apps que mas demandan procesamiento... por algo será.

Lo que es seguro es que pronto será necesario cambiar a 64 bits, por los motivos expuestos... lo mismo que pasó en PC.

[andy_ferrari]

Tampoco veo un problema para android que use java, se pueden ir desarrollando nuevas aplicaciones sin java y así no usa dalvik

[Verni]

Wao, creo que el S5 si esto es cierto será más rápido que mi computadora jaja.

Espero que refinen lo del big little, con ese A53 los 4 procesadores menos potentes serán como 4 núcleos A9 jaja más potente que muchos gama media.

A ver que pasa

[DaSound]

Con un procesador de 32 bits se pueden direccionar 4 gb de ram, ese es su tope.

No es necesario un procesador de 64 para manejar 4 gb de ram a menos que se quiera superar esa cantidad.

Con un procesador de 32bits se pueden direccionar hasta 64gb de ram... como? Usando la dirección extendida de memoria. Para ello se tienen que cumplir 2 cosas
- que el procesador soporte la tecnologia de direccion ampliada, es decir, que tenga esas lineas extra
- que el kernel soporte PAE (Physical Address Extension) si hablamos de Linux y AWE (Address Windowing Extensions) si hablamos de windows.

Primeramente no es factible limitarse unicamente a kernels que sean compatibles con PAE... y segundo y mas importante, la compatibilidad con la direccion de memoria extendida ha de ser soportada físicamente por el procesador... contando con esas loneas extras. Actualmente solo los cortex A15 son compatibles, y no tiene porque serlo mas adelante. Si ARM es precisamente quien antepone la arquitectura de 64bits sobre la de 32 con extension PA... por algo será.

Meter PAE seria solo un parche momentáneo a una evolución obligatoria... porque complicarse la vida... se mete x64 y a correr.

[juanche007]

Por cierto mucho tiros a la línea de flotación de android, samsung saca sus sistema operativo, oppo acaba de sacar ColorOS de Oppo en su oppo one, etc... los fabricantes se esta cansando de android?

[Verni]

Por cierto mucho tiros a la línea de flotación de android, samsung saca sus sistema operativo, oppo acaba de sacar ColorOS de Oppo en su oppo one, etc... los fabricantes se esta cansando de android?


El caso de Samsung no creo que sea aburrimiento de Android, lo que pude leer es que ellos no quieren depender de Google, pero si ese Tizen no pega tendrán que volver a Android, aunque espero que pegue, sería una opción más, pero que sigan con Android también.

[zhealot]

asu se me aclararon varias dudas que tenia... gracias

[YoArnold83]

Puro marketing ahora mismo.

[Birutas]

Con un procesador de 32bits se pueden direccionar hasta 64gb de ram... como? Usando la dirección extendida de memoria. Para ello se tienen que cumplir 2 cosas
- que el procesador soporte la tecnologia de direccion ampliada, es decir, que tenga esas lineas extra
- que el kernel soporte PAE (Physical Address Extension) si hablamos de Linux y AWE (Address Windowing Extensions) si hablamos de windows.

Primeramente no es factible limitarse unicamente a kernels que sean compatibles con PAE... y segundo y mas importante, la compatibilidad con la direccion de memoria extendida ha de ser soportada físicamente por el procesador... contando con esas loneas extras. Actualmente solo los cortex A15 son compatibles, y no tiene porque serlo mas adelante. Si ARM es precisamente quien antepone la arquitectura de 64bits sobre la de 32 con extension PA... por algo será.

Meter PAE seria solo un parche momentáneo a una evolución obligatoria... porque complicarse la vida... se mete x64 y a correr.

Y que tendra que ver ahora las PAE y las AEW, segun tu Sansung va a implementar los 64 por ampliar la ram a 4 Gb actualmente para utilizar esos 4 gb de ram no es necesario una CPU de 64 bits.

[DaSound]

Y que tendra que ver ahora las PAE y las AEW, segun tu Sansung va a implementar los 64 por ampliar la ram a 4 Gb actualmente para utilizar esos 4 gb de ram no es necesario una CPU de 64 bits.

Te lo acabo de explicar más arriba, léelo.

Con 4Gb se direccionan 4Gb TEÓRICAS, no físicas ni prácticas, porque la RAM no es lo único que hay que direccionar... los recursos de la placa y otros componentes también ocupan direccionamiento, por lo que la dirección de la RAM se limita y no es capaz de direccionar las 4Gb si no se usa el direccionamiento extendido.

Aparte de esto, se pretende superar las 4Gb de RAM incluso en el mismo año... no vamos a esperar al límite para implementar la arquitectura.
Parece que no queda claro como funciona el tema de los procesadores... ARM desarrolla los esquemas de los procesadores, y las marcas lo adoptan para fabricar cada uno el suyo... si la siguiente generación con los ARM A57 y A53 son 64bits, todas las marcas que quieran fabricar sus procesadores con arquitectura ARM, tendrán que ser x64, es que nos creemos que las marcas hacen los procesadores así porque les da la gana!! pues no! así dan lugar las discusiones absurdas sobre si uno copia y el otro lo saca porque este lo saca... las arquitecturas las marca ARM, y cada uno lo scará a su ritmo.

Aparte de todo esto, va a ser un cambio forzoso... ARM va a fabricar los A50 con arquitectura de 64bits, así que todos los nuevos terminales montarán SoC 64bits... los programadores tendrán que empezar a pensar si desdoblan las aplicaciones o solo programan para 32bits... pero desde ya te digo que los buenos juegos empezarán a usar 64.

[MDLSoft]

Sí, sé que desde hace tiempo se pueden escribir en C++, pero esto tiene ventajas y virtudes, por ejemplo...
Ventajas:
- C++ te permite entrar hasta la cocina... con su código puedes acceder a cualquier parte del dispositivo.
- Es rápido como el viento... es una arquitectura sólida y rapidíiiiiiiiisima.
- Es nativo, comunica directamente con el kernel de Linux (escrito en c).

Desventajas:
- Es muy tedioso de programar, ya que no hay tanta API escrita para C++ sobre todo en el mundo smartphone.
- Controlar la gestión de memoria. Me ha tocado muchas veces, sobre todo cuando programaba en Visual C++, pero manejar los punteros es una p*t*d* como un templo... si hay que hacerlo se hace, pero nada como un gestor automático de memoria como el de .NET o Java.
- No es un lenguaje en alza... lo fue, pero la gente que lo maneja no está por la labor de meterse con dispositivos móviles... el pool de programadores es muy escaso.

Si a día de hoy parece que lo que prima en todas partes y en todos los segmentos de la sociedad es ir a lo fácil y rápido sin pensar en que es "pan para hoy y hambre para mañana".
Soy de los de la "vieja escuela" que ha programado casi todo en C y C++ pero que también he programado bastante en ASM y he visto la brutal diferencia de eficiencia que hay entre capas de software.
Entiendo que no se puede programar todo en ASM porque sería poco menos que inviable pero tampoco me parece bien el enorme despilfarro de recursos de que hay actualmente. Me da la sensación de que hoy día ya no se programa sino que se "diseña" software, todo a partir de "módulos prefabricados" que a la vez enlazan con otras capas modulares y al final para ir de A hasta B se dan un millón de vueltas y con un montón de problemas por el camino.

Desde mi punto de vista Java sobra y se tendría que ir a C++ no solo mirando el diseño y funcionalidad del software sino también la eficiencia del mismo dándole como mínimo la misma importancia que al diseño. Pero bueno, parece que a día de hoy es la mentalidad que hay, crecer y crecer, pero siempre ir a lo fácil no a la calidad. Que van lentas las aplicaciones.. pues a meter más máquina en vez de optimizar el software.

En fin, bienvenidos sean los 64bits, pero seguro que serían mejor recibidas las optimizaciones de software y aquí Apple creo que si da un gran ejemplo a seguir.

[DaSound]

Si a día de hoy parece que lo que prima en todas partes y en todos los segmentos de la sociedad es ir a lo fácil y rápido sin pensar en que es "pan para hoy y hambre para mañana".
Soy de los de la "vieja escuela" que ha programado casi todo en C y C++ pero que también he programado bastante en ASM y he visto la brutal diferencia de eficiencia que hay entre capas de software.
Entiendo que no se puede programar todo en ASM porque sería poco menos que inviable pero tampoco me parece bien el enorme despilfarro de recursos de que hay actualmente. Me da la sensación de que hoy día ya no se programa sino que se "diseña" software, todo a partir de "módulos prefabricados" que a la vez enlazan con otras capas modulares y al final para ir de A hasta B se dan un millón de vueltas y con un montón de problemas por el camino.

Desde mi punto de vista Java sobra y se tendría que ir a C++ no solo mirando el diseño y funcionalidad del software sino también la eficiencia del mismo dándole como mínimo la misma importancia que al diseño. Pero bueno, parece que a día de hoy es la mentalidad que hay, crecer y crecer, pero siempre ir a lo fácil no a la calidad. Que van lentas las aplicaciones.. pues a meter más máquina en vez de optimizar el software.

En fin, bienvenidos sean los 64bits, pero seguro que serían mejor recibidas las optimizaciones de software y aquí Apple creo que si da un gran ejemplo a seguir.

Cuan de acuerdo estoy contigo...a eso me refiero, metemos capas y más capas, es algo que me molesta muchísimo. Veo herramientas de desarrollo que se basa en conectar módulos únicamente, las llama "arquitecturas"... "mierdaquecturas" las llamo yo. Y luego encima aquel que pare una aplicación con esta basura de herramientas, se hace llamar "programador".... seguro que sabes lo que llega a molestar!!

Efectivamente, o incluso me atrevería a decir que en C#/VB.NET tal y como propone la gente de Xamarin, que es un lenguaje que sería nativo para el kernel y es de última generación igual que Java... bueno, realmente mucho mejor porque es rápido como él solo.

Capas, capas y más capas... más código autogenerado que no genera nada más que paja y mierda que no vale para nada... es peor que la crisis del software!!

En ese aspecto, tal y como cuentas iOS, Windows Phone y próximamente Ubuntu Touch, Jolla y Tizen le lleva la delantera a Android en ese aspecto tan inmensamente importante. Y ya no hablemos como otros sistemas como los anteriormente citados implementen multihilo... entonces ya apaga y vámonos.

[sanmi69]

Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.

iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo.

Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C.

Saludos.

Que pesaos con que es problema de java....

A que no sabes que las aplicaciones mas pesadas y serias web corren en servidores de aplicaciones JEE?

[sanmi69]

Cuan de acuerdo estoy contigo...a eso me refiero, metemos capas y más capas, es algo que me molesta muchísimo. Veo herramientas de desarrollo que se basa en conectar módulos únicamente, las llama "arquitecturas"... "mierdaquecturas" las llamo yo. Y luego encima aquel que pare una aplicación con esta basura de herramientas, se hace llamar "programador".... seguro que sabes lo que llega a molestar!!

Efectivamente, o incluso me atrevería a decir que en C#/VB.NET tal y como propone la gente de Xamarin, que es un lenguaje que sería nativo para el kernel y es de última generación igual que Java... bueno, realmente mucho mejor porque es rápido como él solo.

Capas, capas y más capas... más código autogenerado que no genera nada más que paja y mierda que no vale para nada... es peor que la crisis del software!!

En ese aspecto, tal y como cuentas iOS, Windows Phone y próximamente Ubuntu Touch, Jolla y Tizen le lleva la delantera a Android en ese aspecto tan inmensamente importante. Y ya no hablemos como otros sistemas como los anteriormente citados implementen multihilo... entonces ya apaga y vámonos.

Ingeniería del software se llama. No tiene sentido desarrollar aplicaciones en bajo nivel. Por que luego mantiene la aplicación su padre. A día de hoy las maquinas son lo suficientemente potentes para realizar la arquitectura de aplicaciones en capas, SOA, etc.


Que queda chachiguay decir que mejor hacerlo en ensamblador no? Así ganas el aplauso de los gafapasta.

[sanmi69]

Cuan de acuerdo estoy contigo...a eso me refiero, metemos capas y más capas, es algo que me molesta muchísimo. Veo herramientas de desarrollo que se basa en conectar módulos únicamente, las llama "arquitecturas"... "mierdaquecturas" las llamo yo. Y luego encima aquel que pare una aplicación con esta basura de herramientas, se hace llamar "programador".... seguro que sabes lo que llega a molestar!!

Efectivamente, o incluso me atrevería a decir que en C#/VB.NET tal y como propone la gente de Xamarin, que es un lenguaje que sería nativo para el kernel y es de última generación igual que Java... bueno, realmente mucho mejor porque es rápido como él solo.

Capas, capas y más capas... más código autogenerado que no genera nada más que paja y mierda que no vale para nada... es peor que la crisis del software!!

En ese aspecto, tal y como cuentas iOS, Windows Phone y próximamente Ubuntu Touch, Jolla y Tizen le lleva la delantera a Android en ese aspecto tan inmensamente importante. Y ya no hablemos como otros sistemas como los anteriormente citados implementen multihilo... entonces ya apaga y vámonos.

Y no se te ocurre pensar que es así por algo?

Tu te ganas la vida desarrollando? No me quiero imaginar el codigo spaguetti que saldrá de tu teclado si no separas tan siquiera en capas tu aplicación.

[DaSound]

Y no se te ocurre pensar que es así por algo?

Tu te ganas la vida desarrollando? No me quiero imaginar el codigo spaguetti que saldrá de tu teclado si no separas tan siquiera en capas tu aplicación.

Pero que dices. Antes de decir tal cosa mas vale que hablases con un minimo conocimiento. Claro que me gano la vida desarrollando pero veo que tu no. A capas no nos referimos a las capas de una metrica 3 por ejemplo en presentación, negocio y datos... si no a las plataformas intermedias que se asientan una sobre otra y sobre otra y que ralentiza todo.

En fin...

[DaSound]

Ingeniería del software se llama. No tiene sentido desarrollar aplicaciones en bajo nivel. Por que luego mantiene la aplicación su padre. A día de hoy las maquinas son lo suficientemente potentes para realizar la arquitectura de aplicaciones en capas, SOA, etc.


Que queda chachiguay decir que mejor hacerlo en ensamblador no? Así ganas el aplauso de los gafapasta.

C#, VB.NET y C++ son lenguajes de bajo nivel? Muy bien chaval, van dos perlas de las buenas. Encima vienes atacando sin tener la menor idea de lo que dices.

Que crack.

[santinhos]

C#, VB.NET y C++ son lenguajes de bajo nivel? Muy bien chaval, van dos perlas de las buenas. Encima vienes atacando sin tener la menor idea de lo que dices.

Que crack.
Este pollo «promete»... será mejor que no le entres al trapo...

[sanmi69]

Vamos, que vosotros sabéis mas que los arquitectos de google ;)
Y si, me dedico al desarrollo, arquitecto/analista orgánico jee. Pero vosotros a lo vuestro, java es una mierda y tal...

[santinhos]

Vamos, que vosotros sabéis mas que los arquitectos de google ;)
Y si, me dedico al desarrollo, arquitecto/analista orgánico jee. Pero vosotros a lo vuestro, java es una mierda y tal...
Al respeto no te dedicas, eso seguro. Un saludo.

[sanmi69]

Al respeto no te dedicas, eso seguro. Un saludo.

No, no me pagan por ello.

Es que uno acaba harto de escuchar que java es una mierda. Y que android va mal por culpa de java.

Java en android con java 'standar' solo se parece en el lenguaje de programación. Internamente son diferentes, por lo que google perfectamente pudo eliminar laldependencia de la maquina virtual y no lo hizo creando otra maquina virtual diferente. Además desde 2.3 existe jit por lo que la supuesta latencia de la dalvik es inexistente.

A los que tanto alardean de .NET, acaso no se ejecuta en una maquina virtual? Además .NET es unancopia descarada (con mejoras) respecto a j2ee 1.3.

Al igual que en java 5 y posteriores se mejoro cogiendo las ideas buenas que tuvieron las de microsoft al implementar su .NET.

Además hacer la comparación de android con los no tiene sentido desde el momento en el que ios tiene un hardware cerrado.


Y sobre el tema de capas, frameworks, etc que hacen enlatecer el sistema, hoy día es mucho mas barato el hardware que las horas de trabajo de cualquier desarrollador, por lo que evidentemente se prima el crear un sistema modulable fácil de mantener en lugar de hacer virguerias para ahorrar un milisegundo de microprocesador.

Esto no quita para que se hagan malos programas y que vaya lento, pero al menos algo malo que este bien modularizado sera mas fácil de arreglar que un churro que no lo entiende ni el pueblo hizo 2 semanas después.

[DaSound]

Vamos, que vosotros sabéis mas que los arquitectos de google ;)
Y si, me dedico al desarrollo, arquitecto/analista orgánico jee. Pero vosotros a lo vuestro, java es una mierda y tal...

Ay que me LOL... pues para "desempeñar" ese cargo tienes los conceptos muy ligeritos y poco claros.

No, no me pagan por ello.
Pues te podrían dar un pequeño extra para que lo adoptaras... es esencial para el trabajo en el mundo del desarrollo.

Es que uno acaba harto de escuchar que java es una mierda. Y que android va mal por culpa de java.
Y a mí me hartan los sinsentidos y tengo que verlos a diario, pero es lo que hay. Ahora vas y todo esto que nos vas a contar, se lo cuentas a esta gente: Xamarin (www.xamarin.com) Y cuando la carcajada sea colectiva, vas y te miras el rendimiento de Android con un lenguaje nativo funcionando contra el Kernel sin meter de por medio la Java y su máquina virtual XobotOS (http://blog.xamarin.com/android-in-c-sharp/).

Java en android con java 'standar' solo se parece en el lenguaje de programación. Internamente son diferentes, por lo que google perfectamente pudo eliminar laldependencia de la maquina virtual y no lo hizo creando otra maquina virtual diferente. Además desde 2.3 existe jit por lo que la supuesta latencia de la dalvik es inexistente.
A lo anterior me remito... de inexistente nada de nada.

A los que tanto alardean de .NET, acaso no se ejecuta en una maquina virtual? Además .NET es unancopia descarada (con mejoras) respecto a j2ee 1.3.
No, nada que ver tiene lo que usa .NET (CLR o Common Language Runtime) con una máquina virtual... .NET permite el acceso al hardware con una simple compilación en JIT.
Y nadie lo esconde... la propia Microsoft afirma que .NET es Java pero bien implementado e ideado y con un entorno de desarrollo (Visual Studio y herramientas colindantes) que Java ni soñaría comparado con Eclipse, NEtbeans y sus derivados.


Al igual que en java 5 y posteriores se mejoro cogiendo las ideas buenas que tuvieron las de microsoft al implementar su .NET.
Aquí estoy de acuerdo, sencillamente hicieron lo que los señores de Java no supieron hacer.

Además hacer la comparación de android con los no tiene sentido desde el momento en el que ios tiene un hardware cerrado.
Tiene sentido en que el hardware sigue la misma arquitectura y sus SO tienen bases similares (Linux y Darwin BSD o UNIX)[/QUOTE]



Y sobre el tema de capas, frameworks, etc que hacen enlatecer el sistema, hoy día es mucho mas barato el hardware que las horas de trabajo de cualquier desarrollador, por lo que evidentemente se prima el crear un sistema modulable fácil de mantener en lugar de hacer virguerias para ahorrar un milisegundo de microprocesador.

Y dale la burra al trigo con la modularidad y el mantenimiento... que aquí nadie ha hablado de eso, que la modularidad de las aplicaciones es el párbulo de la programación, nadie está hablando de capas en cuanto a la división del código por actividades para mejorar el mantenimiento (una pequeña parte de lo que sería la Ingeniería del Software que casi nadie hace y luego se arrepienten.
Y así salen las aplicaciones... precisamente tengo que padecer el trabajar con Java y una de esas maravillosas arquitecturas ideadas para """ahorrar""" tiempo de programación y hacer el mantenimiento """más fácil"""... Esa idea maravillosa de 4 lumbreras de crear herramientas que generan el código para poder poner en la silla a personal semicualificado de muy baja experiencia por 600€ al mes.
La ironía del tema es que, al final, el mantenimiento de estas arquitecturas requieren el doble de conocimiento en lugar de exigir la mitad, que era su cometido, pues los errores propios de la arquitectura y su conocimiento interno requieren personal más cualificado que lo que se pretendía en un primer momento.
Lentas como ellas solas, generadoras de basura en lugar de "gastarse" ese dinero en verdaderos profesionales y una buena gestión por parte de capas más altas en el estrato jerárquico del proyecto.


Esto no quita para que se hagan malos programas y que vaya lento, pero al menos algo malo que este bien modularizado sera mas fácil de arreglar que un churro que no lo entiende ni el pueblo hizo 2 semanas después.

Claro que no lo quita... lo provoca, pero oye... aunque sea una mierda, que al menos sea modular.

Vovlemos a lo mismo, nadie habla de módulos ni de mantenimientos, eso va implícito y no tiene nada que ver con la arquitectura que se quiera implementar.

[sanmi69]

Ay que me LOL... pues para "desempeñar" ese cargo tienes los conceptos muy ligeritos y poco claros.


Pues te podrían dar un pequeño extra para que lo adoptaras... es esencial para el trabajo en el mundo del desarrollo.


Y a mí me hartan los sinsentidos y tengo que verlos a diario, pero es lo que hay. Ahora vas y todo esto que nos vas a contar, se lo cuentas a esta gente: Xamarin (www.xamarin.com) Y cuando la carcajada sea colectiva, vas y te miras el rendimiento de Android con un lenguaje nativo funcionando contra el Kernel sin meter de por medio la Java y su máquina virtual XobotOS (http://blog.xamarin.com/android-in-c-sharp/).


A lo anterior me remito... de inexistente nada de nada.


No, nada que ver tiene lo que usa .NET (CLR o Common Language Runtime) con una máquina virtual... .NET permite el acceso al hardware con una simple compilación en JIT.
Y nadie lo esconde... la propia Microsoft afirma que .NET es Java pero bien implementado e ideado y con un entorno de desarrollo (Visual Studio y herramientas colindantes) que Java ni soñaría comparado con Eclipse, NEtbeans y sus derivados.


Aquí estoy de acuerdo, sencillamente hicieron lo que los señores de Java no supieron hacer.


Tiene sentido en que el hardware sigue la misma arquitectura y sus SO tienen bases similares (Linux y Darwin BSD o UNIX)




Y dale la burra al trigo con la modularidad y el mantenimiento... que aquí nadie ha hablado de eso, que la modularidad de las aplicaciones es el párbulo de la programación, nadie está hablando de capas en cuanto a la división del código por actividades para mejorar el mantenimiento (una pequeña parte de lo que sería la Ingeniería del Software que casi nadie hace y luego se arrepienten.
Y así salen las aplicaciones... precisamente tengo que padecer el trabajar con Java y una de esas maravillosas arquitecturas ideadas para """ahorrar""" tiempo de programación y hacer el mantenimiento """más fácil"""... Esa idea maravillosa de 4 lumbreras de crear herramientas que generan el código para poder poner en la silla a personal semicualificado de muy baja experiencia por 600€ al mes.
La ironía del tema es que, al final, el mantenimiento de estas arquitecturas requieren el doble de conocimiento en lugar de exigir la mitad, que era su cometido, pues los errores propios de la arquitectura y su conocimiento interno requieren personal más cualificado que lo que se pretendía en un primer momento.
Lentas como ellas solas, generadoras de basura en lugar de "gastarse" ese dinero en verdaderos profesionales y una buena gestión por parte de capas más altas en el estrato jerárquico del proyecto.



Claro que no lo quita... lo provoca, pero oye... aunque sea una mierda, que al menos sea modular.

Vovlemos a lo mismo, nadie habla de módulos ni de mantenimientos, eso va implícito y no tiene nada que ver con la arquitectura que se quiera implementar.

Que conceptos tengo poco claros?

Y de que hablas de código prefabricado? Por desgracia las churrerías de código existen en todos los lenguajes.

De que "arquitecturas" hablas tu que penalizan tanto y te quieres deshacer de ellas?


Hablas mucho y dices poco. Si la plataforma java fuera mala habría dejado de existir hace tiempo (y la realidad es que las aplicaciones grandes tienen ser en jee y no en .NET donde aparte estas atado por m$), y google no lo habría adoptado como lenguaje para su plataforma (java android y java de oracle/sun solo se parecen en la sintaxis,mismo lenguaje diferente plataforma)


Pero claro, un desarrollador como tu (y me apuesto el dedo meñique del pie a que ni eres ingeniero) sabe más que los gurus...

[DaSound]

Que conceptos tengo poco claros?

Llevamos todo el hilo de hablando de "capas" de arquitectura, o los generadores de code behind y erre que erre con la modularidad para el mantenimiento de una aplicación... si te parece poco.


Y de que hablas de código prefabricado? Por desgracia las churrerías de código existen en todos los lenguajes.
Hay varias tanto para Android como para iOS... me cuesta creer que nunca hayas oido hablar de ninguna de ellas, porque están muy presentes actualmente incluso en el mundo del desarrollo profesional... comunmente denominados "appbuilder" únicamente se trata de conectar módulos que aportan X funcionalidad a tu aplicación... eso obviamente genera código automáticamente por debajo.
Me sigue extrañando que si trabajas donde dices no hayas escuchado hablar nunca de BankSphere, WebSphere.... etc, etc... programando máquinas de estado para crear aplicaciones web que generan basura por debajo hasta límites insospechados.


De que "arquitecturas" hablas tu que penalizan tanto y te quieres deshacer de ellas?
Las citadas appbuilders a nivel de programación, y la máquina virtual Java a nivel de arquitectura.


Hablas mucho y dices poco. Si la plataforma java fuera mala habría dejado de existir hace tiempo (y la realidad es que las aplicaciones grandes tienen ser en jee y no en .NET donde aparte estas atado por m$), y google no lo habría adoptado como lenguaje para su plataforma (java android y java de oracle/sun solo se parecen en la sintaxis,mismo lenguaje diferente plataforma)

Solo hace falta entenderlo. Con Java, estás sujeto a Oracle, y no tengo que recordarte los juicios que ha tenido Google con Oracle por culpa Java después de comprar Sun Microsystems... la plataforma Java no desaparece porque apareció hace muchos años y se extendió como la pólvora... un lenguaje de alto nivel que funciona en casi cualquier cosa! para aquel entonces estaba bastante bien... se hizo con millones de desarrolladores que ahora son los que sostienen la continuidad de ese lenguaje a pesar de haber soluciones mejores. Pero ahora sinceramente se queda corta... ¿cuantos juegos y/o aplicaciones de peso hay programados en Java? Ya te puedes hartar de buscar.




Pero claro, un desarrollador como tu (y me apuesto el dedo meñique del pie a que ni eres ingeniero) sabe más que los gurus...

Issshhtttt casi aciertas... ingeniero y graduado con posgrado!! has andado cerquita... menos mal que no te has apostado el bulbo raquídeo :risitas: aunque tampoco...
No hace falta ser superdotado para ver que Google escogió Java porque al fin y al cabo para subir rápido y hacerse grande, lo que necesita son programadores... ¿dónde estaba el pool más extenso? en Java, pues allá que se fue, ni más ni menos.

[sanmi69]

Llevamos todo el hilo de hablando de "capas" de arquitectura, o los generadores de code behind y erre que erre con la modularidad para el mantenimiento de una aplicación... si te parece poco.


Hay varias tanto para Android como para iOS... me cuesta creer que nunca hayas oido hablar de ninguna de ellas, porque están muy presentes actualmente incluso en el mundo del desarrollo profesional... comunmente denominados "appbuilder" únicamente se trata de conectar módulos que aportan X funcionalidad a tu aplicación... eso obviamente genera código automáticamente por debajo.
Me sigue extrañando que si trabajas donde dices no hayas escuchado hablar nunca de BankSphere, WebSphere.... etc, etc... programando máquinas de estado para crear aplicaciones web que generan basura por debajo hasta límites insospechados.





Solo hace falta entenderlo. Con Java, estás sujeto a Oracle, y no tengo que recordarte los juicios que ha tenido Google con Oracle por culpa Java después de comprar Sun Microsystems... la plataforma Java no desaparece porque apareció hace muchos años y se extendió como la pólvora... un lenguaje de alto nivel que funciona en casi cualquier cosa! para aquel entonces estaba bastante bien... se hizo con millones de desarrolladores que ahora son los que sostienen la continuidad de ese lenguaje a pesar de haber soluciones mejores. Pero ahora sinceramente se queda corta... ¿cuantos juegos y/o aplicaciones de peso hay programados en Java? Ya te puedes hartar de buscar.





Issshhtttt casi aciertas... ingeniero y graduado con posgrado!! has andado cerquita... menos mal que no te has apostado el bulbo raquídeo :risitas: aunque tampoco...
No hace falta ser superdotado para ver que Google escogió Java porque al fin y al cabo para subir rápido y hacerse grande, lo que necesita son programadores... ¿dónde estaba el pool más extenso? en Java, pues allá que se fue, ni más ni menos.

A los generadores de código le llamas arquitectura? Yo fliplo. Quien tiene los conceptos mal en su cabeza de "hingeniero"?

Los generadores de código son simplemente eso. Generadores de código que "funciona". Aquí sobra la palabra arquitectura, porque entonces según tu incluso usar una librería seria una parte de la definición de la arquitectura de la aplicación. Te viene grande todo este tema...

En mi 10 años de trayectoria profesional en jee no hemos utilizado ningún generador de código. Si tu has estado en empresas poco serias con una calidad de producto nefasta, tu mismo te estas describiendo.

Sobre el tema de aplicaciones y juegos de peso, juegos evidentemente no (cada lenguaje para lo que esté especializado) pero en aplicaciones empresariales Java es el rey, te guste o no. Más del 80% de las aplicaciones empresariales de las administraciones públicas están en JEE. SAP por ejemplo, empezó a migrar a JEE. Pero según tu, las grandes aplicaciones no usan java, claro que no.

Pero claro, creo que hablas por aplicaciones de escritorio, ahí java no tiene prácticamente presencia, salvo en aplicaciones multiSO ya que java es independiente del SO gracias a la JVM que tanto odias.

Incluso en aparatos de pocos recursos, JME se llegó a usar mucho.

Y sobre los juicios google/oracle, que tiene que ver una cosa con otra? Sabes acaso la causa? Parece que no

Java y su especificación es libre, por lo que no se depende de oracle para nada.
En .net por ejemplo no se puede decir lo mismo

[DaSound]

A los generadores de código le llamas arquitectura? Yo fliplo. Quien tiene los conceptos mal en su cabeza de "hingeniero"?


Jajajajaj, madre mía, es enormemente aburrido tener que responderte una y otra vez y cada vez con pero memez. Los appbuilder generan código por debajo y ciertas arquitecturas como las que te dije antes también, a ver si aprendemos a sintetizar.


Los generadores de código son simplemente eso. Generadores de código que "funciona". Aquí sobra la palabra arquitectura, porque entonces según tu incluso usar una librería seria una parte de la definición de la arquitectura de la aplicación. Te viene grande todo este tema...

Claro, solo eso... solo eso es para tí porque primero no tienes la menor idea de lo que te estoy hablando y segundo que no has visto uno en tu vida, así que mejor no vamos a hablar de lo que le viene grande a cada uno porque me puedo reír bastante. Una librería es una librería y punto, como un átomo es parte de la materia, no tiene sentido ninguno lo que dices.


En mi 10 años de trayectoria profesional en jee no hemos utilizado ningún generador de código. Si tu has estado en empresas poco serias con una calidad de producto nefasta, tu mismo te estas describiendo.
Se me olvidaba que las "empresas" en las que tú has trabajado produce la totalidad del software que se genera en el mundo... siendo así te doy la razón. Pero quitando este detalle, he dicho que estoy completamente en contra de este tipo de herramientas, no que las haya utilizado, es OBVIO hasta para tí, haz un esfuerzo.
Las empresas "nefastas" a las que te refieres, ahora mismo precisamente se llaman Banco De España, y es un estándar, no hay más, es sí o sí independientemente de lo que la empresa quiera programar... y sí, se llama arquitectura, Encofrador de software.


Sobre el tema de aplicaciones y juegos de peso, juegos evidentemente no (cada lenguaje para lo que esté especializado) pero en aplicaciones empresariales Java es el rey, te guste o no. Más del 80% de las aplicaciones empresariales de las administraciones públicas están en JEE. SAP por ejemplo, empezó a migrar a JEE. Pero según tu, las grandes aplicaciones no usan java, claro que no.

Y así de bien van... y encima me hablas de la administración pública donde precisamente tengo bastante experiencia y te podría contar sobre quién toma las decisiones y con qué criterio seleccionan la tecnología que se usa en sus aplicaciones... es que me descojono cada vez un poco más.


Pero claro, creo que hablas por aplicaciones de escritorio, ahí java no tiene prácticamente presencia, salvo en aplicaciones multiSO ya que java es independiente del SO gracias a la JVM que tanto odias.
Ahí Java no tiene presencia porque no tiene potencia para hacer lo que aplicaciones pesadas de verdad hacen... sino verías como estaba ahí... pues es un poco lo que empieza a pasar ahora... mientras la cosa era liviana, todo genial y todos contentos... ahora que empieza a pesar un poco empieza a rascar cosa fina.


Incluso en aparatos de pocos recursos, JME se llegó a usar mucho.

Porque precisamente para eso se inventó, para aparatos de pocos recursos.


Y sobre los juicios google/oracle, que tiene que ver una cosa con otra? Sabes acaso la causa? Parece que no

Yo lo tengo muy claro porque he leído mucho del tema... a lo mejor tú puedes aportar más datos.


Java y su especificación es libre, por lo que no se depende de oracle para nada.
En .net por ejemplo no se puede decir lo mismo

Java es libre siempre que no tengas ánimo de lucro... igual que .NET. Y más ahora que Oracle está de por medio.

[Tony891]

Valla pelea de gallinas teneis montado aqui...continuar con el tema que trata el hilo y si tanto os gustais os pedis el whatsapp...:facepalm: