valuable trends top the programming new most languages language for demand best java c++ programming-languages language-design innovation

java - trends - the best programming language



¿Necesitamos un Java++? (19)

Me parece que, de alguna manera, Java es donde C hace un tiempo. Ambos son lenguajes bastante minimalistas para su época, con núcleos relativamente limpios y simples en los que se puede construir. (Me refiero al lenguaje central aquí, no a las bibliotecas). Ambos son / fueron extremadamente populares. Ambos son / fueron lingua francas, con toneladas de código heredado. Ambos carecen / están careciendo de varias características modernas de productividad que los programadores de otros lenguajes a menudo pasan por alto. Ambos parecen muy dominados por la inercia y tardan en adaptarse a un mundo cambiante.

Me parece que sería razonable crear un Java ++ que sea más o menos un superconjunto de Java, ya que C ++ es un C. Ese lenguaje intentaría sacar a Java del relativo estancamiento que ha sufrido, romper la compatibilidad solo en unos pocos solo formas menores si es absolutamente necesario, agregue muchas características modernas que faltan en el viejo Java simple, y preocúpese por la estandarización más adelante. Las características que pueden ser una buena idea incluyen:

  1. Funciones de primera clase, delegados.
  2. Cierres
  3. Inferencia de tipo estático, similar a var en C # o auto en D.
  4. Sobrecarga del operador.
  5. Estructura como tipos de valores distintos de las clases, como C # y D.
  6. Propiedades
  7. Una opción para ignorar las excepciones marcadas.
  8. La capacidad de declarar más de una clase pública de nivel superior en un archivo.
  9. Arrays incorporados más poderosos que permiten cosas como agregar.
  10. Mejores genéricos / plantillas reales.
  11. Algo así como la palabra clave dinámica para C # 4.0 que permite el tipado de pato cuando es necesario en un lenguaje generalmente estático.
  12. Dado que Java es principalmente un lenguaje VM, tal vez algunas funciones de metaprogramación difíciles como generar código sobre la marcha para ciertas cosas.

¿Crees que habrá demanda de ese tipo de lenguaje? ¿Crees que tal cosa tendría éxito?

Editar: no estoy hablando de compatibilidad en el nivel de tiempo de ejecución / bytecode, estoy hablando de compatibilidad con Java en el nivel de origen . Además, sí, Java 7 podría agregar algunos de estos, pero parece que el proceso "oficial" para agregar funciones a Java es extremadamente conservador. El verdadero punto es la idea de convertir a Java en una sucursal si la atención se centra más en la innovación que en la estabilidad / estandarización.

¿Como, digamos, Scala o mejor aún Groovy, que se anuncia a sí mismo como una versión dinámica de Java?

¿Tal esfuerzo de Sun simplemente no se llamaría Java 7 (o 1.7 o 2.0)? ¿No se llamaría tal esfuerzo de otra persona / grupo a algo diferente a Java?

Actualmente en Java hay soluciones para muchos de estos, lo que hace que sea más difícil introducir formas más naturales de hacer estas cosas.

  1. Funciones de primera clase, delegados.

La mayoría de los casos son más cortos usando la reflexión. (Pero menos natural)

.4. Estructura como tipos de valores distintos de las clases, como C # y D.

Esto estaría de acuerdo con.

.5. Propiedades

Esto se puede hacer ahora, pero se requiere un poco de esfuerzo. El soporte adecuado de builtin sería mejor.

.6. Una opción para ignorar las excepciones marcadas.

Puedes hacer esto ahora, pero es un truco. Nota: las excepciones marcadas son una función de tiempo de compilación.

Soy bastante escéptico de que esto sea realmente una buena idea a menos que la gente entienda realmente las excepciones. A menudo, las personas que sugieren esto no quieren que les obliguen a pensar sobre las condiciones de error, documentarlas o manejarlas.

.7. La capacidad de declarar más de una clase en un archivo.

Puedes hacer esto ahora. Simplemente no más de una clase pública de alto nivel.

.8. Arrays incorporados más poderosos que permiten cosas como agregar.

Ver los commons ArrayUtils. Una matriz que tiene una sana toString () sería inicio.

.9. Mejores genéricos / plantillas reales.

