Recomendación

alguna herramienta que me pueda servir

Pues sólo se me ocurre... un cerebro... y al final sería deseable el aparatito ese de Men in Black para borrar de tu memoria todo vestigio de la horrible experiencia que te espera.

Herramientas para generar diagramas a partir de código y cosas pues así pues solamente se me ocurren las de Rational pero no creo que jalen con VB, son principalmente para Java y creo que .NET (pero ps quién sabe capaz y tienen por ahí un módulo adicional). Cuestan UN VARO y medio. Cuando veas el costo tal vez concluyas que es más barato contratar dos o tres pobres diablos conocedores de VB que lean todo el código y te puedan documentar el sistema a partir de eso.

Por otra parte, no quisiera ver los diagramas que un sistema de análisis de código pudiera generar... el horror... el horror...

Tienes razon ni modo de generar una herramienta especificamente para VB la situacion es que este sistema lo ocupan constantemente pero como solicitan una que otra modificacion luego no saben por donde modificarle y lo peor es que cuando le modifican despues resulta que eso afecta a otras funciones del sistema.

aunque leyendo tu comentario voy a tomar en cuenta la parte donde dices que ponga gente que sepa visual y que de ahi genere la documentacion, estuve leyendo y creo diagramas de casos de usos seria bueno. para ahorrarme el horror como dices tu de generar toda la Documentacion.

tienes alguna idea de que otro diagrama puedo usar si no fuera casos de uso.

Lo que te recomiendo es primero saber/entender que hace y como trabaja el sistema a nivel usuario y analizar la base de datos. Despues puedes hacer el manual del usuario o los casos de uso y si es necesario rehacer la base de datos implementado buenas practicas. A veces con esa informacion es mas facil crear una aplicacion nueva que estar tratando de entender lo que hizo otra persona, ademas de que ya existen frameworks que te ahorran muchas lineas de codigo.

Primero que nada... para qué es la documentación? La quieres para usuario final, o sea un manual de cómo usar el software? O quieres documentación técnica, a manera de mapa para ubicar los componentes de la aplicación y saber dónde mover algo cuando piden modificaciones?

Si es documentación técnica, para poderle mover en el futuro, entonces pues pensando en UML los casos de uso son muy útiles. Te diría que los diagramas de componentes pero pues luego ni componentes hay en VB. Los de secuencia y de estado podrían ser de los más útiles.

Y algo importantísimo es que el código mismo tenga comentarios apropiados, en cada método/función/clase/rutina/etc (cada unidad de programación, para vernos más agnósticos de lenguaje). Y dentro de cada unidad de programación, el código que contenga debe tener también comentarios. Eso es para que una vez que sepas por dónde tienes que empezar a hacer una modificación y te metas al código, sepas dentro de ese código qué parte modificar.

Y pues tal vez sea muy idealista porque siendo VB es casi seguro que no hay facilidad alguna para pruebas, pero lo mejor sería que antes de modificar cualquier cosa, se pongan a crear un montón de pruebas unitarias y de integración para ese software. Toda una batería lo más completa posible; eso les puede ayudar muchísimo a comprender cómo funciona el software, porque tienes identificar las unidades que vas a probar (funciones por ejemplo, o métodos si es que usan OOP) y hacer una o preferentemente varias pruebas para cada unidad. Y además algunas pruebas de integración, donde pruebas varias unidades en secuencia esperando encontrar cierto resultado.

Al principio estas pruebas serán hechas sin tocar el código, solamente haces las pruebas y deben de pasar (las que deban de pasar) o tronar (las que deban de tronar). Esto te servirá mucho para que luego cuando empieces a modificar el código, modifiques las pruebas de lo que vas a cambiar (o hagas pruebas nuevas si es que agregas funcionalidad), y corras de nuevo TODA la batería de pruebas; lo que no hayas movido debe seguir pasando sus pruebas (o debe seguir tronando si es que la prueba era que tronara); eso se llaman pruebas de regresión.

...Cuando veas el costo tal vez concluyas que es más barato contratar dos o tres pobres diablos conocedores de VB que lean todo el código y te puedan documentar el sistema a partir de eso.

@ezamudio
ja ja
Te pasaste yo antes usaba VB para todo , no en serio tienes razón desde que supe que existia Java abandone el barco de VB y ahora soy feliz.

