¿Cuál es el mayor obstáculo para crear un lenguaje de programación unificado que permita que un programador aprenda una vez y luego pueda crear aplicaciones nativas para dispositivos Apple, Android, Microsoft y sistemas Linux? ¿Cuándo existirá, si alguna vez?

El problema con el desarrollo de aplicaciones multiplataforma no tiene nada que ver con los lenguajes de programación; Tiene más que ver con los marcos y bibliotecas de nivel de sistemas. Mac, Linux y Windows proporcionan API específicas para interactuar con el sistema operativo. Mac y Linux, ambos descendientes de Unix, admiten muchas ideas similares (por ejemplo, estándares POSIX y OpenGL). Pero también proporcionan sus propias bibliotecas únicas que permiten a un desarrollador aprovechar el sistema operativo, como las bibliotecas Core en Mac (todas las que comienzan con NS *). Windows es una bestia completamente diferente. La estructura del archivo es única y la API es muy única. Esa singularidad es lo que hace que portar aplicaciones de Windows a * nix sea una tarea más complicada que portar una aplicación de Mac a Linux.

En cuanto a un lenguaje de programación que permite crear aplicaciones nativas multiplataforma, C o C ++ son probablemente las más cercanas. Es ampliamente compatible con los compiladores en muchos sistemas diferentes. También se usa comúnmente para desarrollar SDK para iOS y Android y para crear juegos multiplataforma para Mac, Windows, Linux y consolas. Una cosa para recordar es que C ++ se usa para implementar la mayoría de los sistemas operativos e intérpretes de lenguaje modernos (como Java), por lo que cualquier cosa que pueda hacer en Python, Java, JavaScript o Ruby, hay una manera de hacerlo en C ++. Puede que no sea la forma más fácil, pero hay una manera. La ventaja de los lenguajes de nivel superior, como Python, es que podemos trabajar en un nivel de abstracción superior y evitar preocuparnos por los detalles específicos del sistema. Básicamente, ¡la abstracción nos hace la vida más fácil! 🙂

La siguiente pregunta ahora es, si los idiomas son capaces de hacer esto, ¿por qué hay una diferencia en las bibliotecas? ¿Por qué no simplemente construir una biblioteca de bajo nivel para servir a cada sistema operativo o especificar una API común y obligar a los sistemas operativos a cumplir con esos estándares? Para crear una aplicación nativa, debe interactuar con el sistema operativo. Esta API variada que existe, se debe en parte a las decisiones comerciales. Pero también se debe a la variabilidad en el hardware. La mayoría de los sistemas operativos están personalizados y optimizados para sus plataformas previstas. Aquí es donde entran en juego los intérpretes de lenguaje y las máquinas virtuales. La JVM, por ejemplo, proporciona un conjunto común de bibliotecas que permiten a un desarrollador crear una aplicación multiplataforma. ¡JVM maneja todas las idiosincrasias subyacentes del sistema operativo por nosotros! Es más fácil para un grupo de personas muy inteligentes construir una plataforma que maneje cosas específicas del sistema operativo para nosotros y para que podamos usarla, que tratar de luchar con los detalles de trabajar en Mac, Windows y Linux simultáneamente.

Gracias por el A2A!

Si las aplicaciones web son aceptables para usted, HTML, CSS y Javascript ya se ejecutan en todas las plataformas. Pero entiendo que está solicitando aplicaciones nativas .


Desafío administrativo
Dicho esto, ya que solicitas aplicaciones nativas; El obstáculo es que Apple, Google, Microsoft y la Fundación Linux son entidades diferentes con sus propias filosofías e intereses creados. Apple, por ejemplo, tiene XCode que no se puede usar en ningún otro sistema operativo que no sea OS X y tienen la intención de mantenerlo así.

Desafío técnico
Todos ellos utilizan diferentes ecosistemas de hardware y software. Aunque si se hace un esfuerzo, se pueden poner bajo el mismo compilador y un solo idioma. Sin embargo, hay inversiones sustanciales en forma de código base que deben desecharse o modificarse para cumplir con este nuevo estándar.

Incluso si todo esto se resuelve de alguna manera. Como Drew ha dicho antes, habrá un nuevo proveedor (quizás Samsung) que creará un nuevo ecosistema.

Es muy inherente a la naturaleza de los seres humanos tratar de distinguirse. Las empresas no son la excepción.

El libre mercado.