Estoy de acuerdo, dependiendo de lo que quieras decir. Creo que deberían hacer que la implementación actual funcione primero, antes de mejorarla. por ejemplo, las API de Java se pueden compilar sin advertencias no verificadas.

.10. Algo así como la palabra clave dinámica para C # 4.0 que permite el tipado de pato cuando es necesario en un lenguaje generalmente estático.

De nuevo, la reflexión hace esto, pero es relativamente feo.

.11. Dado que Java es principalmente un lenguaje VM, tal vez algunas funciones de metaprogramación difíciles como generar código sobre la marcha para ciertas cosas.

Como JavaCompiler (en java 6), soporte de scripting (en java 6), JCI o BeanShell.

C ++ está orientado a objetos C. Java ya está orientado a objetos, entonces, ¿cómo vamos a hacer otro cambio de paradigma, convirtiéndolo en Java ++?

De alguna manera, creo que es al revés. Java está muy por delante de C ++. Java tiene bibliotecas y marcos de alto nivel, mientras que C ++ a menudo todavía es de bajo nivel y está entremezclada con ansi C (porque podemos).

Java tiene buenas posibilidades de prueba unitaria, y grandes comunidades que apuntan en la misma dirección.

Tener más "características" no mejora el idioma. Creo que es posible empeorar las cosas.

Al final, poner un idioma "en frente" del otro no va a ayudar. Seleccione la mejor herramienta para el trabajo. Creo que Java es un lenguaje bastante bueno, tal como es. Sin embargo, C ++ podría usar algunas bibliotecas mejores, como un puerto de Spring por ejemplo.

Como Java se está convirtiendo en código abierto, puede tomar la fuente (si está disponible) y crear su propia versión de Java. Si esto se adopta a gran escala, entonces genial, si no, puede que no sea un conjunto de características que se necesitan.

Consulte la información que está disponible en Java 7. Creo que encontrará que está programado para agregar varias características que todo el mundo está pidiendo, sobre todo cierres.

Creo que la respuesta a " ¿Necesitamos un Java ++? " Depende de quiénes somos " nosotros " (y no estoy seguro de que " nosotros " somos todas las instancias de una clase ;-). Este tema ha sido discutido en más de una ocasión por The Java Posse .

Los grandes usuarios corporativos de Java tienden a ser más conservadores. Tienen grandes plantillas de desarrollo y grandes cantidades de código existente. Como consecuencia, existe un alto costo percibido y un riesgo para los cambios en el idioma o las bibliotecas (capacitación, mantenimiento, rotura del código existente, etc.).

Por otro lado, hay muchos equipos de desarrollo pequeños y ligeros (de código abierto o de otro tipo) que siempre están listos para unirse a Next Great Idea en la programación. No tengo claro que una sola respuesta deje a todos suficientemente satisfechos.

Sugiero que el creciente ecosistema de lenguajes basados ​​en JVM puede ayudar a resolver esta tensión. Si los lenguajes más nuevos (Scala, Fan, JRuby, JavaFxScript, etc.) proporcionan las características de notación (y novedad) que el segundo grupo desea, manteniendo la interoperabilidad con Java existente (que puede moverse a un ritmo más tranquilo), tal vez ambos grupos puedan tener su sabor elegido de la torta.

Estoy un poco desconcertado por el grado en que algunas personas parecen querer One True Language. En el pasado, era bastante común escuchar la idea de que cada lenguaje (notación) tenía un "punto óptimo" de aplicabilidad; a veces la solución correcta era escribir cada parte de un sistema en el lenguaje apropiado y vincularlas.

De vuelta al futuro, ¿alguien?

Esas cosas son en su mayoría pelusas.

Debes resolver algunos problemas más grandes, como hacer que el código simultáneo sea fácil de diseñar y razonar.

Java puede y debe mejorarse, pero no creo que deba haber un lenguaje que se ajuste a todas las necesidades. En general, esta es una mala idea, al igual que la estrella de la muerte.

Muchos programadores son flojos y no quieren aprender cosas nuevas. Ellos prefieren quedarse con el idioma que han estado usando durante los últimos 10 años.

