Gracias
IVM

What would you think if #microsoft invented TypeRuby to fix #ruby lack of static type checking? #typescript #javascript—
Enrique Amodeo Rubio (@eamodeorubio) October 27, 2012

“no he visto nunca a nadie decir que “en Ruby no se pueden mantener grandes bases de código porque no tiene tipado estático””

Probablemente porque un significativo porcentaje del “alguien” sólo haya programado en Ruby y porque la inmensa mayoría de los proyectos grandes son Java o C# o C++.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

(ojo tampoco hay que considerar Tiobe como una religión)

La frase “no puedes mantenerlo” es de Anders Hejlsberg no mia, yo soy de los que opina más bien, que sí puedes mantenerlo… pero muy malamente, con un esfuerzo inmenso y con una enorme disciplina de codificación para compensar la ausencia de gestores de código estático.

A mi la detección de errores por el tipado estático me importa poco aunque importa, a mi interesa infinitamente más:

1) La expresividad: soy un perro, soy un gato, soy comida de perro

La expresividad es impagable cuando la cosa se complica más y más y más y más aun si heredas código de otro.

2) Gestión de código: es decir control, control y control. El llamar a References (Eclipse) o Find Usages y mostrarte en 1 segundo todas las dependencias es impagable, el introducir un cambio en ese método y ser capaz en cascada de resolver decenas de implicaciones sin problema, en minutos, con seguridad, con fiabilidad… es impagable. Sin tener que ejecutar cientos de tests y a cada error introducir el cambio y otra vez ejecutar cientos de tests para detectar otro error y otro nuevo cambio etc, y si no tienes esos tests directamente estás muerto.

Otro tema es el de lenguajes de tipado estático contra los de tipado dinámico. Eso merece otro post. Resulta que JS es de tipado dinámico, y claro, a los que les gusta el tipado estático lo ven como un problema. Lamentablemente sólo encuentro que se esgrime este argumento contra JS, no he visto nunca a nadie decir que “en Ruby no se pueden mantener grandes bases de código porque no tiene tipado estático”. No veo a nadie escribir transpiladores de lenguajes estáticos a Ruby, ni TypeRuby ni nada similar, ¿por qué?

Ya sabes que pienso que haciendo TDD no necesitas que un compilador te detecte errores de tipado estático, ya que TDD detecta éstos y encima detecta bastantes errores “semánticos” (si defines bien tus tests, claro), cosa que ningún compilador hace.

Mi opinión es que los lenguajes de tipado estático son muy beneficiosos para los fabricantes de herramientas de desarrollo de software y de máquinas virtuales: Microsoft, IBM, etc. ¿Para quién trabaja el inventor de TypeScript? ¿Y el de Dart?

Finalmente: “millones de lineas de código” Si tienes una aplicación con millones de lineas de código, seguramente esta sea tan inmantenible como Windows. Las aplicaciones mantenibles no tienen millones de lineas de código. Es más, dime algún sistema con millones de lineas de código que sea mantenible, aunque esté hecho en Haskell, JAVA, C#, Clojure o Scala. Seguro que no encuentras ninguna.

JavaScript es un lenguaje que fue concebido para validar formularios y algunos efectillos DHTML y que se mueve en un entorno anémico, la tendencia actual a programar a saco en JavaScript el navegador que no digo que esté mal, tiene mucho sentido común, el problema es la “herramienta” que con el tiempo va a dar en mi opinión muchos disgustos a algunos.

Como dice Anders Hejlsberg el padre de Typescript

http://en.wikipedia.org/wiki/Anders_Hejlsberg

“No, you can write large programs in JavaScript. You just can’t maintain them.”

http://css.dzone.com/articles/you-can-write-large-programs

El que todo el mundo esté haciendo lenguajes alternativos a JavaScript algunos de ellos ESTATICAMENTE TIPADOS y con orientación a objetos completa como Typescript y Dart, no la cosa rara que tenemos habitualmente que hacer para que no sea un todo un spagetti-function, pues es un signo de todo esto. Por no hablar que los futuros estándares de JavaScript empiezan a ser otra cosa.

Ahora bien estoy de acuerdo con lo de la pereza, la pereza NO debería ser la excusa, si merece la pena la tecnología X de turno, si convence… ¡¡pues a saco!!

Como opinión puramente personal, pienso que es mejor aprender las tecnologías y estándares web, para poder trabajar con ellas, que estar anclado en JAVA y depender de cosas como GWT. Pero otras personas pueden tener otros gustos y opiniones, claro.

Salud !

GWT esta centrado 100% en cliente y te permite compartir clases java entre cliente y servidor de forma totalmente transparente. Esto lo diferencia a otras herramientas como JSF, ZK, Eclipse RAP o vaadin (vaadin utiliza GWT para renderizar la parte cliente ) que se basan en la gestión de eventos en el servidor.

Se puede integrar el sistema de logging estándar de java, la validación de JPA, Excepciones y otras características que facilitan la vida a cualquier desarrollador Java.

Es muy sencillo integrar una maquetacion html tradicional utilizando uibinder o incluso el nuevo framework de twitter bootstrap. Aunque también te permite desarrollar la interfaz de usuario utilizando la forma tradicional de las aplicaciones de escritorio basada en paneles y widgets.

Ademas integra una implementacion del patrón MVP + un eventbus que te proporciona una base muy potente para el desarrollo de aplicaciones grandes.

El único inconveniente que tiene GWT es el tiempo de compilación final para obtener el código javascript, el equipo de GWT esta trabajando en ello, aunque tampoco es mucho problema si se utiliza un sistema de integración continua que realice ese trabajo final de compilación y despliegue.

Saludos.