Y después dicen que yo soy el sarcástico.

beto.bateria tiene razón. Pensando más en el "big picture", no es muy recomendable estar modificando aplicaciones en VB porque ya es una tecnología descontinuada, incluso el proveedor ya le dio su End of Life. La situación actual es que las apps hechas en VB6 seguirán corriendo hasta Windows 7, pero ya no correrán en la siguiente versión de Windows (que podría llamarse Windows 8 o Windows [SomeOtherStupidName], no sabemos).

Puede ser una buena oportunidad para reescribir la aplicación, usando algo más actual. Sin embargo, para poder reescribirla necesitas entender qué hace y para eso necesitarás la documentación. En este caso todo lo que dije de las pruebas ya no aplica (para la app existente), te servirían más los diagramas de estado y de secuencia, y documentar MUY bien la base de datos. Si usa SQL Server o algo así, entonces sí hay varias herramientas que te generan el diagrama E-R pero pues falta saber para qué es cada tabla, cada relación, cada stored procedure, y aprovechar si se pueden identificar columnas o tablas obsoletas para no migrarlas, si es que se cambia también la BD, aunque idealmente pues deberían poder seguir usando la misma, incluso así pueden hacer deployment de la nueva app en paralelo con la existente.

Opciones para reemplazar una app VB: Pues una en .NET con Winforms, o en Griffon (no usaría Java+Swing así pelón, qué dolor de cabeza)... tendrían que analizar si se presta para migrarla a web...

lo que deseo es hacer un documentación técnica para que cuando sea necesario que hagan modificaciones entiendan donde esta cada cosa.

es importante también mencionar que esto lo haré porque como les comente este sistema es muy usado aunque ya sea viejo y todo lo que quieran y algún día de tantas modificaciones al aire que se le están haciendo se va a perder la secuencia y el código sera muy inestable.

respecto a lo que comenta ezaumudio haré las pruebas que me dice.

@beto.bateria tienes razón en volver a hacer la base de datos pero si ya es una versión en VB y es una aplicación viejita por así decirlo lo mejor seria solo hacer una buena documentación técnica.

@beto.bateria tienes razón en volver a hacer la base de datos pero si ya es una versión en VB y es una aplicación viejita por así decirlo lo mejor seria solo hacer una buena documentación técnica.

No entendi que quieres expresar.

¿Hacer documentacion tecnica de la app en VB?, ¿o de la nueva que piensas hacer?.

Una observacion (no se tu experiencia como programador), pero una aplicacion que tiene una buena arquitectura e implementa buenas practicas la documentacion se reduce mucho.

Si piensas hacer la documentacion tecnica de la app en vb, no creo que valga la pena.

Un consejo, divide la aplicacion vb en modulos (te los podrias imaginar), considerando que cada modulo debe de aportar alguna funcionalidad al negocio, platica con tu jefe o el administrador para asignarle a cada modulo un nivel de importancia, y despues ve creando esos modulos dependiendo de la importancia asignada.

Un modulo podria ser, crear facturas o manejo de almacen, etc.

Suerte.

@beto.bateria
Seria mas bien una documentación del APP que esta echa en VB, y efectivamente la aplicación esta dividida en módulos, planteare de nuevo mi idea.

lo que quiero es generar la documentación Técnica, para que cuando se tenga que hacer alguna modificación no tengamos muchos problemas con ello.

por eso pedo opinión a ustedes que tienen mas experiencia, para saber sí existe alguna herramienta que me facilite este proceso.

pero de que tengo que hacer la documentación la tengo que hacer.

@ ezaumudio, hablando de cambiar la aplicación a algo mas actual considerando que ya este hecho le código y solo tendría que reescribirlo, estaba yo pensando en Java+ Swing pero veo que no estas muy convencido, sinceramente no es una aplicación que tenga salida a internet entonces algo que sea de escritorio no caería nada mal.

Que me podrías aconsejar.

Metiendo mi cuchara, podria aconsejarte gwt, estoy aprendiendo a manejarlo y me parece una buena tecnologia.

Voto 2 por Gwt.... aunque sea un voto bastante subjetivo...

Echale un ojo a Griffon. Es una plataforma para hacer apps en Swing, usando una arquitectura muy similar a la de Grails. Es programación en Groovy, puedes utilizar bibliotecas y frameworks de Java, implementa MVC, etc.