Si necesita velocidad y más control sobre su hardware, usa algo como C. Si necesita tareas de administración del sistema, probablemente terminará con scripts de shell o un lenguaje de script como perl, python o ruby. Si haces muchas cosas específicas de matemáticas, Matlab es una buena opción. Etc. pp.

Utilice la mejor herramienta para la tarea, sin importar el idioma que sea. Un buen programador debería ser capaz de trabajar con cualquier idioma (en cuanto a mí, todavía estoy trabajando en eso).

La pregunta es realmente cómo decide qué va en el "siguiente idioma". Solo agregar / eliminar funciones por partes dará como resultado un montón de basura. Es mucho mejor pensar cómo la adición o eliminación de esas características (a menudo trabajando en combinación) cambia la forma en que se programa según los nuevos principios. Por ejemplo, pensé que era interesante que las propuestas de cierres de Java sufrieran en muchas formas por tener que lidiar con el tipado estático sin la inferencia de tipos enriquecidos. Hay abundantes ejemplos de lenguajes dinámicos con cierres bonitos, que van bien juntos. Y Scala y otros idiomas han demostrado que la tipificación estática más la inferencia de tipo enriquecido también pueden hacer que los cierres sean bonitos. Mi punto es que tomar el lenguaje X y crear el lenguaje X ++ probablemente no sea tan interesante. Es más interesante ver problemas en X y crear un nuevo lenguaje Y.

Ciertamente, no hay nada que le impida bifurcar Java ahora y convertirlo en lo que desee (siempre y cuando no lo llame Java o quiera pasar el banco de pruebas). Como se mencionó anteriormente, ya hay un conjunto de idiomas de alta calidad emocionantes que hacen precisamente eso y mantienen la interoperabilidad con Java ahora. Estoy pensando principalmente en Groovy, Scala, Clojure y Fan y en menos puertos de idiomas anteriores a la JVM como JRuby, Jython y Rhino, que tienden a tener un momento más desafiante implementando la integración limpia de Java.

Es bastante probable que las características JSR 292 que llegan a la JVM en Java 7 proporcionen un patio de recreo aún más rico para el desarrollo del lenguaje en la base de JVM ya espléndida. Y el CLR + DLR también está empujando muchos límites interesantes.

Cada vez más, creo que el futuro tenderá a elegir el idioma adecuado para el trabajo. Eso va a suceder en idiomas con una tradición combinada (Scala es un buen ejemplo de FP / OO por ejemplo) o en máquinas virtuales (JVM, CLR, BEAM, Parrot, lo que sea) que fomentan la integración limpia entre múltiples idiomas. O muy probablemente, ambos. Creo que NO estamos tendiendo a ningún Next Big Language que sea un derivado de Java (o cualquier otra cosa).

Si agrega soporte para esas estructuras a la JVM (cuando sea necesario, por ejemplo, cierres), y luego cree el azúcar sintáctico necesario en el lenguaje escrito y el compilador. Por supuesto, si desea conservar la compatibilidad con versiones anteriores, entonces tiene que tomar decisiones de diseño, y es por eso que los Java Generics no fueron tan buenos como podrían haber sido. Quisiera liberarse de eso para obtener un Java más perfecto, creo, pero habría muy poca demanda porque la compatibilidad está donde está.

Y 7 puede irse de inmediato. No estamos corriendo contra los límites de archivos FAT12 en un disquete aquí.

Si hicieras grandes cambios, ¿no querrías comenzar de nuevo? Hay muchas cosas que podrían hacer con la fijación / eliminación en Java. No puede considerar las características individualmente, interactúan de forma inesperada. Un lenguaje grande y complejo es probablemente un mal lenguaje (ver C ++).

Por mucho que sienta que Java se ha vuelto obsoleto, la verdad es que creo que todos sabemos que, como lenguaje, todavía funciona bastante bien. Claro, muchas de las cosas más nuevas que podemos encontrar en otros idiomas no están ahí, ¡pero aún funcionan! Todavía puede hacer todo, a veces lleva más tiempo y requiere más trabajo. Definitivamente estoy esperando el día en que sea reemplazado, pero creo que con todos los códigos y aplicaciones existentes que están escritos en Java, de momento no hay forma de que (casi) nadie haga el cambio a Java ++. Creo que estamos esperando un cambio de paradigma real, como C ++ fue para C. Tal vez la programación funcional podría ser la próxima gran cosa y Scala será el próximo Java.

