¿Necesitamos un Java++?[cerrado]

https://stackoverflow.com/questions/484172

20-08-2019
|

Pregunta

A mí me parece que, en algunos aspectos, Java es donde C es un tiempo atrás.Ambos son bastante minimalista idiomas para su tiempo, con relativamente limpio, simple núcleos a construir.(Me refiero a la del núcleo del lenguaje aquí, no las bibliotecas.) Ambos son/eran extremadamente populares.Ambos son/fueron lingua francas, con un montón de código heredado.Ambos fueron/son las que carecen de modernas características de productividad de los programadores de otros lenguajes a menudo se olvida.Ambos parecen muy inercia dominado y lentos para adaptarse a un mundo cambiante.

Me parece que sería razonable para crear un Java++ que es aproximadamente un superconjunto de la de Java, C++ es C.Un lenguaje de intentar levantar Java en el relativo estancamiento es sufrido, romper la compatibilidad hacia atrás, sólo en algunas pocas maneras sólo si es absolutamente necesario, añadir un montón de características modernas que plain old Java falta, y la preocupación acerca de la normalización posterior.Características que podría ser una buena idea incluir:

Primera clase de funciones, los delegados.
Los cierres.
La inferencia de tipos estáticos, similar a var en C# o auto en D.
Sobrecarga de operadores.
Estructuras como el valor de los tipos distintos de las clases, tales como C# y D.
Propiedades.
Una opción para ignorar las excepciones comprobadas.
La capacidad para declarar más de un nivel superior pública de la clase en un archivo.
Más potente matrices integradas que permiten cosas como anexar.
Mejor genéricos/real de las plantillas.
Algo así como la dinámica de palabras clave de C# 4.0 que permite pato de escribir cuando sea necesario, en una estática con el lenguaje.
Dado que Java es principalmente una VM idioma, tal vez un poco de hardcore metaprogramación características como la generación de código sobre la marcha por ciertas cosas.

¿Crees que sería la demanda de un idioma?¿Crees que tal cosa iba a tener éxito?

Editar:No estoy hablando acerca de la compatibilidad en tiempo de ejecución/bytecode nivel, estoy hablando de la compatibilidad con Java en el fuente nivel.También, sí, Java 7 podría añadir algunos de estos, pero parece que la "oficial" del proceso para agregar características a Java es extremadamente conservador.El punto real es la idea de que se bifurcan en Java en una rama fueron el foco es la innovación más que la estabilidad/normalización.

Solución

Los fanboys de Java van a ser votados negativamente por esto, pero como alguien que escribe tanto Java como C #, diría que C # está tan cerca de Java ++ como usted lo va a conseguir.

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

Java se expande constantemente y Sun está incorporando rápidamente más y más funciones, por lo que podría ser que Java 7 u 8 sea su Java ++

Otros consejos

Como, digamos, Scala o mejor aún, Groovy, que se anuncia como una versión dinámica de java.

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

Grandes usuarios corporativos de Java tienen una tendencia a ser más conservador.Tienen un gran desarrollo personal y las grandes masas de código existente.Como consecuencia, existe un alto costo percibido y el riesgo de los cambios en el idioma o las bibliotecas (la formación, el mantenimiento, la rotura de código existente, etc.).

Por otro lado, hay un montón de pequeños, la luz-en-sus-pies dev equipos (open source o de otro tipo) que siempre están dispuestos a aferrarse a la Próxima Gran Idea en la programación.No es claro para mí que una sola respuesta va a dejar a todo el mundo lo suficientemente satisfecho.

Yo sugiero que el creciente ecosistema de JVM idiomas puede ayudar a superar esta tensión.Si nuevas lenguas (Scala, Ventilador, JRuby, JavaFxScript, etc.) proporcionar los métodos de representación de funciones (y la novedad) que el segundo grupo lo desea, mientras que el mantenimiento de la interoperabilidad con Java (que se puede mover en una más sosegado ritmo), tal vez ambos grupos pueden tener su elegido sabor de la torta.

Estoy un poco desconcertado por el grado en que algunas personas parecen querer Un Verdadero Lenguaje.De vuelta en el día, era muy común escuchar a la idea de que cada lengua (notación) había un "sweet spot" de aplicabilidad;a veces la solución correcta era escribir cada parte de un sistema en el idioma apropiado y vincular a ellos.

