Banda Ancha EU

Comunidad de usuarios
de fibra, móvil y ADSL

Origen del diseño de Java: Bill Joy quería los closures

BocaDePez
BocaDePez

Me han pasado esto donde, si mi inglés no está muy oxidado, Joy se peleaba por incluir en Java las características más frescas de lenguajes como Python mientras que, Patrick Naugthon y James Gosling querían cerrar el diseño y sacarlo a producción aprovechando la ventana de popularidad que estaba teniendo la marca.

Entonces, pregunto desde la ignorancia en compiladores e intérpretes y un conocimiento básico de Java, si realmente la idea de no incluir la sobrecarga de operadores fue más bien una decisión de usabilidad o de falta de tiempo, ¿podría haberse implementado fácilmente a posterior?

[Bill Joy] was often comparing Oak to more complicated and elegant languages like Python and Beta. He would often go on at length about how great Oak would be if he could only add closures and continuations and parameterized types. While we all agreed these were very cool language features, we were all kind of hoping to finish this language in our lifetimes and get on to creating cool applications with it. The more we argued with Bill about making those changes the more strongly he would fight us. After a while it became a choice between not having Bill involved at all or losing control of the language. James [Gosling] and I got into a rather epic battle with Bill in his office in Aspen one evening about this issue. He started out by insulting both of us about how poorly Oak compared to better languages and then he volunteered to resign from being the Live Oak architect if we wanted him to. James and I agreed that would be best and walked out to go across the street to watch "Speed". What a rush.

The next day, Bill was pretty much his normal old nice guy self again, a little relieved, I think, to be out of the role of being directly responsible for our destiny. Bill is annoyingly smart, and I wouldn't put it past him to have planned that whole scenario the night before to force us to defend our positions and take ownership of our project. The interesting thing is that we were right about needing to finish the language even though it had missing features. It was a timing issue, there was only about a three-month window in which the whole Java phenomenon could have happened. We barely made it. It is also interesting that Bill was absolutely right about what Java needs long term. When I go look at the list of things he wanted to add back then, I want them all. He was right, he usually is.

artima.com/weblogs/viewpost.jsp?thread=173229

vukits

sí que han tardado en meter Lambda calculo, pero ha llegado al final .

Una vez que has usado lambda calculo, no quieres usar otra cosa, la verdad ?

🗨️ 4
BocaDePez
BocaDePez

Me metí con Haskell y no le vi superpoderes, claro que tampoco lo puse en práctica). La metodología tiene sus características como POO tiene las suyas, supongo que cada lenguaje cubre un nicho y el funcional se debe a la concurrencia y multiprocesador, pero vamos, la pregunta era tal cual: si la herencia de Java fue un diseño rápido y sin acabar o mirando la usabilidad.

🗨️ 3
vukits

Un lenguaje tipo Haskell, o Maude, te permite derivar el código directamente a partir de la especificación, resultando en un código casi libre de bugs.

Te ahorras un montón de tiempo de verificación y depuración

🗨️ 2
BocaDePez
BocaDePez

Está muy bien y la PF resulta muy atractiva como novedad, ahora, qué pasa con el resto de cosas: codificación, mantenimiento, librerías, scope... Entiéndeme, el código sin errores es una buena cosa pero el resto también es importante. ¿Hay ciertos aspectos que se pueden ver como negativos?, la evaluación perezosa y la aplicación práctica junto a la memoria transaccional, por ejemplo.

...

La idea del texto original es que llegó un momento en que Java era tan complejo que se hacía complicado añadir nuevas características sin romper la retrocompatibilidad.

🗨️ 1
vukits