Todo Sobre Netbeans ???? y que base de datos estas ocupando

Si ocupo Griffon tengo que darle salida a internet o lo puedo usar tipo aplicacion de escritorio !!!!

Griffon es para aplicaciones de escritorio. Te puse la liga al sitio oficial para que puedas leer ahí toda la info que necesites. Durante el desarrollo obviamente necesitas acceso a internet, por lo de las dependencias y demás (se manejan con Maven y con Ivy, como en Grails). Pero una vez que tienes la aplicación hecha, puede funcionar sin internet, se conecta directamente a una base de datos.

Base de datos ocupo MYSQL ?????
o cual seria la ideal !!!!

Depende lo que necesites. A mi no me gusta MySQL pero es algo muy personal, cuestión de gustos podría decirse. Mi favorita es PostgreSQL. Pero ps ya es cuestión de gustos, supongo... a mi parecer PostgreSQL es muy superior a MySQL, alguien podría argumentar que PostgreSQL puede ser "demasiado" para tus necesidades, pero pues esos argumentos creo que son válidos cuando el software cuesta, es decir si tuvieras que decidir entre MS SQL Server y Oracle, tienes que pensarle muy bien en tus necesidades presentes y futuras, porque la diferencia de precio es muy grande. Pero si MySQL y PostgreSQL te cuestan lo mismo... cuál es la bronca? Además la licencia de PostgreSQL me gusta más, porque te permite usarlo con software comercial, mientras que MySQL tiene una licencia doble: si lo usas con software libre (es decir tu aplicación es de software libre) entonces lo puedes gratis con la licencia de software libre que tienen, pero si lo quieres para una aplicación comercial (o de software propietario como es tu caso), tienes que pagar una licencia comercial.

Sé que NADIE hace esto último, es muy triste, pero pues así es: si usas MySQL en software propietario, deberías pagar la licencia comercial.

@beto.bateria no encuentro mucho sobre gwt, podrías pasarme un link.

Pon en google "wow ebook", entre los links hay un sitio en donde puedes bajar ebook, en el buscador del sitio pon gwt y busca en los resultados.
Suerte.

La pagina oficial generalmente es un buen punto de partida.

ya verifique la pagina oficial y descargue un libro para tenerlo como Referencia, tengo una duda que tan estable es para conexiones a bases de datos.

y de esta tecnología hay suficiente soporte ???? y se podrá conectar con SQL Server.

Si existe un conector JDBC para la base de datos que utilizas se va a poder. SQLServer tiene un JDBC, asi que si se puede.

hasta donde sé, GWT es un framework para las capas de vista y control, no tiene nada de bases de datos. Pero sea cual sea el framework que uses en Java, la respuesta de "se puede conectar a X base de datos?" siempre la respuesta es: sí se puede conectar, siempre y cuando tengas el driver JDBC para tu DBMS.

En cuanto a soporte: Si no te has dado cuenta todavía, la G de GWT significa Google, ellos mismos usan ese framework para desarrollar muchas de sus apps web (gmail, G+, etc). Además es open source y ya hay bastante gente usándolo (programadores, es decir), por lo que si Google decidiera hoy en la tarde anunciar que ya no lo van a soportar, se puede hacer un fork y probablemente surgirá una comunidad que lo mantenga.

Exacto, GWT es para la vista. Permite desarrollar interfaces con Ajax sin tener que escribir código JavaScript. Todo se escribe en java y el compilador generá código JavaScript.

Por cierto, Gmail no esta desarrollado en GWT y me parece que G+ tampoco,

Saludos!

Orale, yo pensaba que ellos consumían su propia droga, es decir, que GMail ( y seguramente más aplicaciones ) estaban hechas con GWT ... he vivido engañado .... OOOOHHH PORQUEEEEEE .... bueno ya ...

Sólo como complemento, por allá por los tiempos de GWT 1.5 había una cosa que se llama gwt-simple-persistence, o algo así, digo, nunca lo usé, pero pues igual puedes buscarlo,a ver si sobrevivió ése proyecto, actualmente,GWT lo uso mucho con JPA/Hibernate o el soporte de Spring para JDBC...
Para que aprendas sobre ejemplos, chécate el showcase de GWT aquí el link vienen componentes, CSS y el fuente en Java
Nos cuentas como te va con tu aprendizaje, suerte!

