[Spanish] presentacion

Jorge Gaspar Sanz Salinas jsanz at prodevelop.es
Tue Mar 20 05:11:01 EDT 2007


Francisco Palm escribió:
> El 17/03/07, Sabrina Pompei <sabrinapompei en gmail.com> escribió:
>> java , C, que sugieren para aplicaciones SIG. Nuestra realidad es que 
>> solo
>> contamos con gente con experiencia en java, lo cual no quita que sea el
>> momento de incursionar en otro lenguaje.
> 
> Java es una tecnología sobredimensionada e innecesariamente
> complicada. Diseñada para cumplir eficientemente los requerimientos de
> las corporaciones sin considerar el punto de vista de los
> programadores (que dentro del ciclo de producción de software son
> vistos como simples herramientas).
> 
> El tema no es: ¿De cuántos expertos en informáticas disponemos?
> 
> Es sabido que en cualquier país del mundo el deficit de personal
> calificado en informática es bastante alto. Juntar algunos
> programadores para desarrollar aplicaciones como gvSIG es plausible.
> Pero, constituir comunidades de usuarios muy amplias que puedan
> participar en profundidad en el diseño y desarrollo de soluciones
> específicas, eso NO es posible bajo el modelo actual. NO es posible
> con Java, simplemente para las corporaciones esto del empoderamiento
> de la gente no es sino una molestia.
> 
> ¿Quieres que un Geográfo (o Sociólogo, o Abogado, o Politólogo, etc.)
> aprenda a programar?, en Java le tomará -años-, en Python le tomará
> -meses-. Además, está comprobado que Python permite desarrollar
> proyectos 5 o más veces más rápido.
> 
> Es obvio, con Java (o .Net) se crean élites superespecializadas que
> monopolizan la tecnología (y por ende los negocios relacionados con la
> tecnología), Con Python (u otros lenguajes similares como Ruby)
> podemos tener comunidades muy amplias de ciudadanos empoderados que
> pueden participar en el desarrollo de la tecnología.
> 
> El problema es que generalmente se toman las decisiones en función de
> un proyecto puntual, se escoge una tecnología por las circunstancias
> del momento, sin considerar aspectos socioeconómicos a mediano y largo
> plazo. Y de esa manera se sacrifica el futuro.
> 
> Saludos
> 
> F. Palm
> _______________________________________________
> Spanish mailing list
> Spanish en lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/spanish
> 

Hola Francisco,

No soy informático, sino cartógrafo, así que tal vez mi opinión no sea 
tal vez muy válida. Hablo desde la experiencia de alguien que ha 
aprendido a programar casi de forma autodidacta (al menos la 
programación orientada a objetos).

A mi Java no me parece tan complicado. La API está tremendamente bien 
documentada (es una pasada ver el código de las clases, cómo está 
documentado cada método, etc.). Tal vez lo más complicado es aprender 
cada API que necesitamos para trabajar, ¡pero es que hacemos cosas 
complejas! Acceso a bases de datos, logging, parseo de documentos XML 
por no entrar en APIs del mundo de la geomática como GeoTools o gvSIG.

A mi Python siempre me pareció un buen lenguaje para scripting o para 
hacer pruebas en prototipos, algoritmos, etc.

Pero, como dice Eduard, cuando uno quiere crear una arquitectura tan 
compleja como un cliente pesado del tamaño de gvSIG, uDig, etc., y que 
además sea MODULAR, es necesario un lenguaje que soporte todas las 
características de la programación orientada a objetos, hasta las clases 
abstractas.

Desde fuera, a mi me da más "miedo" meterme con GRASS que con uDig, por 
hablar de dos proyectos de los que no he visto ni una línea de código 
fuente.

En cuanto a "la trampa de Java", parece que ya se ha acabado con eso. 
Por varias razones:
*Desde hace tiempo hay varios proyectos alternativos al de Sun para 
implemetar una máquina virtual: gcj, classpath, etc.
*Por lo visto, Sun va a liberar la máquina virtual bajo la GPL 3.

No sé, no es por avivar una flame war, pero decir que Java es para 
entornos profesionales y que el resto están más cómodos en C++/Python... 
es un poco exagerado.

(Otra cosa es que la especificación J2EE sea un infierno :P, pero métete 
tú en C++ a hacer un servidor de mapas que funcione en clusters y que se 
acerque a Geoserver...)

Este es el tipo de discusiones que espero ver en esta lista (SL, 
alternativas técnológicas, etc.).
-- 
Un saludo

Jorge Gaspar Sanz Salinas
Ingeniero en Geodesia y Cartografía
Prodevelop S.L. - Valencia - España
Tlf.:  96.351.06.12 - Fax:   96.351.09.68
jsanz[en]prodevelop[punto]es
http://www.prodevelop.es


More information about the Spanish mailing list