¿Qué lenguaje de bajo nivel de próxima generación es la mejor apuesta al migrar una base de código? [cerrado]

https://stackoverflow.com/questions/1815613

07-07-2019
|

Pregunta

Supongamos que tiene una empresa que ejecuta muchos C / C ++ y desea comenzar a planificar la migración a nuevas tecnologías para que no termine como las empresas COBOL hace 15 años.

Por ahora, C / C ++ funciona más que bien y hay muchos desarrolladores en el mercado para ello.

Pero quiere comenzar a pensarlo ahora, porque dada la enorme base de código en ejecución y la sensibilidad de los datos, cree que puede llevar de 5 a 10 años avanzar al siguiente paso sin sobrecargar el presupuesto y los equipos de desarrollo.

Has oído hablar de D , que comienza a ser bastante maduro, y Ir , prometiendo ser bastante popular.

¿Cuál sería tu elección y por qué?

Solución

D y Go probablemente se volverán tan populares como Python y Ruby son hoy. Cada uno llena un nicho, y aunque se suponía que D era un reemplazo completo de C ++, probablemente nunca adquirirá suficiente masa para alejar a C ++. Sin mencionar que ambos no son lo suficientemente estables / maduros, y se desconoce si tendrá soporte para estos idiomas en 10-20 años para el hardware y los sistemas operativos actuales. Teniendo en cuenta que C / C ++ es más o menos el lenguaje compilado y se utiliza en la gran mayoría de los sistemas operativos y aplicaciones de código nativo, es muy poco probable que desaparezca en el futuro previsible.

Otros consejos

C y C ++ son una combinación casi inmejorable cuando se trata de nativo / no administrado / " bajo nivel " idiomas.

No porque sean los mejores idiomas, ni mucho menos, sino porque están allí, hacen el trabajo y son suficientemente buenos . Hay pocas dudas de que D, por ejemplo, es mejor que C ++ en la mayoría de los aspectos. Pero falla en el más importante: compatibilidad con todo el código C ++ existente. Sin ese requisito, la mayor parte de ese código se escribiría en un lenguaje administrado hoy de todos modos. La única razón por la que muchas bases de código usan C ++ hoy en día es porque la usaron el año pasado, y sería demasiado doloroso cambiar a otra cosa. Pero if y when cambian, normalmente no cambian a D. Cambian a C # o Java o Python.

El problema para D y otros "próximos" Los idiomas que compiten por los mismos nichos es que, si bien son mejores, no son lo suficientemente innovadores como para motivar a las personas a cambiar a ellos.

Entonces C y C ++ están aquí para quedarse. C es poco probable que evolucione mucho más. Es como es, y uno de los nichos que tiene que llenar es la simplicidad, incluso para los escritores de compiladores. Es probable que ningún otro idioma lo supere en ese nicho, incluso si nunca vuelven a revisar el estándar.

C ++ está evolucionando mucho más dramáticamente, con C ++ 0x cada vez más cerca, y ya tienen una gran lista de características que quieren hacer después . C ++ no es un callejón sin salida de ninguna manera.

Ambos idiomas están aquí para quedarse. Quizás en 50 años otros idiomas los hayan reemplazado, pero no sucederá en esta década.

Actualmente uso D regularmente. Todavía no lo recomendaría a las personas que escriben código de producción porque es demasiado avanzado. Me salgo con la suya porque la mayor parte de mi código son prototipos de investigación en bioinformática. Sin embargo, el lenguaje está comenzando a estabilizarse. Andrei Alexandrescu está lanzando un libro titulado "El lenguaje de programación D" el próximo marzo, y ahora hay un impulso para estabilizar la especificación de la versión 2 del idioma a tiempo para el libro.