Si me había dado cuenta de la G de GWT, lo que pasa es que en un principio como no lo conocía esta confundido pero ahora veo que de soporte hay mucho. ahora retomando lo que en un principio quiero hacer es cambiar una aplicación que tenemos donde trabajo a una nueva opción,.

Es por eso que yo les preguntaba que podemos utilizar para experimentar, pero para nosotros es importante que se pueda conectar con bases de datos. es decir que nos permita crear nuestro formulario y guardar nuestros registros en una base de datos.

y la situación es que estábamos analizando si usar Swing o que otra mas se puede y por eso decidimos preguntarle a los expertos.

Ahora ya me puse manos a la obra en leer sobre GWT y veo que se puede conectar con bases de datos, también que se utiliza con tomcat aqui me gustaria que alguien me dijera si esto es correcto y veo puedes incrustar algun codigo html.

En lo que he estado leyendo al parecer Netbeans es muy buen IDE para desarrollar esta tecnología, lo primero que haré es un pequeño formulario para ver como trabaja, porque tambien me estaban recomendando Csharp pero no estoy muy seguro siento que es mejor java por mi experiencia.

Yo ya te había recomendado Griffon pero supongo que ni a la página entraste. Por los comentarios que has hecho, me da la impresión que están apenas adentrándose en el mundo de Java, por lo que yo pienso que es muy buen momento para que usen algo como Griffon. Por qué? Pues porque las razones por las que los javeros se resisten a usar frameworks de este tipo siempre van por el tipo de "es que no sé Groovy" y "es que ya tengo mucha experiencia en Swing". Si no tienes experiencia en Swing, o no sabes mucho Java, pues hasta te conviene más usar Griffon, porque Groovy es más sencillo de Java y el desarrollo de aplicaciones es mucho más sencillo que con Swing pelón.

Ahora ya me puse manos a la obra en leer sobre GWT y veo que se puede conectar con bases de datos, también que se utiliza con tomcat aqui me gustaria que alguien me dijera si esto es correcto y veo puedes incrustar algun codigo html.

GWT tiene componentes para que contruyas fragmentos de HTML, pero su gracia consiste precisamente en crearte formas de JavaScript, completas, sin necesidad de usar tags de HTML, en todo caso, mejor aprende HTML y algún framework de Javascript.

Por otra parte apoyo lo que dice @ezamudio, Groovy es más relajado que Java, y para aplicaciones con Swing, supongo que debe ser muy buena alternativa, pero pues a fin de cuentas, tú eliges con qué quieres castigarte
Suerte!

Hace tiempo en otro foro puse un ejemplo de Swing en Groovy vs. Java, y eso es con Groovy solito, sin Griffon. Griffon lo que agrega es la separación de modelo-vista-controlador, acceso a la base de datos, plugins, y algunas monerías para Swing que no se pueden con Groovy solo y que no he visto en ningún otro framework, como por ejemplo aplicar estilos CSS a componentes Swing...

Si leí la documentación, lo que pasa es que tienes toda la razón apenas estoy adentrándome en el mundo de java pero en el mundo de los frameworks y otras cosas bastante interesantes y sinceramente no es tan fácil, aunque quizá ya con experiencia las cosas sean mas fácil .

Lo que si te puedo asegurar es que tenemos la intención de aprender nuevas tecnologías y lógicamente aplicarlas.

La verdad yo no le veo caso aprender a manejar librerias para hacer aplicaciones desktop (exepciones como un inkscape, gimp o similares), el futuro ya nos llego, y este futuro es el web y los dispositivos moviles.

@beto Ya no leí el resto del hilo, pero sobre tu comentario te diré que el futuro llegó nos rebasó y ya va de vuelta al escritorio eh. Obvio no de la misma forma que en 1985. No sé si le llamarán Web2.1 o 3.0 o que cosa, pero va a pasar.