Cuando una compañía de software está buscando un desarrollador, muchos de los mejores desarrolladores pueden aprender los rudimentos de un nuevo idioma en unas pocas semanas. Tendrían más problemas con las bibliotecas, pero en cualquier proyecto nuevo es probable que un desarrollador también necesite nuevas bibliotecas en su idioma actual.

Mientras tanto, los vendedores de herramientas para estos lenguajes están tratando furiosamente de agregar aplicaciones brillantes y geniales para atraer a nuevos desarrolladores y proyectos a su redil. Por supuesto, los desarrolladores han visto todos los problemas con su plataforma actual, por lo que el césped también es más ecológico en otro lugar.

A muchos desarrolladores también les gusta el desafío o el cambio de perspectiva al aprender un nuevo idioma. Si se le da a elegir entre aprender un nuevo idioma cada año y estar atrapado en el mismo idioma durante toda su vida, creo que la mayoría de los desarrolladores preferirían el primero.

Por supuesto, tales lenguajes sí existen, pero el problema es que están incompletos y apuntan solo a una parte de la pila de software y existen pequeñas diferencias en los intérpretes. HTML y CSS funcionan en todas las plataformas y están destinados a una versión declarativa de la lógica de presentación, y SQL existe en todas las plataformas y está destinado a una versión declarativa de acceso a datos.

Existe sobre todo. El código C ++ puede diseñarse para ejecutarse en cualquiera de las plataformas mencionadas, y el código Java puede ejecutarse en cualquiera de ellas, excepto iOS.

Si está escribiendo una aplicación GUI, deberá llamar a diferentes funciones en cada plataforma para dibujar botones, responder a eventos del sistema operativo, etc. Mientras esté escribiendo en C ++, probablemente debería estar usando Qt para esto; le permitirá usar un código similar en todas las plataformas, y las llamadas Qt se convertirán en llamadas específicas del sistema operativo en cada plataforma. Entonces, siempre que haya aprendido Qt, puede usarlo para tratar los detalles de cada plataforma. No estoy seguro de qué equivalentes tiene Java, aunque sé que tiene algún soporte para este tipo de cosas.

Si está haciendo gráficos, debe seguir con OpenGL (probablemente incrustado dentro de Qt). Parece que Qt también puede manejar audio en estos días.

Realmente, el mayor problema es que las aplicaciones genéricas tienden a ser mediocres en todo. Cada plataforma tiene fortalezas y limitaciones específicas. Los teléfonos necesitan botones más grandes porque los presionas con los dedos. Las PC de escritorio no tienen acelerómetros. La resolución es diferente en cada dispositivo. A veces tienes un joystick, a veces tienes un mouse, a veces tienes un trackball. El rendimiento de la CPU, la disponibilidad de memoria, la calidad de los gráficos y el soporte de audio pueden ser muy diferentes. Si solo está utilizando el subconjunto de características comunes a todas las plataformas, probablemente esté escribiendo una aplicación bastante pobre.

Para crear una buena experiencia de usuario, debe adaptar su aplicación a cada plataforma. Puede hacer esto en C ++, generalmente con opciones de configuración y bloques #ifdef; en la práctica, así es como se escriben la mayoría de las aplicaciones multiplataforma. La lógica de back-end a menudo puede usar el mismo código en todas las plataformas, pero la interfaz de usuario es muy diferente.

La única forma en que algo como esto existiría es si una sola entidad informática de extremo a extremo (aplicaciones de usuario hasta el metal y todo lo demás) proporcionara muchas de sus investigaciones, planes, etc. en lo que respecta al software y hardware como información de código abierto, pero retuvo información sobre procesos de desarrollo y cosas de esa naturaleza para asegurarse de poder trabajar más rápido que otras entidades competidoras.

Si esto sucediera y la compañía pudiera mantenerse a flote el tiempo suficiente para introducir sus componentes en las PC y tal, y tuviéramos un hardware de código abierto en el que se basaran muchas de nuestras computadoras, podríamos comenzar a considerar la posibilidad de que nuestro software pudiera estar abierto fuente casi completamente de código abierto y, por lo tanto, permita este tipo de lenguaje unificado que está describiendo.

Sin embargo, para garantizar que la compañía pueda competir con otras compañías manteniendo el secreto de sus procesos y realizando suficientes ventas de su hardware para mantenerse en el negocio, requeriría que la inteligencia promedio de sus empleados sea mucho mayor que la de sus competidores, lo que no es probable Entonces, lo siento, pero no creo que esto suceda en un futuro cercano si alguna vez.