Realmente estoy de acuerdo con tu opinión, habiendo encontrado problemas con Java que podrían ser aliviados por tus sugerencias.

En principio, podría escribir su propio javac que funcione para esto y use el JRE de Hotspot existente. Sin embargo, realmente no puedes lograrlo sin la ayuda de Sun.

El problema es realmente doble: 1) El enfoque de Sun es soportar la "plataforma Java" y es resistente a un nuevo estándar, incluso un superconjunto y 2) para obtener cualquier cambio en Java, tiene que obtener un JSR emitido, y eso generalmente requiere un patrocinador corporativo. Las corporaciones tienden a tener otras prioridades.

Por otra parte, te insto a que lo presiones. Después de todo, hasta 2007 muchas personas inteligentes casi rehacen Java desde cero = classpath GNU. Entonces, existe el talento necesario para un "segundo lenguaje de JVM de primera clase".

Los fanboys de Java me han votado negativamente por esto, pero como alguien que escribe tanto Java como C # diría que C # es lo más cercano a Java ++ que va a obtener.

C a C ++ fue un cambio de paradigma, de procedimental a orientado a objetos, la única razón por la que retienen el nombre es para atraer a los programadores C a pensar que era el mismo lenguaje lo que llevó a una carga de código C realmente malo disfrazado de C ++.

Java se expande constantemente y Sun está incorporando rápidamente más y más características, por lo que bien podría ser que Java 7 u 8 es tu Java ++

Todos estos parecen cambios de lenguaje más bien "superficiales" motivados principalmente por la conveniencia del desarrollador en lugar de cambiar fundamentalmente la filosofía del lenguaje .

Desde mi punto de vista, los ajustes menores a la sintaxis no justifican un movimiento mayorista hacia un nuevo idioma, especialmente si eso significa tirar grandes inversiones en plataformas, bases de códigos y conjuntos de habilidades de desarrollo.

Los cambios menores se pueden agregar al lenguaje Java a lo largo del tiempo (en Java 7, 8, 9 ...) si hay suficiente demanda. Sin embargo, existe una pregunta real sobre si están justificados, ya que un cambio como este hace que el lenguaje sea más complejo y, por lo tanto, más difícil de aprender y mantener bases de código a medida que diferentes desarrolladores comienzan a usar un subconjunto diferente de las características.

Tomemos como ejemplo C ++: en teoría es un lenguaje sorprendente, que le permite programar en cualquier nivel posible de abstracción, al tiempo que permite el rendimiento del nivel de código de máquina en código optimizado. En la práctica, la complejidad de toda esta funcionalidad del lenguaje significa que muy pocos mortales pueden esperar comprender lo que realmente está sucediendo, y las bases de códigos grandes se vuelven casi imposibles de mantener.

En mi opinión, los únicos cambios que justificarían un "Java ++" al por mayor serían cambios de paradigma fundamentales que cambiarían la forma en que desarrollas el software para mejor. Los cambios fundamentales que hicieron Java un éxito (sobre C ++, etc. en 1995-2000) fueron en mi opinión:

  • Ejecución de bytecode en un entorno de tiempo de ejecución portátil, estándar y multiplataforma (JVM / JRE) sin necesidad de una recompilación
  • Una biblioteca de clase estándar grande y robusta (que incluye subprocesos, redes, GUI, etc.), es decir, un reconocimiento de que la plataforma es mucho más que solo el lenguaje
  • Recolección de basura hecha obligatoria

Ejemplos de la próxima etapa de cambios fundamentales serían:

  • Bote la orientación del objeto a favor de la programación funcional
  • Elimine el bloqueo a favor de la memoria transaccional de software para permitir la concurrencia de alto rendimiento y seguridad de subprocesos para arquitecturas multinúcleo masivas
  • Reemplazar variables mutables con valores inmutables en todas las bibliotecas de idiomas y clases (para permitir razonar sobre el estado concurrente)
  • Adopte la metaprogramación de macro en tiempo de compilación como una solución genérica para cualquier deseo de agregar nueva sintaxis al lenguaje o crear DSL

Ah, sí, y hay un lenguaje JVM que hace todo esto - Clojure