Permíteme hacer un comentario al respecto, si dices que ya no es indispensable aprender a hacer aplicaciones para Desktop.
-En sucursales bancarias, se manejan aplicaciones de escritorio.
-En aplicaciones para cobro de productos, se manejan aplicaciones de escritorio.
-En terminales de cajeros de servicios diversos, llámese autoservicios, terminales de autobuses, se manejan aplicaciones de escritorio.
-En aplicaciones para call center, se manejan aplicaciones de escritorio.
-En aplicaciones para chequeo de inventarios, se manejan aplicaciones de escritorio.

Me pregunto entonces, porqué en éste tipo de giros se siguen usando apliaciones de escritorio si el futuro es web?

Demasiado exagerado pero así lo escribió:
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration".
Edger Dijkstra, EWD498

bferro, eso me toco a mi, mi primer experiencia fue con basic, y al menos conmigo se equivoco al mencionar eso Dijkstra, no solo conmigo, sino con otros.

Me pregunto entonces, porqué en éste tipo de giros se siguen usando apliaciones de escritorio si el futuro es web?

neko069
¿No sera porque les cuesta mucho dinero cambiar las aplicaciones?
¿No sera que esos sistemas todavia funcionan perfectamente en el entorno en donde son usados?
Hay muchos motivos por los cuales siguen usando esa tecnologia.

@beto Ya no leí el resto del hilo, pero sobre tu comentario te diré que el futuro llegó nos rebasó y ya va de vuelta al escritorio eh. Obvio no de la misma forma que en 1985. No sé si le llamarán Web2.1 o 3.0 o que cosa, pero va a pasar.

OscarRyz de acuerdo contigo, y agregando:
Al ver Flex, JavaFX, GWT, y similares, creo que la tendencia es crear tecnologia que funcione y tenga el mismo comportamiento tanto en web como en el escritorio, pero estoy seguro que la plataforma va a ser el web, mientras inventan otra.

WebOS es un sistema operativo que implementa una buena idea acerca de ese presente, puedes crear aplicaciones con javascript, html, y css.

La verdad yo no le veo caso aprender a manejar librerias para hacer aplicaciones desktop (exepciones como un inkscape, gimp o similares), el futuro ya nos llego, y este futuro es el web y los dispositivos moviles.

El futuro? Mas bien el pasado, el modo de programar en web es obsoleto desde que se invento, HTML5 lo unico que "tan grandioso" que hace es traer una micro muestra de capacidades que siempre estuvieron el desktop al web.

Y los dispositivos moviles? El Iphone se programa con un SDK que si lo miras con cuidado, esta inspirado en Cocoa (el SDK para escritorio en las Macs), asi que mas de lo mismo: los mobiles atrayendo capacidades que siempre estuvieron el desktop... claro que si hay inovaciones, como las interfaces tactiles, pero se programan sobre un SDK derivado los creados para desktop.

¿No sera porque les cuesta mucho dinero cambiar las aplicaciones?

No sera que no se justifica migrar una aplicacion a una plataforma mucho mas limitada, como es la Web? (Las formitas de html estan bien para juguetitos como la pantalla de registro de una red social, pero no para sistemas empresariales donde el rey es el teclado y la productividad se mide por el numero de registros capturados)

¿No sera que esos sistemas todavia funcionan perfectamente en el entorno en donde son usados?

Aqui si le diste al clavo, el Web y los moviles no son para todo.

Al ver Flex, JavaFX, GWT, y similares, creo que la tendencia es crear tecnologia que funcione y tenga el mismo comportamiento tanto en web como en el escritorio, pero estoy seguro que la plataforma va a ser el web, mientras inventan otra.

Desgraciadamente, es muy probable que tengas razon, al los humanos nos encanta reinventar la rueda...

WebOS es un sistema operativo que implementa una buena idea acerca de ese presente, puedes crear aplicaciones con javascript, html, y css

Javascript, html, y css... Tecnologias tan primitivas comparadas con Flex, Silverlight, JavaFX o WPF que no se si reir... o llorar... pero coincido en que es muy probable que haya que esperar hasta que HTML7 o HTML8 tenga todas estas caracteristicas para dejar de sufrir...

Hace mucho leí ese comentario de Dijkstra y me puse a pensar... wow, si no hubiera usado BASIC nunca, ahorita sería un programador fenomenal... o no sería programador tal vez, porque lo único que tenía a mi disposición eran BASIC y Logo, pero con Logo solamente podía hacer dibujitos y con BASIC pude hacer procesadores de palabra, jueguillos muy primitivos, sonidos y todo tipo de monerías para entretenerme y algunas cosas que me sirvieron para la escuela.