Hasta donde yo sé, hay dos métodos de esto por ahora.

El primero es HTML5 + PhoneGap, que no es realmente nativo. PhoneGap puede ayudar a HTML5 a obtener más acceso al sistema.

El segundo es C #. Con proyecto mono, son compatibles con Linux y Mac. y luego está Xamarin, que te ayuda a construir C # para iOS y Android, de forma nativa.

Sin embargo, Xamarin es costoso para algunos desarrolladores independientes.
Hubo algunas noticias sobre la asociación de Microsoft con Xamarin y la posibilidad de comprarlas.

¿Quizás tengan planes futuros para llevar sus aplicaciones universales (que actualmente son universales entre Windows y Windows Phone, y pronto Xbox también) a otras plataformas también?

Como se mencionó, ya hay formas de usar un solo lenguaje de programación en la mayoría o todas las plataformas enumeradas anteriormente, ya sea que el lenguaje sea compatible directamente con una plataforma o indirectamente a través de una herramienta de terceros (como Xamarin o RhoMobile). Pero eso solo le permite usar el mismo lenguaje, no lo excusa de la necesidad de incluir código específico de la plataforma. Y aunque no lo pediste directamente, casi parece que eso es lo que estás buscando.

Si ese es el caso, el mayor obstáculo para que un lenguaje tan unificado controle todos los sistemas en su lista con el mismo código es una capa de abstracción de software común que admite todos los sistemas operativos y las variaciones de hardware de los sistemas en su lista.

HTML5 / CSS / JavaScript, junto con Cordova (también conocido como PhoneGap), se está acercando a ser ese lenguaje universal (o conjunto de idiomas), proporcionando una API común a un número creciente de dispositivos y bibliotecas de abstracción asociadas que se ejecutan en la mayoría de las plataformas en la lista y más … el mismo código puede usar una cámara Android o una cámara iOS, por ejemplo. El rendimiento está mejorando, tanto en términos de optimización de código como de la Ley de Moore que se manifiesta como núcleos de 2 + GHz en los teléfonos.

Qt es un gran marco que proporciona no solo un poco de GUI y soporte de dispositivos, sino también abstracciones para cosas como IPC, asignación de memoria, semáforos, subprocesos, etc. Se ejecuta en muchos sistemas operativos y, combinado con C o C ++, obtienes tu lenguaje unificado que admite muchas plataformas. Dicho todo esto, ha existido durante años y se ha usado “mucho” (supongo que principalmente en dispositivos integrados), pero no es exactamente un nombre familiar entre los desarrolladores de software.

En todos estos casos, aún necesitará compilar para cada dispositivo. Y hoy, todavía necesitará un código específico del dispositivo, particularmente para problemas de representación HTML5 / CSS / JavaScript en diferentes motores de navegador. Pero aún así, si entiendo tu pregunta, creo que está llegando allí.


Fuente: xkcd: Estándares

Esta pregunta es buena Apple tiene Xcode tratando de unificar todo (escritorio, móvil). MS tiene Visual Studio y Linux tiene varios tipos de herramientas de desarrollo de código abierto. Se ven diferentes y de hecho son algo diferente. Pero comparten la misma esencia: habilidades de lenguaje de programación. Como programador, puedes aprender una vez y adaptarte a diferentes plataformas con relativa facilidad. Eso es lo que llamo APRENDER UNA VEZ. Sin embargo, no es una verdadera “APRENDER UNA VEZ”.
La arquitectura de hardware / sistemas operativos son diferentes bajo diferentes ecosistemas de plataforma. Es posible un lenguaje de programación unificado (C o C ++) pero un entorno de desarrollo unificado es imposible debido a la diferencia. El ajuste del rendimiento o el soporte de ciertas funcionalidades como un sistema de tiempo de ejecución debe ser proporcionado por cada entorno de programación / ejecución para cada plataforma. Lo hacen por rendimiento seguro. Un contraejemplo es Java, es un entorno de programación y ejecución independiente de la plataforma que es criticado por su rendimiento.
Desde una perspectiva más profunda, lo que los desarrolladores de aplicaciones pueden hacer está bastante limitado por lo que los sistemas / hardware de bajo nivel pueden proporcionarle. La capacidad de su aplicación no puede ir más allá del soporte del sistema. En otras palabras, debe aprender cada API; de lo contrario, debe aprender el hardware / sistema que resulta ser más APRENDIZAJES.

