Lenguajes y metodología (opinión publicada en Solo Programadores)

Lenguajes y metodología

Eduardo Millán, analista-programador de Saytel.

 La mayoría de las personas con reciente formación en un determinado lenguaje - Java por ejemplo - se sienten ya preparados y con ganas de iniciar la vida laboral de programador. Pero la realidad es bien distinta, no es suficiente con conocer a fondo el lenguaje que nos servirá de herramienta de trabajo en la vida laboral, sino que entra en juego otros conceptos muy importantes. La metodología de desarrollo cobra gran importancia en proyectos empresariales, no utilizarla adecuadamente puede desembocar en la frustración del equipo de desarollo y en la insatisfacción de los clientes. Por tanto es necesaria para llevar un mínimo control del ciclo de vida de un proyecto. Aspectos como el análisis, diseño, prototipado, implementación, pruebas, instalación, soporte y monitorización son tareas para las que el equipo de desarrollo debe estar preparado. Existe gran variedad de ellas: metodologías ágiles, programación extrema, RUP, Scrum... son muchas las alternativas disponibles y que no siempre hemos de adoptar como doctrina sino como una guía para lograr el éxito en nuestros proyectos.  
 

La metodología de desarrollo elegida necesitará entonces de herramientas de desarrollo adecuadas para llevarla a la práctica. En este ámbito encontramos variedad de ellas, desde herramientas potentes y de código abierto y basadas en software libre, como el renovado proyecto Maven 2 de Apache, o si vamos más allá con herramientas de integración continua como Cruise Control, hasta herramientas profesionales como la plataforma Rational de IBM, compuesta por su Requisite Pro, ClearCase Software Architect o Build Forge, entre otros, que cubren distintas fases del desarrollo. 

En definitiva, la formación en un lenguaje de programación es sólo una pieza en el puzzle de nuestra larga y esperanzadora vida de desarrollador de software.

Gestión de memoria en Java vs CPython y CRuby

En TSS se plantean una pregunta bastante interesante. Desde la plataforma Java se está haciendo un trabajo muy importante para conseguir que código fuente Python o Ruby ejecutarse en la máquina virtual Java, y el soporte a nivel de lenguaje actualmente es ya muy bueno. Sin embargo, el modelo de gestión de memoria que tienen Python y Ruby difiere considerablemente del que tiene Java. En el primer caso, se basa en malloc y free; en el segundo está bastante poco documentado y no está muy claro.

En cualquiera de los dos casos, un moderno recogedor de basura de cualquier máquina virtual Java realiza muchas más optimizaciones, siendo una potencial ventaja de saltar de la implementación en C a la implementación en Java. Sin embargo, el contar con diferentes modelos de memoria podría causar que programas escritos en Python o Ruby no funcionen correctamente en la máquina virtual Java, o bien porque los desarrolladores del porte han fallado al crear alguna de las abstracciones que permiten la ejecución de esos códigos en la máquina virtual, o incluso porque los códigos originales para funcionar correctamente dependían de funcionalidad no documentada de la implementación en C.

Garantizar la corrección de un modelo de memoria es algo absolutamente no trivial. Recordemos que el modelo de memoria de Java básicamente estuvo "roto" hasta Java 5.

La pregunta que se plantean en TSS es ¿habéis visto problemas al ejecutar códigos Python o Ruby en la máquina virtual Java por causa de las diferencias en el modelo de memoria?

Menos Java, más VM

Hola, buenas tardes.

En la sección de blogs que está en la columna derecha de javaHispano he visto un enlace a una reflexión que me ha parecido interesante: ¿Por qué no incluir Groovy en el JDK? Básicamente, como podéis ver vosotros, el texto, que es breve, dice: A raíz del proceso que se está siguiendo para decidir qué implementación de Closures se integra en Java (el lenguaje), que básicamente como podéis comprobar es una encuesta -lo que a mí me parece de todo menos serio-, Geertjan Wielenga se pregunta si no sería mejor incluir directamente Groovy en la plataforma, hacerlo convivir con Java dentro del JRE/JDK e implementar con él las nuevas funcionalidades, que no siempre tienen una forma sencilla de integrarse con Java. Dadas las virtudes de Groovy como lenguaje de scripting para la plataforma Java, "¿por qué no incluírlo en la plataforma? ¿por qué seguir forzando Java para incluír funcionalidades como los closures, que Groovy ya incorpora?"

A esto yo añado una idea que bien es cierto que se asemeja a .NET. Pero, existiendo Groovy y, como hace poco supimos, teniendo SUN en mente la idea de la máquina virtual DaVinci ¿por qué no distribuir la máquina virtual junto con el soporte a dos o tres lenguajes que sean lo suficientemente distintos como para aportar algo propio cada uno de ellos para el desarrollo de aplicaciones? la máquina DaVinci, Java, Groovy y Scala, por poner un ejemplo. Y dejar ya de modificar Java. En todo caso arreglar la genericidad si es posible -siempre lo diré-, utilizar las anotaciones para añadir algún mecanismo de diseño por contrato de modo que sea optativo para quien lo quiera usar -de hecho ya existe algo así casi completamente implementado y se llama Contract4J-, mejorar la integración de Java con el escritorio y con el mundo multimedia, simplificar JavaEE, etc. Me parece que hay suficientes tareas pendientes como para no dedicar tiempo a seguir modificando Java.

Un saludo.

JavaSE Update 10 Beta

Buenos días.

Acabo de ver en el sitio web de Sun que han publicado la versión beta de la décima actualización de Java SE 6. Al parecer, esta versión incluye el famoso Java Kernel, mejor soporte para Windows Vista, soporte para la aceleración por hardware, mejora del rendimiento y un nuevo aspecto y sensación llamado Nimbus, entre otras características interesantes. Es una noticia digna de celebrarse aunque hay algo que no entiendo. Si la versión actual que se puede descargar es la actualización sexta de Java SE 6, ¿es que piensan sacar otras tres actualizaciones menores antes de que esté definitivamente lista esta ansiada actualización?

Saludos cordiales,

José María

JBuilder 2008

Code Gear ha anunciado la segunda versión de JBuilder desarrollada sobre Eclipse: JBuilder 2008. Las principales novedades son una actualización de los servidores de aplicaciones que soporta, la inclusión de un profiler (antes la compañía ya lo tenía, pero ahora viene incluido con el IDE), mejoras en el análisis estático y métricas del código y mejoras en el soporte para colaboración.

Yo todavía no le he echado un vistazo (aunque lo haré); si miré en su día la primera versión del antiguo entorno de borla construida sobre Eclipse (JBuilder 2007) y no me convenció en absoluto.

¿Cuántos usuarios de JBuilder hay por aquí?