Y lo de haber aprendido Logo primero no me salva de su comentario de tener daño cerebral, porque simplemente habla de los que hayan tenido conocimiento previo de BASIC, no que hayan aprendido a programar en BASIC.

Ya en serio, esos comentarios hay que tomarlos siempre con un grano de sal. Los fans de una tecnología siempre hablan mal de los fans de otras tecnologías; los programadores que favorecen un lenguaje hablan mal de los que favorecen otro, o los que favorecen un tipo de lenguaje hablan mal de los que favorecen otro tipo. Lo hacemos todos los días y no pasa nada; el problema es cuando alguien se vuelve famoso (como Dijkstra o Torvalds) y entonces la gente tiende a citarlos a veces fuera de contexto por el fenómeno del "teléfono descompuesto" que se sigue dando (hoy más rápido que nunca) y a veces con intenciones distintas a las del autor, o a veces dicen cosas simplemente como si estuvieran tomando una chela en un bar con alguien y pudieran decir algo en confianza pero no se fijan en que ya son figuras públicas y están en una conferencia y todo mundo está super atento a cada palabra que dicen.

Un ejemplo muy claro para mí es Torvalds cuando se la pasa diciendo que los que usamos Subversion somos unos retrasados mentales y los que usamos CVS ya casi casi ni siquiera calificamos como humanos. La neta es git y si no lo usas eres un pobre estúpido. Todo esto sin tomar en cuenta que muchos usamos CVS porque no había otra cosa, y que usamos SVN después porque era la siguiente mejor opción, porque todavía no existía git. Y sí, tal vez no todos tenemos su gran capacidad intelectual (tal vez porque alguna vez programamos en BASIC), para que en vez de usar SVN porque es lo que hay, dedicarle "un tiempito" a hacer un mejor SCM y crear git.

Sé que lo dice (parcialmente) en broma, pero la cosa es que ya es una figura pública y debería cuidar un poco más lo que dice; el problema es que particularmente en el campo de la programación, habemos muchos que tenemos el tacto de un puercoespín a la hora de hablar en público.

Pues yo sigo con la idea de que programación web de ninguna forma es para todo.
Los 2 ejemplos más representativos que se me vienen a la cabeza, el sistema de ventas de grupo ADO en la terminal de autobuses de oriente.
Administrador de campañas para Coca Cola Femsa.

El proyecto más viejo (relativamente) es el grupo ADO, por allá del 2006, si mal no recuerdo.
El proyecto de Coca Cola Femsa, es de principios de éste año (2011).

Tuve la oportunidad de participar en el segundo, y bueno, si se hubiera hecho en web, de ninguna forma hubiera quedado, porqué?, bueno, porque se tenía que integrar con un sistema SAP, y con una plataforma propietaria de CISCO, había por ahí que hacer simulaciones de click de ratón y posicionamiento de ventanas, que definitivamente NO se hubieran podido hacer vía web.

No hay aferrarse a que web es el futuro o que web es para todo , @luxspes ya hizo una buena retroalimentación del tema, y por su experiencia le tengo mucho respeto en cuanto a sus opiniones, y por mi experiencia también me doy cuenta, que una aplicación web como las conocemos hasta el día de hoy, nada más no le llegan a las Desktop, en lo personal no he probado la capacidad de HTML 5, cuando lo haga, ya veré si mi opinión al respecto cambia.

Te volaste la cerca y por el center field (en términos beisboleros) al decir que "el modo de programar en web es obosleto desde que se inventó" y otras cosas que comentas. Ese modelo de programación con esas "formitas" que mencionas le dio y le sigue dando vida a un chorro de aplicaciones útiles que han resuelto un millar de cosas.
Lo obsoleto se mide con el tiempo. Cuando algo se inventa o se descubre, el futuro de ese algo es un misterio. Es como si alguien afirmara que la mecánica clásica gracias a la genialidad de Newton (la mente más prodigiosa de la especie humana) era obsoleta desde que se inventó, porque después vinieron otros grandes genios y demostraron que en el mundo de las partículas tales leyes no eran ciertas.
El Web no se inventa con el propósito de usarlo como la infraestructura para el desarrollo de aplicaciones distirbuidas; se inventa con otro objetivo. A pesar de eso, ha podido ser usado para desarrollar aplicaciones en extremo complejas que todos conocemos.