Gracias por el A2A. Hay varios problemas aqui. Para las aplicaciones nativas, debe poder crear una aplicación que se ejecute directamente en el hardware. Hoy en día, en muchos casos, tiene una máquina virtual para simular un tipo de hardware sobre la plataforma real. Esto es lo que permite Write Once Run Anywhere o WORA que Java hizo famoso.

Claro, puede resolver muchos de estos tipos de problemas mediante el uso de capas sucesivas de abstracción. Cuanto mayor sea la capa de abstracción, más desconectado estará del hardware subyacente y más común será su interfaz de programación.

Tiendo a pensarlo así: en la evolución puedes tener dos tipos de animales: un pez que se adapta perfectamente al agua y no puede vivir en ningún otro lugar (ignora los patrones de barro por el momento), y un anfibio como una rana que puede vive tanto en tierra como en agua, pero no está perfectamente adaptado a ninguno de los dos. Renuncia a algo, por lo que no es exactamente tan bueno como un animal terrestre en tierra, y algo más, que no es tan bueno como un pez en el agua. Puede tener una adaptación perfecta (especificidad) para apuntar a su entorno de hardware particular, o tener la máxima flexibilidad (abstracción) para hacer que su lenguaje sea más fácil de usar en todas (o muchas) máquinas.

¿Cuándo surgirá un único estándar? Como alguien que trabajó en estándares en el IETF, ETSI, ITU, etc., puedo decirle que es extremadamente difícil lograr que los intereses creados de la industria pasen de sus posiciones a un terreno común. Estas batallas ocurren y se ganan o se pierden a medida que los jugadores cambian de bando: Sony Betamax y, más recientemente, Blu-Ray vs. HD DVD son algunos buenos ejemplos de cuán duramente se libran estas batallas y cómo a veces tardan mucho en resolverse.

La necesidad de crear aplicaciones multiplataforma ya se ha resuelto con la ayuda de diferentes marcos como los otros mencionados. Ahora no existe un lenguaje que implemente todas las funciones avanzadas de Windows, Linux y MAC. Porque tienen un sistema de archivos diferente, gestión de memoria y arquitectura.
Ahora, la belleza de los marcos es que cada uno de ellos ha seleccionado un lenguaje existente único y desarrollado algunas funciones y clases integradas para manipular la plataforma del sistema operativo.
El mayor desafío de crear un lenguaje de programación para gobernar todas las plataformas es hacer que todos los proveedores de sistemas operativos estén de acuerdo en cierta característica que es casi imposible. Así que supongo que la respuesta es “no”. No es posible desarrollar un lenguaje que rija las tres plataformas del sistema operativo.

Tal lenguaje realmente existe, puede ser C o C ++.
El problema es que para crear una aplicación moderna, deberá vincularla a varias bibliotecas / API / kits de herramientas / etc. Y esos son muy dependientes del sistema operativo.

Java, por otro lado, trató de resolver esto con una abstracción a través de su máquina virtual Java.

Escogiendo un ejemplo específico, recientemente necesité crear un dispositivo de bloque de arranque en Linux, y aprendí todo sobre la creación de un archivo disperso, tamaños de bloque, montaje de particiones, tipos de registros de arranque, instalación de un cargador de arranque, etc. La mayoría de los pasos para ese proceso son específicos de Linux En OS X, no es difícil descubrir los comandos equivalentes, pero son diferentes. Entonces, si estoy desarrollando una aplicación de administración de dispositivos de bloque y la voy a implementar en un servidor Linux, podría escribirla para que funcione en OS X para el desarrollo y las pruebas, pero eso podría no tener mucho sentido para un caso de uso de un disparo.

Si la administración de dispositivos de bloque fuera una necesidad bastante común, probablemente lo vería como una función de biblioteca estándar en más idiomas. En Ruby, es bastante normal que un desarrollador lea y escriba en archivos, y la biblioteca `File` les brinda una abstracción para hacer precisamente eso. `File` se implementa para cualquier sistema operativo y plataforma que admita Ruby. No ha habido tanta demanda para crear una biblioteca `BlockDevice`, por lo que simplemente no se ha implementado todavía.

El mayor obstáculo en mi opinión es el hecho de que cada idioma tiene ciertas fortalezas para las cuales surgió. Al poner todo en un idioma, tendrá un lenguaje de programación que es muy difícil de entender y aprender. Es similar a que se te pida que aprendas todos los idiomas que hablan en el mundo, al poner todos estos idiomas en un libro de texto.