Regreso al futuro, ¿alguien?

La pregunta es realmente cómo decides qué va en " next language " ;. Solo agregar / eliminar características poco a poco dará como resultado un montón de basura. Es mucho mejor pensar cómo la adición o eliminación de esas funciones (a menudo combinadas) cambia la forma en que programa de acuerdo con los nuevos principios. Por ejemplo, pensé que era interesante que las propuestas de cierre de Java sufrieran de muchas maneras el tener que lidiar con la escritura estática sin inferencias de tipo rico. Hay abundantes ejemplos de lenguajes dinámicos con bonitos cierres, que van bien juntos. Y Scala y otros idiomas han demostrado que la escritura estática más la inferencia de tipos enriquecidos también pueden hacer que los cierres sean bonitos. Mi punto es que tomar el lenguaje X y hacer 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 te impida bifurcar Java ahora y convertirlo en lo que quieras (siempre que no lo llames Java o quieras pasar el conjunto de pruebas). Como se mencionó anteriormente, ya hay un conjunto de lenguajes emocionantes de alta calidad que hacen exactamente eso y mantienen la interoperabilidad con Java ahora. Estoy pensando principalmente en Groovy, Scala, Clojure y Fan y menos en puertos de lenguajes anteriores a JVM como JRuby, Jython y Rhino, que tienden a tener un momento más desafiante al implementar una integración Java limpia.

Es muy probable que las características JSR 292 lleguen a la JVM en Java 7 proporcionará un patio de juegos aún más rico para el desarrollo del lenguaje en la ya excelente base JVM. Y los CLR + DLR también están empujando muchos límites interesantes.

Cada vez más, creo que el futuro va a tender a elegir el idioma adecuado para el trabajo. Eso 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 fomenten una integración limpia entre múltiples idiomas. O lo más probable, ambos. Creo que NO estamos tendiendo hacia ningún Next Big Language que sea un derivado de Java (o cualquier otra cosa).

Actualmente en Java existen soluciones para muchos de estos, lo que dificulta la introducción de formas más naturales de hacer estas cosas.

Funciones de primera clase, delegados.

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

.4. Estructuras como tipos de valor distintos de las clases, como C # y D.

Con esto estaría de acuerdo.

.5. Propiedades.

Esto se puede hacer ahora, pero se requiere algo de esfuerzo. Un soporte adecuado 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 esta sea realmente una buena idea a menos que la gente realmente entienda las excepciones. A menudo, a las personas que sugieren esto no les gusta verse obligados a pensar en 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 nivel superior.

.8. Matrices integradas más potentes que permiten cosas como agregar.

Ver commons ArrayUtils. Se iniciará una matriz que tiene un toString sano ().

.9. Mejores genéricos / plantillas reales.

Estoy de acuerdo, dependiendo de lo que quieras decir. Creo que deberían hacer que la implicación actual funcione primero, antes de mejorarla. p.ej. Por lo tanto, las API de Java se pueden compilar sin advertencias sin marcar.

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

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

.11. Dado que Java es principalmente un lenguaje VM, quizás algunas características de metaprogramación hardcore como generar código sobre la marcha para ciertas cosas.

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

Si fuera a hacer grandes cambios, ¿no le gustaría comenzar de nuevo? Hay muchas cosas que podrían hacer con la reparación / eliminación en Java. No puede considerar las funciones de forma individual: interactúan de manera inesperada. Un lenguaje grande y complejo es probablemente un mal lenguaje (ver C ++).

Java ++ ya está aquí ...: D

Esas cosas son principalmente pelusas.

Debe resolver algunos problemas mayores, como hacer que el código concurrente sea fácil de diseñar y razonar.

Todo esto parece más bien " superficial " cambios de idioma principalmente motivados por la conveniencia del desarrollador en lugar de fundamentalmente cambiar la filosofía del idioma .

En mi opinión, los ajustes menores a la sintaxis no justifican un movimiento generalizado a un nuevo idioma, especialmente si eso significa desechar grandes inversiones en plataformas, bases de códigos y conjuntos de habilidades de desarrollador.

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, por ejemplo, C ++: en teoría, es un lenguaje sorprendente, que le permite programar en cualquier nivel posible de abstracción y, al mismo tiempo, permite un rendimiento a 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 entender lo que realmente está sucediendo, y las grandes bases de código se vuelven casi imposibles de mantener.

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

Ejecución de Bytecode en un entorno de ejecución multiplataforma portátil y estándar (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 obligatoria

Ejemplos de la siguiente etapa de cambios fundamentales serían:

Deseche la orientación a objetos en favor de programación funcional
Elimine el bloqueo a favor de Memoria transaccional de software para permitir un alto rendimiento, concurrencia segura para subprocesos para arquitecturas masivas de múltiples núcleos
Reemplace las variables mutables con valores inmutables en todas las bibliotecas de idiomas y clases (para que sea posible razón sobre el estado concurrente)
Adopte la metaprogramación de macro en tiempo de compilación como una solución genérica a cualquier deseo de agregar una nueva sintaxis al idioma o crear DSL

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

La mayoría de las características ya existen.

Ese idioma es:

_{(fuente: codehaus.org )}

En cuanto a:

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

Ha estado presente en Java desde el principio.

¿No sería un esfuerzo de Sun simplemente llamado Java 7 (o 1.7 o 2.0)? ¿No se llamaría a ese esfuerzo de otra persona / grupo algo distinto de Java?

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, debe tomar decisiones de diseño, razón por la cual los Java Generics no fueron tan buenos como podrían haber sido. Desearía liberarse de eso para obtener un Java más perfecto, creo, pero habría muy poca demanda porque la compatibilidad es donde está.

Y 7 pueden ir de inmediato. Aquí no estamos corriendo contra los límites de archivos FAT12 en un disquete.

Como Java se está convirtiendo en código abierto, usted puede tomar el código fuente (si está disponible) y crear su propia versión de Java. Si esto consigue una adopción a gran escala, entonces excelente, de lo contrario, puede que no sea un conjunto de características que son necesarias.

Java puede y debe mejorarse, pero no creo que deba existir un solo idioma para todas las necesidades. Esta es generalmente una mala idea, muy parecida a la estrella de la muerte.

Muchos programadores son simplemente vagos y no quieren aprender cosas nuevas. 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, es probable que termine con scripts de shell o un lenguaje de scripts como perl, python o ruby. Si haces muchas cosas específicas de matemáticas, Matlab es una buena opción. Etc. pp.

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

Sugiero echar un vistazo a Más allá de Java .

Hay una buena reseña en Joel en software .

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

Realmente estoy de acuerdo con tu opinión, habiendo tenido problemas con Java que podrían aliviarse con tus sugerencias.

En principio, podría escribir su propio javac que funcione para esto y use el HRESpot JRE existente. Sin embargo, realmente no puede hacer que eso suceda sin la ayuda de Sun.

El problema es realmente doble: 1) El enfoque de Sun es admitir la " plataforma Java " y es resistente a un nuevo estándar, incluso un superconjunto y 2) para obtener cualquier cambio en Java, debe obtener un JSR emitido, y eso generalmente requiere patrocinadores corporativos. 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 rehicieron Java desde cero = GNU classpath. Por lo tanto, existe el talento necesario para un & Quot; segundo lenguaje JVM de primera clase. & Quot;

Por mucho que siento que Java se ha quedado 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 allí, ¡pero aún así funciona! Todavía puede hacer todo, solo a veces lleva más tiempo y requiere más trabajo. Definitivamente estoy deseando que llegue el día en que sea reemplazado, pero creo que con todo el código y las aplicaciones existentes que están escritas en Java, por el 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. Quizás la programación funcional podría ser la próxima gran novedad y Scala será la próxima Java.

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

En cierto modo, creo que es al revés. Java está muy por delante de C ++. Java tiene bibliotecas y marcos de alto nivel, mientras que C ++ muy a menudo sigue siendo de bajo nivel y se mezcla con ansi C (porque podemos).

Java tiene buenas posibilidades de pruebas unitarias y grandes comunidades que apuntan en la misma dirección.

Tener más " características " no mejora un idioma Creo que es posible empeorarlo.

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

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

No afiliado a StackOverflow