Que buena controversia se ha generado entre la Comunidad, lo importante pienso yo es que a nosotros nos funcione lo que usamos
siempre aceptando la critica y apoyando a quienes nos lo pida.

Te volaste la cerca y por el center field (en términos beisboleros) al decir que "el modo de programar en web es obosleto desde que se inventó" y otras cosas que comentas.

Por fin estamos otra ves en desacuerdo... creo... ;-)

Ese modelo de programación con esas "formitas" que mencionas le dio y le sigue dando vida a un chorro de aplicaciones útiles que han resuelto un millar de cosas.

Si yo viajo hoy a Merida en caballo, estoy usando un medio obsoleto de transporte, no importa que antes miles de viajes se resolvieran a caballo. Que el caballos fuera alguna vez el mejor medio de transporte no hace que no sea obsoleto hoy en día. (Por supuesto, depende del objetivo, si el objetivo es un medio ecológico de transporte, el caballo supera a cualquier invento humano, si el objetivo es llegar a Merida (desde el DF) en cuestión de horas, el caballo es obsoleto comparado con un avión)

Lo obsoleto se mide con el tiempo. Cuando algo se inventa o se descubre, el futuro de ese algo es un misterio. Es como si alguien afirmara que la mecánica clásica gracias a la genialidad de Newton (la mente más prodigiosa de la especie humana) era obsoleta desde que se inventó, porque después vinieron otros grandes genios y demostraron que en el mundo de las partículas tales leyes no eran ciertas.

Ah, pero hay una gran diferencia: clásica a cuántica = siglos, desktop a web = años (y desktop fue primero)
Cuando Newton "invento" la mecánica clásica, la cuántica no se habia inventado. (faltaban literalmente siglos para que nacieran Heisenberg o Planck.) En cambio, las formitas (y paginitas) web han coexistido con soluciones muy superiores... y lo que es mas curioso aun, con el tiempo van tomando mas y mas de esta soluciones, hasta el punto de que muy probablemente "culminen" en HTML8 o HTML9 al ofrecer funcionalidad que ya estaba disponibles desde años antes, a través de Flash o XAML.

El Web no se inventa con el propósito de usarlo como la infraestructura para el desarrollo de aplicaciones distirbuidas; se inventa con otro objetivo. A pesar de eso, ha podido ser usado para desarrollar aplicaciones en extremo complejas que todos conocemos.

La capacidad del cerebro humano para "retorcer" algo que inventa y convertirlo en algo distinto es ciertamente impresionante. Ciertamente son logros técnicos nada triviales. Pero al mismo tiempo es muy frustrante leer que "Chrome ya tiene procesos aislados, para que una pagina no tire a otra", por que te hace darte cuenta que los navegadores son en realidad una plataforma tan (o mas) inestable que windows 3.1, que ademas, esta presumiendo de "descubrir el hilo negro" separando las cosas en procesos (como si Unix o inclusive Windows NT no hubieran ofrecido algo así hace varios años). O que HTML5 ya tiene un "canvas" que te permite pintar pixel por pixel, o que "se esta estudiando la posibilidad de darle capacidad multihilo a Javascript", y la gente se emociona con esas "innovaciones", como si no supieran (y creo que tal vez es precisamente por eso) que todo eso ya estaba disponible en SDKs para el escritorio hace años.

Alguien mencionó también las plataformas móviles. Los smartphones son cada vez más potentes; hoy traigo en mi celular muchisisisisisisima más RAM y CPU que tenía hace casi 30 años en mi Apple IIe, o incluso mi PC 486 con 8MB de RAM hace casi 20 años. Y se conecta a internet, y puede ejecutar varios procesos de manera simultánea, y usa Linux en el kernel, y por si fuera poco, puedo hacer llamadas de voz.

Hace como 15 años incursioné brevemente en el desarrollo para plataformas móviles. En aquel entonces era la Newton de Apple, y fue muy interesante para mí porque pues había que cuidar mucho los recursos y tomar en cuenta muchas cosas que en escritorio no ocurrían, como la posibilidad de que app fuera interrumpida por el usuario o por otra app, o porque se acaba la pila o la conectan a la compu, etc. Simplemente el hecho de NO tener un filesystem era un cambio bastante fuerte.

Las plataformas móviles hoy en día ciertamente siguen siendo distintas de las de escritorio, pero ya tienen tanta capacidad que esa diferencia es muy pero muy pequeña. Y creo que esto es lo que traerá de vuelta el modelo de desarrollo de escritorio nuevamente: cuando ya suficiente gente tenga smartphones y utilicen aplicaciones móviles que funcionen incluso mejor que sus contrapartes web, preferirán la app móvil que entrar a la página (esto ocurre hoy ya con algunos sitios como por ejemplo Twitter, que muchos prefieren usar desde el móvil o con algun cliente de escritorio, que entrar a la página). Cuando lleguemos a esa etapa, las apps verticales que hoy se desarrollan puramente en web y muy de vez en cuando tienen un cliente móvil (pero esto va cambiando, cada vez más clientes piden un complemento de app móvil para su página web), sus usuarios ya no estarán contentos con la funcionalidad en web porque la sentirán muy limitada comparada con la app móvil. La solución será deshacerse de la app móvil y poner en su lugar una app de escritorio, aunque no funcione offline porque a fin de cuentas estará haciendo varias llamadas a una API remota.

Las aplicaciones web definitivamente tienen sus ventajas (cero deployment es tal vez la más obvia) pero también conforme se incrementan las aplicaciones que se quieren desarrollar en esa plataforma y se vuelven más sofisticadas, sus desventajas se vuelven cada vez más obvias. AJAX fue en parte un gran avance pero hoy en día sigue siendo un dolor de cabeza: las incompatibilidades entre frameworks como Prototype y jQuery, incluso entre versiones del mismo framework, sumado a incompatibilidades con otros frameworks de desarrollo web (ya sea en Java, .NET, PHP, Ruby, etc) la verdad es que el desarrollo web sigue teniendo mucho sabor al "viejo oeste".

Luxspes recordará una app bastante compleja en la que participamos los dos, y que fue precisamente un desarrollo como el que describo: una app de escritorio que no funciona offline porque es un cliente rico que hace un montón de llamadas a una app en servidor. Esto lo comenzamos en 2001 y nos fuimos por escritorio porque el desarrollo web todavía estaba más primitivo que hoy: no había AJAX y por lo tanto estar recargando las páginas web era una monserga para actualizar datos según lo que se iba capturando, la interacción era muy pobre. Seguramente hoy en día sería perfectamente posible desarrollar la app sobre web valiéndose de algún framework AJAX. Y es muy curioso pensar que tal vez de hecho la versión actual de esa app sea precisamente así, pero que la siguiente versión regrese al escritorio, ya sea en una computadora de escritorio o en forma de app móvil (que poco a poco se convertirá en el nuevo escritorio).

Todo lo que se ha hecho en el modelo de programación para el Web es llevar la "experiencia del usuario" con aplicaciones de desktop al Web. Nadie de los que han creado esas soluciones ha proclamado que está inventando algo nuevo. Todos reconocen la interactividad con el usuario de las aplicaciones de desktop y todos han tratado de buscar soluciones de lograr lo mismo para aplicaciones distribuidas usando el Web.

NO se está regresando al desktop porque NUNCA se abandonó. Se buscan soluciones para llevar un modelo local a un modelo remoto. Esa ha sido la idea que predomina en los sistemas distribuidos con sus limitaciones comparada con los sistemas locales.

Lo del caballo y Mérida no aplica con el Web. En el momento en que el Web surge para lograr lo que ha logrado, uno de sus objetivos es uniformizar modelos disparatados de aplicaciones distribuidas que usaban decenas de protocolos diferentes, técnicas de visualización de documentos diferentes y un sin fin de cosas.

Lo de los siglos que pasaron entre la mecánica clásica y cuántica tampoco aplica como un contra ejemplo. Lo que demoraba entre una idea (ciencia, técnica, etc.) hace cientos de años, hoy dura meses o quizá días. De otra forma, todavía viajaríamos en caballo a Mérida.
Los cassetes de Beta duraron menos que los discos de acetato.. Eso no es razón para decir qu fueron obsoletos desde que se inventaron.