Para la programación de nivel inferior, hay C que puede usar fácilmente para crear bibliotecas multiplataforma que se compilan en .dll (Windows), .so (Linux) y .dylib (Mac).

Sin embargo, no se detiene en el nivel inferior, ahora hay una industria emergente de compiladores GUI multiplataforma que ha experimentado un aumento significativo en la actividad en los últimos años.

Compré una licencia para Xojo Professional el año pasado, hasta ahora solo la he usado para jugar en mi tiempo libre, pero se ejecuta en los sistemas de escritorio Windows, Linux y Mac GUI y puede compilarlos desde la plataforma que elija. como su base También están agregando IOS a la lista de plataformas compatibles, por lo que la única plataforma que falta aquí es Android.

Xojo está lejos de ser perfecto, pero es un gran front-end GUI multiplataforma para que lo use con mis bibliotecas de nivel inferior que están codificadas en C y compiladas en las diferentes plataformas.

Siento que en los próximos años llegarán más soluciones multiplataforma y quien cree el primer sistema estándar de facto utilizando un lenguaje de programación ‘adecuado’ que se ejecuta en Windows, Linux, Mac, IOS y Android tiene el potencial de liderar la industria para los próximos años.

Además de la exactitud de casi todas las respuestas hasta ahora …

¿Por qué querrías escribir una consulta en C, cuando podrías usar SQL? Existen pros y contras, beneficios y trampas en cada una de las metodologías competitivas (además de lo que se adapta a la mente y experiencia de un desarrollador determinado, yendo hacia la comodidad individual, pensamientos y opiniones).

Y es por eso que, cuando SQL no es lo suficientemente bueno, y tiene una idea sobre cómo hacer algo diferente o mejor para una tarea determinada, termina con diferentes variantes (como NoSQL), diferentes estándares y luego Vuelva a las respuestas correctas aquí, que tienen que ver con los desafíos técnicos y las dificultades que rodean a los modelos de adopción.

¿Cuál es el obstáculo para crear un automóvil que reemplace las bicicletas, camiones, SUV, camionetas, autos de carrera, etc.?

No todos los problemas son iguales, y los idiomas se crean para satisfacer diferentes necesidades. Un lenguaje de script es diferente de un lenguaje incrustado y nuevamente diferente de un lenguaje numéricamente intensivo.

No hay Las personas no tienen diferentes lenguajes de programación porque algunos son mejores para ciertos objetivos que otros (aunque es cierto, por ejemplo, los lenguajes que no son JVM no son adecuados para JVM). Esto es simplemente porque para un idioma dado y un objetivo dado, solo necesita escribir un programa, un compilador, para que luego pueda traducir su código al idioma nativo de esta máquina. Obviamente esto es extremadamente simplificado.

La razón de la existencia de tantos lenguajes de programación es que incorporan una amplia gama de conceptos . La tipificación de patos, las clases de tipos, las macros higiénicas, los singletons, son todo lo que a la gente le gusta o no le gusta usar. Para tener el lenguaje de programación que los gobierne a todos, necesitaría que todos estuvieran de acuerdo sobre lo que le gustaría en un lenguaje de programación. Buena suerte.

Respuesta alternativa: no la hay. El código nativo se está convirtiendo en un concepto sin sentido, y Java es lo que está buscando. Feliz por siempre ahora? 🙂

Se llama a todos ellos !

OK, eso no es realmente justo. Hay lenguajes específicos de dominio que no estaban destinados a manejar todo. Pero en serio, ¿qué idioma has encontrado en la corriente principal que no fue diseñado para ejecutarse en todas partes y (eventualmente) para todos los propósitos?

El problema no son los idiomas, excepto que cada idioma toma decisiones que a la mayoría de las personas no les gustan, por lo que usan un idioma diferente. No puedes complacer a todos.

La sintaxis del lenguaje, sin embargo, es la parte menos gravosa del trabajo, por lo que no es que esté lastimando a nadie.

Agregando a R. Drew Davis.

Se trata de EGO en la industria del software.

Confía en mí. He visto a mi mentor trabajar en la publicación de un estándar con Open Group. ¡Es mucho más difícil de lo que piensas! La gente no está de acuerdo la mitad del tiempo, cuando cambias algo para acomodar a estas personas, otros dejan de estar de acuerdo contigo. Simplemente se reduce a un concurso de meadas con minutos desperdiciados en llamadas de conferencia.