El titular es bastante descriptivo, y esa fue la idea que tuvo el equipo de Dropbox a la hora de desarrollar dos de sus aplicaciones para smartphones "menos usadas" (como Mailbox y carousel). La idea tiene su gran lógica, y es que cosas muy distintas son la parte interna de una app (sea cual sea su índole) y su interfaz, por esa razón vieron más productivo realizar en C++ la parte interna de la app, aunque tenga sus dificultades para ciertas cosas.
Comentarios
Esto es una no-noticia. C++ es lenguaje común y nativo tanto para Android como iOS.
Recurrir a C++ para reutilizar código en aplicaciones que se quieran crear para ambas plataformas en una solución obvia y directa.
#10 En aplicaciones para el consumidor el rendimiento siempre es relevante. No quiero tener que jubilar mi móvil el año que viene, por ejemplo.
"Para eso cualquier mierda picada en Ruby por chavales de startup te sobra y te basta"
Y así nos va...
#6 No debe de ser lo normal cuando Dropbox sólo lo usa para sus apps menos usadas (como dice el artículo) y cuando Google sigue empeñada en que se use Java (sin importarle la máquina traga-memoria en la que se ha convertido Android).
#11 En aplicaciones para el consumidor el rendimiento siempre es relevante.
Correcto, pero veo que no te quieres enterar, ye-ye, de a lo que me refiero. Te pongo un ejemplo:
- Aplicación smartphone/web/escritorio picada en Python-Qt (por ejemplo): el usuario clica los botones y se realizan acciones, navega menús, hace selecciones... conforme va clicando, se ejecutan tareas o acciones.
- Aplicación smartphone/web/escritorio picada en Qt "puro" C++: idem de idem. El usuario no, repito: no nota la diferencia en el uso respecto a si la aplicación se hubiera escrito en C++. Aunque esté corriendo en un Pentium 4 de 1 solo núcleo en vez de un pepino de 4 cores. No, no lo nota.
Conclusión cuando necesite escribir una aplicación de ese estilo: usaré el lenguaje que me permita a mí ser más eficiente y rápido programando, porque la máquina ya es lo suficientemente eficiente para moverlo (y sí, joder, lo es en el 99'9999% de los casos de apps comerciales).
No quiero tener que jubilar mi móvil el año que viene, por ejemplo.
Ya lo jubilabas al año antes, cuando los gloriosos Nokia y Ericsson y demás, que estaban programados en assembly o en C++. Ahora incluso los smartphones puedes estirarlos más años.
Y así nos va...
Pues eso, así les va a los grandes de internet: picaron la aplicación en dos tardes en Rails y la echaron a rodar y ya, cuando tuvieron millones de usuarios y, entonces sí, el rendimiento empezó a ser un problema, pues tenían presupuesto suficiente para desarrollarlo de forma más eficiente en otro lenguaje. Ejemplo claro: Twitter. Nada extraño en un mundo en el que hay que moverse rápido para ser el primero en hacer algo, no el primero en hacerlo perfectísimo al microsegundo mientras otros te comen la idea y se forran. Más aún cuando el hierro está tan jodidamente barato que alquilar unos cuantos servidores más cuando necesites más rendimiento no te supone más que unos pocos cientos de dólares extra al año.
#12 ¿No lo nota? ¿Y qué pasa cuando se llena la RAM? ¿O cuando tarda más en cargar?
Además, hay dos tipos de aplicaciones simples: las que se ejecutan puntualmente (donde sí que no importa el rendimiento demasiado) y las que se ejecutan todo el tiempo. En estas cada MB y cada ciclo es vital, si no conforme se van añadiendo aplicaciones el rendimiento se degrada.
"Ya lo jubilabas al año antes, cuando los gloriosos Nokia y Ericsson y demás, que estaban programados en assembly o en C++"
Mentira. Estuve con un Nokia 5800 hasta marzo. Con 128 MB de RAM era una castaña, sí, pero una castaña que me permitía tener más aplicaciones abiertas que mi actual Xperia SP y la patética gestión de memoria de Android.
"Pues eso, así les va a los grandes de internet"
Estás mezclando aplicaciones Web con aplicaciones de escritorio. Como digo en #4 son un mundo bien distinto: te sale más barato un servidor nuevo que un desarrollador extra. Pero cuando la aplicación no es para tu servidor sino para tus usuarios, aunque sean ellos los que cambian el teléfono, es un gasto añadido que no utilizarán en pagarte. Mira el beneficio de iOS y mira el de Android. ¿Tú crees que el típico usuario que tiene un teléfono que se arrastra va a pagar por aplicaciones que lo arrastran aún más?
#13 ¿Y qué pasa cuando se llena la RAM? ¿O cuando tarda más en cargar?
Puedes ir a ver las cifras de facturación de las empresas que han desarrollado el software para ver lo que pasa cuando se llena la RAM
Por otro lado, no es algo común que se llene la RAM o que tarde más en cargar una aplicación porque se haya escrito en Python o en Ruby que en C++. Si tu aplicación Python va como el ojete y encima hace que se cuelgue la máquina... algo malo estás haciendo. Y de programar mal no te salva ni C++ ni MIPS-assembly.
Que no copón, que para según qué cosas el beneficio que obtienes utilizando lenguajes dinámicos de muy alto nivel es mayor que el que obtendrías haciendo lo mismo en C. En dos tardes, un par de rubystas te hacen cualquier extensión o te reescriben buena parte de una app, cuando para hacer cualquier cosa en C o C++ (hablamos siempre de buenos programadores) tardarían días==dinero.
#14 Entonces explícame por cualquier aplicación que se precie está hecha en esos lenguajes. Hablas de aplicaciones chorra o de aplicaciones para servidores.
No me compares una app para ver el menú de un restaurante o para que te muestra citas de famosos con un cliente de correo electrónico (con su correspondiente servicio en segundo plano) o una aplicación de galería.
Además, todas esas plataformas que mencionas consumen más RAM de por sí, no hace falta que hagas las cosas mal.
#3 Claro, pero que yo sepa iOs no soporta Java (y Android no sé hasta qué punto), además de otras pegas que tiene.
En cuanto al lenguaje a elegir, todo depende de lo que quieras desarrollar. Los servidores por ejemplo son un mundo bien distinto (poco importa el rendimiento si los programadores cuestan más que los servidores, y poco importa la compatibilidad si es sólo para ti).
#4 Si desde luego, yo soy de los que apuesta "según para que app" por phonegap. Pero si dropbox por ahora han elegido C++ han acertado. Aunque como en todo esto nos falta información.
Noticia de alcance
Tiene su lógica, ya sea C++, java, etc aunque no soy el único que le ha llamado la atención esto. No deja de ser curioso.
#1 No entiendo qué lógica ves si comparas C++ con Java Para mí la clave es que han usado un código digamos, más "universal", para poder mantener una sola versión, a pesar del empeño de Google y Apple en que se usen sus respectivas plataformas y lenguajes.
C/C++ siguen vivos y siguen siendo muy útiles por mucho que muchos se empeñen en matarlos sepultándolos bajo una maraña de tecnologías "cool e innovadoras" que al final hacen lo mismo con menor durabilidad, menor compatibilidad (y ahí se va a la mierda la supuesta facilidad que ofrecen), y menor eficiencia.
Que, sí, que algunas herramientas son muy útiles, pero al final el desarrollo de la informática va por dos caminos: el de las aplicaciones pequeñas, incompatibles, y de corta vida, y el de toda la vida, que es justo el que se usa en aplicaciones grandes, y que encima aprovecha mejor los recursos.
Y así tenemos que un PC de 512MB de RAM, aun estando obsoleto, gracias a sus aplicaciones nativas sigue haciendo muchas más cosas que un móvil nuevo de 512MB, que a duras penas mueve los menús con soltura.
#2 Vaya me he vuelto a explicar mal de nuevo. Me refería a elegir un lenguaje para dar soporte a las 2 plataformas
y "Por cierto que quede claro prefiero mil veces Java que C++" aunque no usaría ninguno de los 2 jeje
En el mundo laboral están siendo demandado
#2 No mantienen una sola versión; mantienen una sola versión de determinadas partes.
#2 Ehhhh son arquitecturas diferentes... La próxima vez compara una moto con un coche y compáralos diciendo que uno solo puede llevar 1 persona y el otro 5.
#2 A ver, nadie se empeña en "matar" a nada. Pues claro que C y C++ siguen siendo lenguajes ampliamente usados... donde se requiren las características de esos lenguajes.
Donde el microsegundo deja de ser importante, es donde programar algo en C o C++, aunque posible, quizá no te conviene tanto por el simple hecho de que vas a tardar más tiempo (aunque seas Bjarne Stroustrup) en hacerlo en C++ que en hacerlo en Python o Ruby. Y si el rendimiento "deja de ser relevante", pues lógicamente te decantarás por un lenguaje de más alto nivel que te permita desarrollar de forma rápida. Y sí, me puedes decir "el rendimiento nunca deja de ser importante", pero tú me entiendes... no es lo mismo un software de trading en tiempo real o de control de maquinaria (casos en los que incluso podrías llegar a despreciar C/C++ en favor de ensamblador ) que un software de CV o cosas para las que no necesitas una respuesta al ciclo de reloj siguiente o si no morimos todos, que es la gran mayoría de software de consumo actual. Para eso cualquier mierda picada en Ruby por chavales de startup te sobra y te basta.
Hace poco tiempo tuve la oportunidad de estar con el equipo de desarrollo móvil de Spotify. La arquitectura que tienen montada es muy parecida a esto. Dividen a su equipo entre "core" developers y "feature" developers. Los core developers mantienen el codebase en C++ que se comparte en iOS y android. Se encarga principalmente de la capa de comunicaciones, encriptación, cacheado, etc... Los feature developers son luego los encargados de usar esas APIs en C++ y dibujar en pantalla.