Si bien D no es un superconjunto formal de C, es lo que yo llamaría un superconjunto idiomático, excepto por la falta de un preprocesador. En otras palabras, cualquier código escrito en C propiamente dicho (ignorando el preprocesador), se puede traducir trivialmente a D sin un rediseño, porque los conceptos de C como punteros y ASM en línea están allí y funcionan igual en D que en C. D también admite directamente vincular a código C y la biblioteca estándar de D incluye toda la biblioteca estándar de C.

Además, a pesar de la falta de bibliotecas de D porque todavía es un lenguaje de vanguardia, es el sueño de un escritor de bibliotecas debido a sus capacidades de metaprogramación. Si despega, probablemente tendrá algunas librerías bastante impresionantes. Para obtener una vista previa de esto, vea std.range o std.algorithm en la biblioteca estándar D2 (Phobos). Como otro ejemplo, implementé un modelo de paralelismo similar a OpenMP (foreach paralelo, mapa paralelo, reducción paralela, futuros) como una biblioteca pura en D, sin ningún soporte especial del compilador. (Ver http://cis.jhu.edu/~dsimcha/parallelFuture.html )

Dado que está principalmente interesado en el largo plazo, yo diría que le dé a D 6 meses para estabilizarse (dado el libro de Andrei y el impulso actual para estabilizar el idioma, la versión 2 debería ser estable para entonces) y luego tomar un mirarlo detenidamente.

Editar: ahora que la especificación del lenguaje central es relativamente estable y el enfoque se ha centrado en el desarrollo de la cadena de herramientas y la biblioteca, recomendaría D para pequeños proyectos de producción a menos que se encuentre en un entorno muy reacio al riesgo . Sin embargo, los proyectos más grandes que absolutamente deben tener una buena cadena de herramientas y soporte de biblioteca deberían esperar.

Si cree en los principios de manufactura esbelta, debe esforzarse por "decidir lo más tarde posible". El momento debe ser el último momento responsable, es decir, el momento en que no tomar una decisión elimina una alternativa importante.

Creo que este principio se puede aplicar a su situación. En lugar de comprometerse ahora con un idioma (que ni siquiera sabe que existirá en 10 años), debe mantener abiertas sus opciones. Tal vez refactorice parte de su código para que sea un poco más genérico o se base en más abstracciones, de modo que cuando sea necesario migrar, el proceso sea más fácil.

Quédate con C y C ++. No lo veo como COBOL, funciona tan bien como cualquier otra cosa, y no tendrá problemas para encontrar personas para codificar en C y C ++.

C ++ : es relativamente joven y actualizado ... Tiene una gran cantidad de proveedores de compiladores y obtuvo mejorado todo el tiempo.

C : viviría durante mucho tiempo llenando el vacío entre ensamblador y lenguajes de nivel superior. También es un lenguaje muy simple y fácil de implementar, por lo que seguiría siendo el primer idioma para varios " extraño " arquitecturas como incrustadas o extremadamente nuevas.

D es prometedor pero sigue siendo especificaciones y bibliotecas muy nuevas e inestables.

Go nació hace unas semanas ... Nunca use nada de la versión 0 para grandes proyectos importantes. También es significativamente más limitado el C ++ o D .

Actualización de 2019: C ++ se mantendrá durante los próximos 10 años ... (si no, corregiré esta respuesta, cuando ya no sea relevante ...)

la razón por la cual las compañías trabajan con COBOL hoy es porque ya tienen millones de códigos COBOL escritos. si pueden lanzarlo, lo harán de una vez, por otro lado, las compañías trabajan con C / C ++ como parte de sus necesidades y los nuevos proyectos que usan este lenguaje b / c no pueden / no quieren usar java / c # cualquier otro lenguaje basado en framework, por lo que COBOL no es la analogía aquí.

Como dsimcha dijo que la forma D es actualmente arriesgada. Sin embargo, el lenguaje tiene un gran potencial, es de bajo nivel y he experimentado una productividad drásticamente mejor con D (en lugar de C ++). Quizás lo que la gente siente con los lenguajes dinámicos.

Go está tan publicitado en el blog que me parece una broma. El envío de un método de interfaz no es trivial, y en realidad es más lento que el envío de un método de herencia única regular.

Si tuviera una enorme base de código, la decisión es, por supuesto, más difícil, solo recomendaría cambiar por nuevos proyectos, no por los existentes.

No me concentraría en un idioma, sino más en las bibliotecas que lo rodean. C ++ en combinación con las bibliotecas de impulso son una excelente opción. Las personas que se desarrollan en C ++ tienden a tener una mejor comprensión de la informática, yo mismo comencé con Java, lo que me facilitó la vida al ocultar muchas cosas fundamentales, lo cual es bueno, sin embargo, solo comencé a entender la programación una vez que aprendí C / C ++ (punteros, etc.).

Reconozco que C ++ puede ser difícil (por ejemplo, administración de memoria), así que creo que es bueno tener un lenguaje 'agregado' donde el rendimiento no es esencial y la legibilidad (== mantenibilidad) es alta: recomiendo Python para esto.

Hay innumerables máquinas que ejecutan el software C ++, no veo que se apaguen todas a la vez. Si C ++ se interpone en el camino de COBOL, habrá un gran mercado para la migración de aplicaciones. Habrá herramientas especializadas desarrolladas para traducir aplicaciones C ++ al lenguaje popular de la época (Z ++ ???).

Así que supongo que el mejor consejo es cruzar ese puente cuando llegues a él.

Consulte Intel & # 174; Cilk ++ Software Development Kit si desea despertar su interés en el desarrollo de C ++ / Multi-Core. Tampoco veo que C o C ++ desaparezcan pronto.

Comparar C * con Cobol es cuestionable

Comparar C * con Cobol puede llevar a una conclusión incorrecta. C fue perfecto para su día, un gran salto adelante en su introducción, y todavía hace el trabajo hoy.

Resumiría Cobol en mi día más caritativo con " buen intento " ;.

C y C ++ sobrevivirán durante mucho tiempo porque se ajustan bien a la factura como lenguajes de implementación. Esto nunca cambiará realmente.

Además, considere que el principal problema negativo con C / C ++ es la falta de seguridad de la memoria. Esto tiende a ser un problema cada vez menor a medida que los códigos maduran. Esto significa que no habrá una razón seria para reemplazar los códigos antiguos.

Espero que los sistemas de software crezcan hacia afuera desde C. Mire la jerarquía hoy:

aplicación escrita en un marco como Rails
back-end de la aplicación escrito en Ruby, PHP, Python, C #, lo que sea
Implementación en tiempo de ejecución de Ruby, PHP, Python o C # (escrita en C *)
núcleo del sistema operativo (escrito en C89)

No creo que las viejas capas desaparezcan, y creo que las capas superiores heredadas escritas en C y C ++ simplemente serán compatibles de esa manera por un período de tiempo indefinido, y finalmente se eliminarán gradualmente para sus reemplazos escritos en Ruby, Python , C #, o un desarrollo futuro.

No tenemos idea si Go encontrará aceptación. Simplemente estar en Google probablemente no sea suficiente.

D? Bueno, se dicen algunas cosas buenas al respecto, pero tampoco despegará. No hay base de usuarios para hablar. D es el número 20 en popularidad en el Índice TIOBE y cayendo rápido.

Puede decir que la popularidad de un idioma tiene poco que ver con lo bien que se adapta al trabajo de su empresa. Pero tiene mucho que ver con lo fácil que será encontrar personas calificadas para programar en él.

Java está en la cima y me sorprendería si desapareciera en los próximos 20 años. No se considera un lenguaje de programación de sistemas, pero funciona lo suficientemente bien como para que haya pocas tareas que haría en C ++ que no podría hacer en Java. Ciertamente, en estos días, nadie está dispuesto a encargar a los programadores humanos con el trabajo realizado (sin fallas y, a menudo, de manera más efectiva) por el recolector de basura. Por mi parte, consideraba que Java era un paso significativo desde C ++ en términos de efectividad de programación.

Estoy bastante impresionado con Ruby . Es un lenguaje elegante y expresivo: puede lograr mucho sin demasiado código, pero ese código sigue siendo en su mayoría legible. Uno de los principios principales de Ruby es ser coherente y no tener sorpresas para el desarrollador. Esta es una muy buena idea, IMO, y aumenta la productividad. En el momento de la gran exageración de Rails (que aún puede estar en curso), hice un gran rodeo alrededor de Ruby porque su implementación de referencia es abismalmente lenta. Sin embargo, la gente de JRuby en Sun lo ha hecho increíblemente rápido en una JVM, por lo que ahora definitivamente vale la pena considerarlo. Ruby proporciona cierres y un buen puñado de capacidades de programación funcional (vea a continuación por qué es tan importante), aunque en realidad no se considera un lenguaje FP. Índice TIOBE: 10 y en aumento.

Algo a tener en cuenta para el futuro es el hecho de que los fabricantes de CPU se han enfrentado a un límite de rendimiento impuesto por la física. Ya no hay una CPU 30% más rápida disponible cada Navidad, como lo era en el pasado. Entonces, para obtener más rendimiento, necesita más núcleos. El desarrollo de software necesitará toda la ayuda que pueda obtener para admitir la programación concurrente multinúcleo. C ++ te deja casi solo con esto, y las soluciones de Java son horribles para los estándares modernos.

En vista de esto, existe una cierta tendencia hacia la programación funcional (que elimina gran parte de la molestia asociada con la concurrencia), así como lenguajes con mejor soporte de concurrencia. Erlang fue escrito específicamente para esto y para la capacidad de intercambiar código en un programa en ejecución (Ericsson quería tiempos de actividad increíbles). Scala es similar a Java pero con un soporte mucho más fuerte para programación funcional y concurrencia. Clojure , lo mismo, pero es un Lisp y ni siquiera está en el top 50 (¡todavía!).

Scala fue desarrollado académicamente, y lo muestra: es sofisticado y francamente pedante sobre los tipos de datos; trata de ser la navaja suiza de los lenguajes de programación. Creo que muchos programadores medianamente inteligentes tendrán problemas para controlar Scala. Ruby tiene menos FP y no hace mucho por la concurrencia, pero es pragmático y divertido y fácil de hacer. Además, al ejecutarse en la JVM, hay una enorme cantidad de código fácilmente disponible en las bibliotecas de Java, que Ruby puede interactuar con. Entonces:

Mi apuesta sería en Ruby, con una posibilidad externa en Scala. ¡Pero hay muchas alternativas!

Java. Para la mayoría de las cosas de bajo nivel, Java está bien en estos días. ¿Por qué elegir una solución parcial para C / C ++ como D o Go cuando puede tener algo tan seguro y fácil de desarrollar como Java? Si está buscando una solución en tiempo real, D y Go definitivamente lo no , sin mencionar que probablemente sean incluso menos compatibles que Java.

Java ahora es un lenguaje de programación del sistema . No veo cómo se puede considerar algo con construcciones inseguras, como punteros '' next gen ''. La única razón por la que existieron esas construcciones inseguras es porque fue el enfoque pragmático para construir un lenguaje completo. No había preocupación de representar la memoria en objetos discretos, porque solo querían construir algo que funcionara . Ya hay aplicaciones en tiempo real duras y suaves en Java, una variedad de procesadores de código de bytes de hardware y más de 2 mil millones de dispositivos móviles que ejecutan Java. A lo sumo, todo lo que tendría que hacer es agregar algunas construcciones para la interoperabilidad con los dispositivos, lo que no sería tanto código; incluso en C / C ++ todavía tendría que agregar estas construcciones ...

¿Qué estás programando? Microcontroladores de 8 bits con 1KB de ram? En ese caso, no tendría sentido usar otra cosa que no sea el ensamblador para esa plataforma ...

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow