¿Cuál es el enfoque principal de Java? ¿Por qué lleva tanto tiempo obtener nuevas funciones?


10

He estado explorando las nuevas características en el JDK8, como las expresiones lambda, los métodos de extensión y la nueva API de transmisión.

Evidentemente, ninguna de estas características es nueva en el mundo de la programación y eso hizo que se preguntara por qué están teniendo todas estas cosas en Java hasta ahora.

Tuvimos expresiones lambda en Lisp (1958), SML (1973), Haskell (1990), Python (1991), JavaScript (1994), Ruby (1995), Scala (2003), C # (2007) y 55 años después de Lisp y prácticamente todos los demás, en Java (2013).

Y había leído sobre transmisiones en SIC (1996).

Me he estado preguntando por qué ahora? La evidencia sugiere que competir con otros idiomas no es la motivación.

Parece que todas las nuevas características interesantes de esta versión de Java son solo un subproducto de la implementación del paralelismo. Tenemos lambdas porque simplifican la escritura de algoritmos paralelos, y tenemos métodos de extensión porque los necesitábamos para dar soporte a los cambios que requerían las expresiones lambda, etc., etc.

Entonces, mi pregunta es: ¿podemos afirmar con seguridad que el tema principal en esta próxima versión de Java es en realidad el paralelismo? ¿O podemos justificar otras razones para la aparición de los trucos más antiguos del libro hasta ahora en Java?


44
Todo esto puede convertirse en una guerra de llamas sobre el retraso de los tiempos de Java.
Michael K

55
The evidence suggests- Por favor comparte tu investigación.

2
Ninguna de las características en Java, JVM o JRE nunca fue nueva. E incluso la combinación de características no es nueva, Eiffel las tenía todas en 1985 (GC, OO, type-safety, incluso Generics que Java no obtuvo hasta 2003). De hecho, ha sido un objetivo expreso de los diseñadores de Java no introducir nada nuevo.
Jörg W Mittag

2
@MichaelK - Estoy de acuerdo en que esto podría convertirse en una guerra de llamas. También podría convertirse en una respuesta válida con respecto a la desafiante historia de Sun; La adquisición de Oracle de Sun y Java; y cómo los actuales mantenedores de Java están tratando de manejar el lenguaje. Espero que las respuestas se centren en los aspectos constructivos de esta pregunta.

@MichaelT: Espero que no se convierta en una guerra de llamas y puedan surgir algunas ideas interesantes. Por ejemplo, a menudo suponemos que un lenguaje que no evoluciona constantemente está atrasado. En mi opinión, esto no es cierto porque supone que la evolución del lenguaje es lineal (que todas las nuevas características que se vuelven populares son buenas y deberían ser adoptadas por todos los idiomas modernos). Pero los mantenedores de un idioma podrían decidir que una nueva característica no se ajusta al resto del idioma. Además, tenga en cuenta que hay lenguajes estandarizados y estables que definitivamente no están atrasados ​​(por ejemplo, Common Lisp).
Giorgio

Respuestas:


12

Cuando se diseñó Java por primera vez, se consideró apropiado omitir funciones anónimas. Puedo pensar en dos razones (pero pueden ser diferentes de las oficiales):

  1. Java fue diseñado como un lenguaje orientado a objetos sin funciones, por lo que no era muy natural tener funciones anónimas en un lenguaje sin funciones. O al menos, esto habría influido mucho en el diseño del lenguaje.
  2. Las funciones anónimas no eran populares en las comunidades de programadores que Java debía atraer (C, C ++, Pascal?). Incluso ahora, muchos programadores de Java parecen considerar estas características bastante exóticas (pero esto probablemente cambiará muy rápidamente con Java 8).

En los años siguientes, como Robert Harvey ha explicado, la política de Sun siempre fue mantener Java compatible con versiones anteriores y muy estable.

Por otro lado, han surgido otros lenguajes competidores (el más importante es C #, que nació como un clon de Java y luego tomó su propia dirección de desarrollo).

Los lenguajes competitivos han puesto a Java bajo presión por dos razones:

Poder expresivo

Las nuevas funciones pueden facilitar la escritura de ciertos modismos de programación, lo que hace que el lenguaje sea más atractivo para los programadores. Normalmente, el conjunto de características proporcionadas por un lenguaje es un compromiso entre el poder expresivo, la complejidad del lenguaje y la coherencia del diseño: agregar más características hace que un lenguaje sea más expresivo pero también más complejo y difícil de dominar.

De todos modos, en los últimos años, los competidores de Java agregaron muchas características nuevas que Java no tenía, y esto puede considerarse una ventaja.

Bombo

Sí, desafortunadamente este es un factor en la elección de la tecnología, al menos por lo que puedo ver en mi experiencia diaria como programador: una herramienta debe tener una determinada característica, incluso si la mayoría de los miembros del equipo no saben cómo usarla y aquellos que podrían usarlo no lo necesitan la mayoría de las veces.

El bombo puede ser aún más importante para las personas no técnicas como los gerentes, quienes pueden ser quienes deciden la plataforma para un determinado proyecto. Los gerentes a veces solo recuerdan algunas palabras clave como lambda, paralelismo, multinúcleo, programación funcional, computación en la nube, ... Si nuestra tecnología de elección tiene una marca verde en cada elemento de la lista, entonces estamos actualizados.

Así que IMO por algún tiempo Java ha sido atrapado entre

  • la política original de estabilidad del lenguaje y simplicidad de diseño, una gran base de código y comunidad de desarrolladores por un lado, y
  • la presión de los lenguajes competitivos que podrían atraer a los programadores de Java, C # al principio, y luego Scala, Clojure, F # (nombro los que conozco, puede haber otros).

Finalmente, Oracle decidió actualizar Java para hacerlo más competitivo. En mi opinión, las nuevas características se dirigen especialmente a los programadores de Java que podrían verse tentados a cambiar a C # y que ven otros lenguajes como Scala y Clojure como demasiado diferentes de Java. Por otro lado, los desarrolladores que tienen algo de experiencia con la programación funcional y todavía quieren usar la JVM probablemente ya se hayan cambiado a Scala, Clojure u otro idioma.

Por lo tanto, las nuevas características de Java 8 harán que Java sea más poderoso como lenguaje y el enfoque declarado es la programación concurrente y paralela, pero la actualización parece abordar también los aspectos de marketing (Mark Reinhold, arquitecto jefe de Java en Oracle, dijo: "Algunos lo harían decir que agregar expresiones Lambda es solo para mantenerse al día con los niños geniales, y hay algo de verdad en eso, pero la verdadera razón son los procesadores multinúcleo; la mejor manera de manejarlos es con Lambda ", vea este artículo ).

Entonces, sí, muchas (todas) las características de Java 8 ya eran bien conocidas, pero por qué y cuándo se agrega una característica a un idioma depende de muchos factores: audiencia objetivo, comunidad existente, base de código existente, competidores, marketing, etc.

EDITAR

Una breve nota con respecto a "... había leído sobre transmisiones en SIC (1996)": ¿quiere decir que necesita Java 8 lambdas para implementar transmisiones? En realidad, puedes implementarlos usando clases internas anónimas.


+1 Y desearía poder darte más puntos porque esta es la mejor respuesta hasta ahora a la pregunta.
edalorzo

Con base en su respuesta, investigué más sobre lo que Mark Reinhold había dicho que encontré un artículo interesante. Lo publicaré aquí con su respuesta para referencia futura: Closures for Java por Mark Reinhold .
edalorzo

Y ese artículo en realidad se refiere a este otro Closures for Java .
edalorzo

1
Desde el enlace que envió, encontré este ibm.com/developerworks/java/library/j-jtp03048/index.html#4.0 , diciendo que Java puede usar clases internas anónimas, pero estas son demasiado detalladas. Sin embargo, el cierre de Java 8 no es solo azúcar sintáctico para clases internas anónimas. Entonces, Java tendrá DOS (semánticamente) diferentes tipos de cierres: clases internas anónimas y expresiones lambda.
Giorgio

11

Java ha cambiado de enfoque con el tiempo. Al principio fue diseñado como un lenguaje simple y poderoso, como una reacción al "complejo poderoso" C ++. Algunas características que estaban en C ++ se omitieron intencionalmente, como la sobrecarga de operadores, plantillas, enumeraciones, que se consideraron demasiado complicadas o reliquias de la era C, y que OOP estaba en la cima de su popularidad, todo se convirtió en un Objeto de una sola vez. paradigma cosmovisión. Las lambdas en este momento se consideraban simplemente "no necesarias" desde la introducción de clases anónimas / internas en Java 1.1. El hecho de que la sintaxis fuera mucho más detallada casi se consideraba una característica .

Habiendo encontrado su público en Java, no hubo incentivos para cambiar hasta que Microsoft introdujo C #, que aprendió de las lecciones de los errores de diseño de Java, y lanzó una serie de nuevas características de lenguaje. No estaban limitados por la compatibilidad hacia atrás. Creo que los diseñadores de Java se dieron cuenta del peligro de la competencia de C # y lanzaron Java 5 con genéricos, enumeraciones, etc.

La inclusión de lambdas en Java se discute desde ese momento y solo se vio exacerbada por la tendencia actual de la programación funcional. Pero cosas como esta son lentas para hacer lo correcto, y tiene que ser correcto la primera vez. En mi opinión, Java falló los genéricos con borrado de tipo porque la compatibilidad con versiones anteriores se consideraba una razón para implementarlo como no más que el azúcar sintáctico. Parece que los cierres se han pensado más a fondo, y será más que solo azúcar sintáctico.

En conclusión, ¿cuál es el tema principal de Java 8? No creo que una versión de idioma tenga un tema. Como C ++ 11, la razón de ser de Java 8 es mantenerse al día con la competencia introduciendo en el lenguaje las cosas que más y más programadores dan por sentados ahora. Lisp puede tener lambda desde 1958, su popularidad se ha estancado durante décadas y solo recientemente la programación funcional se ha considerado seriamente para la programación "convencional" (por falta de una palabra mejor).


"Lisp puede tener lambda desde 1958, su popularidad se ha estancado durante décadas y solo recientemente la programación funcional ha sido considerada seriamente para la programación" convencional ": la popularidad de un lenguaje no parece ser un buen indicador de su efectividad. La programación funcional se ha defendido durante muchos años, pero la mayoría de las personas en la industria lo consideraban el tipo de cosas con las que a los investigadores les gusta jugar para escribir su tesis doctoral. Ahora, de repente, la industria está despertando y dándole una oportunidad, tal vez porque ahora que la POO es la corriente principal, están buscando la próxima gran cosa.
Giorgio

1
La razón por la cual los cierres no se incluyeron originalmente en Java de acuerdo con: Comprender el debate de cierres . Ahí, James Gossling dijo: "Los cierres quedaron fuera de Java inicialmente más debido a las presiones de tiempo que a cualquier otra cosa. En los primeros días de Java, la falta de cierres era bastante dolorosa, y así nacieron las clases internas: un compromiso incómodo que intentó evitar una serie de problemas difíciles. Pero como es normal en tantos problemas de diseño, las simplificaciones realmente no resolvieron ningún problema, simplemente los movieron ".
edalorzo

"La inclusión de lambdas en Java se discute desde entonces y solo se vio exacerbada por la tendencia actual de la programación funcional". Me parece interesante que en algunas comunidades (C ++, Java, ...) "usar lambdas" a menudo significa " haciendo programación funcional ".
Giorgio

8

Evidentemente, ninguna de estas características es nueva en el mundo de la programación y eso hizo que se preguntara por qué están teniendo todas estas cosas en Java hasta ahora.

Debido a que Java tiene que pasar por un proceso de aprobación que involucra a varias partes interesadas de alta visibilidad en un proceso similar al "diseño por comité", y ese proceso lleva tiempo, eso es todo.

Compare eso con otros idiomas y encontrará un dictador benevolente o un pequeño comité de diseñadores de idiomas que trabajan en estrecha colaboración y no están vinculados a los intereses corporativos.

Combine eso con una base de código establecida de millones de líneas de código Java que tiene que ser compatible con versiones anteriores, y tiene todos los ingredientes para cambiar a un ritmo glacial.


1
OTOH, también tiene los ingredientes para estándares realmente fuertes y ampliamente aceptados. Contraste, por ejemplo, JPA con la situación de PHP, donde everye web framework tiene su propio ORM a medias.
Michael Borgwardt

Puedo estar equivocado, pero entiendo que Haskell también es un lenguaje de "diseño por comité", y es un lenguaje de vanguardia. Entonces, ¿tal vez eso no sea lo que obstaculiza Java?
Andres F.

@AndresF. Sí, pero imagino que no tienes grandes compañías monolíticas en el comité de Haskell. Vea también la conversación en los comentarios aquí .
Robert Harvey

1

Diría que se debe utilizar el propósito más importante de un lenguaje de programación; actualmente C y Java no tienen expresiones lambda y son los lenguajes más utilizados (según TIOBE, por ejemplo).

Y para responder a la pregunta, creo que Java está dirigido a la empresa; en este dominio, las cosas deben ser muy estables y confiables; por ejemplo, Java 7 ha aparecido durante casi 2 años, pero no conozco directamente ningún proyecto en Java 7. Además, otra cosa importante es la compatibilidad con versiones anteriores, que es muy importante para la empresa.


Estoy de acuerdo con usted (+1): valoro mucho Java (como lenguaje y por su enorme ecosistema) pero me habría parecido más apropiado congelar el lenguaje en Java 6. No voy a poner ningún esfuerzo en aprender Java 7 u 8, a menos que me vea obligado (algún proyecto muy interesante en el que Java 7 u 8 sea obligatorio), prefiero pasar mi tiempo aprendiendo Scala y Clojure.
Giorgio
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.