Categoría: Visual Basic

En defensa de Visual Basic.Net y las “buenas practicas”

Posted on by ecardenas

Primero el Disclaimer: La herramienta a la que le tengo mas cariño y con la que he sido mas productivo es Borland Delphi (ahora Embarcadero, pero la que yo conocí era de Borland), dicho esto pasemos al grano.

El titulo del post proviene a razón de la ultima sesión de Mad.Nug en la que Jorge Serrano compartió su experiencia sobre las posibles acciones a tomar cuando se tienen aplicaciones en Visual Basic 6 y existe la necesidad/presion/requerimiento de migrarlas a .Net, la sesion fue muy explicativa, recordandonos cuales son los puntos donde hay mas incompatibilidades y las posibles opciones:

– Herramienta de migración automática
– Entorno mixto (Microsoft Interop Forms Toolkit 2.1 y wrappers)
– Empezar todo desde cero.

De acuerdo a su experiencia (corrígeme si te estoy referenciando mal, Jorge) debería procurarse por la ultima opción (en ese sentido Jorge facilito un buen enfoque para acometer esos proyectos), y estar alertas ante el riesgo de que una solución puntual como un entorno mixto crezca y pierdas el control.

Si bien comparto la idea de que hay casos en que no queda otra que proceder de esa manera, creo que esa decisión tiene que ser sopesada teniendo en cuenta criterios como: cantidad de lineas de código existente, dependencia de terceros, disponibilidad de conocimiento funcional, etc… en ese sentido se sintió la falta de cubrir posibles estrategias de cuando se ha decidido ir por el camino de la migración (que igual se hace para algunas aplicaciones, dejando el resto a un rehacer desde cero).

Bueno, a lo que iba, como parte del camino de un rehacer desde 0, Jorge planteo que había que procurar migrar hacia C# en lugar de hacia VB.Net, ¿por qué? es lo que nunca me queda claro, salvo por un hecho (mencionado en la reunión) que es la mayor disponibilidad de recursos en Internet para C# que para VB.Net, pero fuera de ello el acceso hacia el Framework de .Net es básicamente el mismo (salvo excepción que contare luego), por lo que también en la conversación con los asistentes se dejo caer que con C# se es mas ordenado y se encamina hacia las buenas practicas, por lo que ya entramos a un tema de preferencias y es a donde quería llegar.

Admitamoslo, por sus propias características en Visual Basic 6 era muy muy fácil desarrollar con malas practicas y que el código spaghetti generado sea muy difícil de mantener, pero si una cosa tiene Visual Basic .Net es que significo una ruptura sin pasos intermedios con respecto a VB6 a fin de volverlo OOP y compatible con el nuevo Framework (*), y por lo tanto mucha de la laxitud inherente al viejo VB6 ya no existe, es un buen lenguaje OOP y muy valido para aprovechar los conocimientos de sintaxis propios de Basic: Dim, as, Next, End…, el problema gordo es la herencia de mala imagen que lastra el lenguaje, asi que explicar a un manager que seria menos traumatico continuar con VB.Net en vez de C#…. complicado, triste realidad.

Siendo así creo que solo hay dos razones no personales para optar por desarrollar un proyecto en C#:
– Es muy critico contar con todos los recursos de documentación disponibles para un tema en concreto, que lamentablemente en su mayoría están en C# (p.ej. hay casi tres veces mas info para Generics en C# que para Visual Basic).
– Te ha tocado acceder a una parte del Framework que expone justamente un tipo de datos existente en C# pero no en Visual Basic.Net, eso me paso con la versión 1.1, no se si lo habrán solucionado, pero … queda como alerta.

En contraparte tengo algunas razones de productividad para seguir usando VB.Net siempre que puedo:
– Detección automática de algunos errores y de su corrección, esa potencia de mostrarte un subrayado en algunos errores de sintaxis es de veras de agradecerse, y lo mismo con el hecho de que si compilas y saltan errores no tienes que recompilar para ver si has corregido bien o no, conforme vas corrigiendo tu pila de errores se reduce.
– No sensible a las mayúsculas/minúsculas, esta característica va de la mano con lo anterior, si defines bien una variable (usando Camel y Pascal case adecuadamente) y luego la invocas, el hecho de que se te auto corrijan las mayúsculas y minúsculas es una señal inmediata de que no te has equivocado al invocar el nombre de dicha variable.
– Las instrucciones (begin..end..next..) son mas claras que las llaves ({}) para poder hacerse una idea del ámbito de un bloque de código.

Dicho esto, como desarrollador he venido a conocer ambos lenguajes, pero lo fundamental es el Framework, siendo que el saber C# me ha facilitado acceder a ciertos recursos no existentes para VB.Net, pero que luego a la hora de implementar no he vacilado en aplicarlos sobre proyectos en VB.Net, así que es bueno saber ambos, pero uno no debería de inhibirse y proponer el uso de VB.Net en los proyectos.

Pero algo se me quedo dando vueltas ya desde la sesión a propósito de eso de que C# te ayuda a ser mas ordenado (o algo así), y a esto se sumo el comentario de uno de los asistentes comento que ellos tenían una aplicación grande en VB6, basada en COM+/MTS, hecha según las recomendaciones que daba Microsoft por entonces para el desarrollo en COM, lo cual me hizo retroceder a la época en que este diagrama salia en toda presentación de arquitectura y diseño de aplicaciones alla por el final de los 90s:

Pongámonos en contexto, para el lanzamiento de Visual Basic 6, ya había un gran parque de aplicaciones en VB4 y VB5, pero la fama del “DLL Hell” ya era muy fuerte, así que Microsoft emprendió una campaña muy intensiva para explicar el concepto de desarrollo de aplicaciones distribuidas, las ventajas del multicapas en la mantenibilidad de las aplicaciones, etc etc… conceptos que ahora son el pan de cada día en los objetivos de los diversos proyectos actuales, fueron recien conocidos para muchos gracias a Microsoft, y la verdad es que en ese entonces Microsoft se preocupo mucho en hacer pedagogía de las buenas practicas, tan así que en los cursos de certificación se hacia énfasis en lo que hay detras de la instanciación de objetos en COM para de esa manera impulsar formas mas ordenadas de programar, y lo bueno de todo es que esa pedagogía era de manera no agresiva, planteándola como una evolución de las aplicaciones que habia en desarrollo entonces, a fin de que los programadores mejoraran sus practicas frente a la fama de caos, o sea se pugnaba (por entonces) un cambio evolutivo en las formas de hacer las cosas apoyándose en lo que los desarrolladores ya conocían, lo cual condujo a que los partners serios si que hicieran aplicaciones buenas y solidas usando VB6.

Para bien o para mal todo cambia con la introducción de .Net, que como ya hemos indicado en este y otros posts vino a ser un ruptura muy fuerte, en la que sobrevivía el que tenia mejor las bases de OOP y/o Windows DNA. Claro, ya lo peor paso (salvo las app VB6 que se resisten a morir) y la cosa esta mas o menos estabilizada, salvo por la nueva tendencia del famoso patron SOLID, sobre el cual ya comente que tenia mis dudas sobre si facilitaban la mantenibilidad de las aplicaciones, pero que en todo caso hay que entenderlas y saber como y cuando aplicarlas, siempre sin dogmatismos.

Y es justamente que ahora los dogmatismos se hacen presentes, pues en lugar de introducirnos progresivamente a las nuevas “buenas practicas” se nos pide que ya no usemos ni Windows Forms (aunque si, podríamos pasar a WPF) ni Windows Forms, diciendonos que “no es testeable” “no permite xxx principio” de buenas a primeras sin mostrar evolutivamente como mejorar el código que estamos desarrollando, de ahi a lo que dije en un twitt reciente: Si nos explicasen las pruebas unitarias con ejemplos basados en multicontroles, eventos y mantenimientos, igual las adoptariamos #digonomas (o este otro), digo eso porque la mayoría de las aplicaciones corporativas de uso interno (no portales de contenido) terminan siendo eso y no los clásicos ejemplos de calculadoras o números perfectos, así que seria bueno que los planteamientos de difusión sobre TDD o SOLID partan de un enfoque evolutivo y no rupturista (dando cobertura tanto a VB.Net como C#) a fin de lograr una mejor adopción.

A ver si no llega alguien por aquí diciendo que he “perdido el punto”… xD

(*) Y si, sigo creyendo que muchos traumas se hubieran evitado si al hacer .Net (y C#) se hubiera mirado lo que tenia VB6 a fin de hacer la ruptura menos dolorosa.

Pensando en estrategias de migración de VB6 a VB.Net

Posted on by ecardenas

Casi a hilo de lo que comentaba en el anterior post, hace poco Jorge Serrano publico Cada vez que migras una línea de código de VB6 a .NET se muere un gatito en el mundo, interesantisimo post que vale la pena leer pues resume muy bien los dilemas, actitudes,creencias erróneas y decisiones que se acometen cuando se tienen aplicaciones en Visual Basic 6 y se piensa el migrar a .Net como una opción a considerar.

Me detendré poco en el tema de la discusión de si migrar si o migrar no, pero en mi modesta opinión creo que los criterios de discusión deberían girar alrededor de (entre otras) estas preguntas:
– ¿Qué tan diferente son los procesos de negocio de la organización de como eran cuando la aplicación fue construida?
– ¿Son los algoritmos técnicos de las aplicaciones aun validos para los procesos de datos?
– ¿El esfuerzo de “entender” la aplicación actual y documentar la especificación de la nueva es mayor que el de la “simple” migración? (Cuando no queda nadie del equipo original)

Llegados a nuestro escenario “pues si, necesitamos migrar esa aplicación pues ya cada vez es mas difícil mantenerla y vamos a migrar de plataforma….. ” hay que plantearse las cosas de como acometerla, no tanto desde el punto de vista técnico, que para eso hay suficiente información en Internet, sino mas bien de cuales serian los pasos razonables para lograr el objetivo de una migración exitosa.

Con esas miras puestas, la experiencia que he tenido recientemente me llevan a plantear dos pequeñas metas antes de la migración en si:
– Reducir todo lo que se pueda la cantidad de lineas a migrar.
– Reducir y aislar los comportamientos críticos no migrables.

Cuando hablo de reducir la cantidad de lineas a migrar, parto del hecho de que es mas que probable que la aplicación a migrar hay sufrido modificaciones durante su tiempo de vida, lo cual haya ocasionado que métodos o clases que antes eran invocados se hayan convertido en código muerto, y reducir ese código muerto antes de la migración deberá ser uno de los principales objetivos que debamos de plantearnos, puesto que es preferible saber de antemano que código ya no es invocado (y eliminarlo/comentarlo) que matarnos en hacer que funcione para luego saber que … sorpresa.. sorpresa… era código muerto.

El tema de los comportamientos de lenguaje no migrables (“As any”, redimensionamiento de arrays …) es complicado, por lo que creo que es conveniente, en la medida de lo posible tomar las acciones para reducirlos antes de la migración y si eso no es posible marcar dicho código como problemático.

Ahora bien, estos son objetivos loables, pero lamentablemente difíciles de conseguir con las herramientas de Microsoft “out of the box”, que si que el Code Analysis de VS .Net nos facilitara el encontrar las referencias “muertas”, pero lamentablemente el tener una información completa de este tipo solo sera posible cuando el código migrado compile sin errores, pero claro… volvemos a lo mismo podemos pasarnoslas divertidos corrigiendo código para luego descubrir que ese código no era invocado en ningún lugar.

Entonces queda claro que el análisis de dependencias es critico, y lamentablemente no queda sino recurrir a herramientas de terceros, concretamente he estado probando Project Analyzer con resultados muy interesantes pues ademas de encontrarme con la opción de encontrar todo el código muerto, me detecto todos las porciones de código que requerían migración manual.

Así pues, creo que el contar con una herramienta de ese estilo (he mencionado Project Analyzer, pero igual podría ser alguna otra) cobra un importancia muy especial en esta clase de proyectos, ya que permite cubrir los dos primeros objetivos señalados y llevando de rebote una ventaja adicional: darnos cuenta, mediante el análisis de dependencias de que porciones de código no compatible como llamadas a la API de Windows, podrían ser reemplazadas por código .Net.

Ese análisis e identificación de codigo critico seria un primer paso, de ahí vendrían los siguientes:
– Refactorización, si, se puede, y nos ayudara a tener nuestro código heredado mas legible.
– Preconversión de código no migrable a código migrable, donde sea posible y se sepa que se seguirá usando luego de la migración.
– Migración en si, ya sea usando Visual Studio o una herramienta de terceros, y de ahí las sucesivas iteraciones para estabilizar el producto hasta el nivel deseado (reemplazo de ADO por ADO.Net, eliminación de los Interop….)

Es obvio que este proceso iterativo por lo que no conviene dar un paso nuevo hasta que no se sepa que la nueva versión sigue haciendo lo que hacia antes, de ahí la importancia de tratar de acometer la mayoría de los cambios posibles antes de la migración en si.

¿Qué le hubieramos pedido a un hipotetico VB 6.5?

Posted on by ecardenas

Pues si, ya han pasado poco mas de 10 años en que .NET fue anunciado (recordemos que antes era llamado NGWS), por lo que ya tendría poco sentido hablar de su predecesor, pero la experiencia de volver a tener que lidiar con VB6 me ha hecho volver a reflexionar algunas cosas…

Primero situémonos en el contexto, VB6 fue lanzado durante 1998 he incluía mejoras como: ADO 2.0 (un enésimo santo grial en la unificación de los modelos de acceso a datos), WebClasses, mejoras en el soporte a COM e integración con MTS; con todo no fue un modelo rupturista y las empresas entusiastamente dieron el salto desde VB5 (versión que por primera vez libero a VB del p-code permitiendo compilar en modo nativo).

Todo bien excepto algunos detalles…. como la herencia, lo cual le hacia ser denostado como un lenguaje no totalmente orientado a objetos, palideciendo en ese sentido ante sus rivales: Delphi y Java. Admitamoslo, durante buen tiempo los fans de VB actuaron con la política de la zorra y las uvas, diciendo que la herencia no era totalmente necesaria, y pregonando la potencia de las interfaces para lograr el polimorfismo. Aun así Microsoft decidio explorar por el lado de una OOP sin las complicaciones del C++, y el resultado fue Visual J++ 6.0 el cual tuvo problemas con Sun, por lo que el producto no tuvo tanto éxito, aunque si que me he topado con un cliente en el cual había herencia de su uso.

Visto ese escenario, para principios del 2000 se rumoreaba sobre lo que seria el inminente ASP+ y el NGWS (Next Generation Windows Services), pero Microsoft sorprendió al mundo cuando en Julio anuncio a .NET, C# y el hecho de como el nuevo VB.Net seria un lenguaje totalmente orientado a objetos, luego vendrian las primeras versiones beta de Visual Studio .Net, sobre cuyo primer contacto ya me he explayado.

Como ya he comentado mi adaptación como desarrollador al nuevo entorno fue fácil, gracias a la base OOP proveída por Delphi, así como a las buenas practicas de los cursos de certificación, pero eso no impedia que mantuviera un ojo en los problemas que se iban a presentar en la transición de VB6 a VB.NET….

Estos cambios venian dados por dos lados: cambios en el lenguaje y cambios en el Framework (de COM a .NET) y ambos eran muy agresivos, tan asi que dos respetados gurues de la época dieron su explicación (muy acalorada por cierto) de porque VB.Net era un nuevo lenguaje (para ellos peor) y no una evolución de VB6:

Karl E. Peterson: VB Fred, A Marketeer’s Worst Nightmare
Bruce McKinney: The End of Hardcore Visual Basic

Sugiero dar un vistazo a esos artículos y a los enlaces ahí contenido para entender la magnitud de los cambios, y si bien luego las cosas no fueron tal como se pintaban en la beta, los cambios si que son muy rupturistas e intentar asumir una migración es algo de veras intimidante.

He realizado migraciones de aplicaciones .NET de la version 1.0 a 1.1 y de la 1.1 a la 2.0 y se puede decir que el camino es mas o menos controlado, pues el lenguaje siempre es compatible hacia atrás, y si bien el Framework evoluciona, dejando algunas tecnologías obsoletas (como Remoting) siempre se puede recompilar en una versión superior, siendo que los potenciales problemas están por el lado de:

– Dependencia de una librería de terceros, cayendo en esta categoría el Enterprise Library, el cual si que tuvo cambios que obligaban a modificar el codigo, problema no presentado en una libreria comercial como Dundas.
– Necesidad de apuntar a una plataforma especifica (como x64 o Itanium), lo cual sumado a lo anterior da para pruebas y comprobación de entornos.
– Alguna cosa que compile, pero que en ejecución falle, son pocas pero las hay, aunque siempre se pueden controlar añadiendo un mayor control de excepciones.
– Cambio de estructura de proyectos, como en el caso de los Servicios Windows, pero se soluciona creando el proyecto desde cero e inyectando progresivamente las clases y métodos necesarios.

En resumidas cuentas, un camino que puede ser mas o menos pesado dependiendo de cuan complejo sea el proyecto, pero en el cual siempre hay vías de hacer que la migración funcione.

Planteemoslo de otra manera, ¿para 2002 habían en producción aplicaciones en VB5 o VB4? Lo dudo sinceramente, el punto de quiebre fue VB5 y como comentaba la migración de VB5 a VB6 era totalmente transparente, salvo (como de costumbre) en la dependencia de algún control de terceros.

Osea, que para migrar dentro de versiones de VB.NET o de Visual Basic “clasico” los caminos han estado mas o menos marcados y eran controlables, pero… para migrar de VB6 a VB.Net… ahi es otra cosa.

Como mencionaba lineas arriba los cambios vinieron por dos frentes: cambios traumaticos en el lenguaje y reemplazo del framework basado en COM por uno basado en .NET. (los dos primeros capitulos de este libro pueden dar una vision de los cambios), si le sumas esto al hecho de que cuando Anders Hejlsberg acometio el desarrollo de .Net, decidió crear un nuevo lenguaje C#, e hizo muchos de los diseños del CLR y el CLI sin tomar en cuenta las particularidades (ya muy usadas por los desarrolladores) de VB, esta claro que lidiar con los cambios seria una tarea harto compleja, cito el libro arriba mencionado:

The Decision to Break Compatibility

When did Microsoft decide to break compatibility with Visual Basic 6? It was actually in early December 1999, during the development of Visual Basic .NET. Until that time, Visual Basic .NET was being developed to support the notion of “Visual Basic 6 sourced” projects that allowed you to edit and compile Visual Basic 6 projects in Visual Basic .NET. These projects would have a compatibility switch turned on, meaning that the language would be backward compatible with Visual Basic 6 and would even have access to the old Visual Basic 6 forms package.
By the end of 1999, it was obvious that this strategy wasn’t working.
Little differences were slipping through: The old forms package could not be fully integrated into .NET, and the Visual Basic 6 sourced projects could not use some of the new features of the .NET platform. At that point Microsoft made the decision to break compatibility and instead concentrate on ensuring that people could upgrade their projects from Visual Basic 6 to Visual Basic .NET.

En fin, es cierto que muchos cambios (de lenguaje) eran inevitables y demandados por la comunidad de desarrolladores: soporte de herencia, excepciones y threading, pero esta claro que Microsoft pudo haberlo hecho mejor en algunos aspectos (de hecho, parte de las criticas de los gurus arriba citados van por el lado de que algunos cambios no eran necesarios para hacer a VB un lenguaje OOP) como la gestión de los arrays, no forzando a tener que hacerlos basados-en-zero y si por el contrario permitir que su gestión de limites sea equivalente a la de VB6.

Entonces esa es la situación a la que llegamos cuando sale al mercado Visual Studio .Net 1.0, el gap del Framework y el lenguaje es tan grande que solo proyectos triviales son susceptibles de ser migrados a .NET, para lo demás muchas veces es mejor hacer el proyecto desde 0, o sino… seguir manteniendo y parchando el código en VB6 hasta que se decida tomar la decisión de migrar (pues ya se sabe lo que dicen las gerencias “Si funciona ¿para que tocarlo?”, claro, es así como el COBOL no muere). La dura realidad es esa, que las organizaciones se han quedado con un parque de aplicaciones para un lenguaje/plataforma que ya no evoluciona y si bien ahora se cuenta con una buena herramienta como el Artinsoft Visual Basic Upgrade Companion, la verdad es que en todo proyecto complejo nos toparemos con situaciones como estas:

– Las inevitables llamadas a la API de Win32, ya no funcionan, y no hay forma directa de hacer un cambio que permitan la recompilacion.
– A revisar todos tus arrays para estar seguro de su comportamiento.
– Replantearte como gestiona el ciclo de vida de tus objetos.
– Los controles y clases tienen otras propiedades, no hay equivalente directo en .NET para algunas clases de terceros y la importación (wrapping) no siempre es segura.

Previo al lanzamiento de VS.Net, algunos articulistas pedían que saliera una ultima versión de VB basada en COM que facilitara la transición y/o introdujera algunas mejoras a VB6, la verdad es que mire de lejos esas peticiones, claro… estaba entusiasmado por el giro a OOP que no mire la complejidad que estoy narrando, pero ahora luego de estos 10 años de .Net (contando desde su primer anuncio y Beta) creo que si que Microsoft debió intentarlo y proveer esa herramienta a fines del 2000 o principios del 2001 a fin de que hubiera un punto intermedio en el camino desde VB6 hacia .Net, lo cual me lleva a la pregunta planteada como titulo de este post….

Personalmente yo hubiera excluido la herencia como caracteristica de un VB 6.5, implementarlo es complejo y el problema radica en como gestionar caracteristicas usadas en las aplicaciones hechas en VB 6 para que funcionen luego en .NET, siendo asi, VB 6.5 debería haber tenido (como anticipo al cambio en .Net):

– Soporte dual para arrays con limites libres y basados-en-zero. Si MS seguia terco en lo de no permitir los limites libres, la compilación debería permitirlo pero indicar que esa característica estaba “deprecada” y no soportada en futuras versiones.
– Fin de las propiedades por defecto de los objetos.
– Eliminación del tipo Variant.
– Cambio en el ámbito de la visibilidad de las variables.
– Uso obligado de paréntesis en las subrutinas.
– Ofrecer un mecanismo de llamadas a la API Win32 cercano al uso que luego tendria DLLImport, pero respetando (temporalmente) la mayoría de los hacks que se tuvieron que hacer para trabajar con dicha API.
– Opcional: soporte para try..catch..finally
– Únicos cambios en el IDE: Encontrar todas las referencias, herramienta imprescindible ahora para una adecuada inspección del código, y un compilador que devuelva una lista de errores y no uno por uno.

La idea de esto seria que los desarrolladores acometieran ciertos cambios sin retorno, sin todavía decirle adiós a COM, para de esta manera tener hechos los deberes en el grueso del lenguaje, quedando (en teoría) cambios menores en el lenguaje y “solo” adaptarse al .Net Framework.

Si Microsoft hubiera hecho esto, a estas altura no habria esas aplicaciones en VB6 que se resisten a morir, haciendo a VB6 el nuevo COBOL, pues eso es lo que esta pasando… un nicho de aplicaciones que persisten mas alla de su ciclo de vida.

Y tu ¿que característica le hubieras puesto a un VB 6.5 todavía basado en COM?.

¿Que hace que una tecnologia resista mas alla de su ciclo de vida?

Posted on by ecardenas

Hace exactamente 3 años comentaba la situación en la que se encontraban muchas empresas, ancladas al pasado tecnológico con tecnologías de mas de 20 años, y de paso enlazando tecnologías que estaban muriendo o agonizando: Cobol(*), Bases de Datos no Relacionales, redes no TCP/IP, ccMail, ColdFusion, C (puro, no C++), PowerBuilder, Netware, PC network y OS/2; claro esta que a esa lista añadiria xBase (¿se acuerdan cuando casi todo pequeño negocio tenia su aplicación en Clipper o Fox para DOS?).

Ya sabemos que aun en pequeños negocios como cabinas de internet cuesta de convencer el migrar hacia tecnologías mejores y mas eficientes, pero aun así al ver la lista mencionada uno ve que el estado de estas tecnologías es mas bien dispar, algunas tecnologias estan realmente muertas o terminando de morir en sus ultimos espacios, mientras que otras a pesar de no brindar nada nuevo, siguen siendo la base para nuevos desarrollos, conviviendo con otras tecnologías.

¿Qué es lo que hace que algunas resistan y otras no? Especulare un poco y a ver si comparten mis ideas.

1)La ola es muy fuerte y no puedes sino dejarte llevar, si, en este caso estamos hablando de Internet y el efecto de arrastre que implico para la adopción del protocolo TCP/IP como la opción por defecto en las organizaciones, todo Ethernet, adiós token ring, protocolo IPX…. lo cual de rebote termino cargándose a las redes Netware de Novell, antaño bien implantadas en muchas organizaciones. Así que si todos los proveedores, incluyendo los de mainframe, deciden dar el salto al soporte de TCP/IP (como ocurrió en la segunda mitad de los 90s) el cambio ya es inevitable. Por mas que algunos digan que Internet resucito un protocolo que ya era “cadáver”, al final la inercia del mercado y la demanda por conexión a Internet nos arrastro a todos, y ya no miramos atrás.

2)El costo de mantener la compatibilidad es muy alto comparado con la migración, aquí ya entro un poco en la especulación basándome en lo que he visto en las pymes, quieras que no el mercado de aplicaciones para pymes es muy dinámico y llega un momento en que ya no se pueden mantener las aplicaciones existentes por: no se pueden encontrar profesionales, o porque eventos como la introducción de Windows 95 o el problema del año 2000 te hacen sacar la calculadora y ver que mas barato te sale migrar que seguir manteniendo tu querido Clipper.

3)Lo que elegiste no era tan masivo y cada vez te costara mas encontrar soporte, aquí caen dos tecnologías al margen de sus méritos: Delphi y PowerBuilder, efectivamente ofrecían una buena respuesta tecnológica a las necesidades de desarrollo en Windows de esa época (mejor que VB en el caso de Delphi, p. ej), pero la presión introducida por el desarrollo de aplicaciones Web, así como la pujanza de .NET y Java, hizo que el nicho de mercado que se había construido alrededor de estas tecnología se debilitara impulsando su migración. Lo bueno en este caso es que la arquitectura modular de estas tecnologías (el entorno de desarrollo de la aplicación no esta amarrado a la BD como en xBase) permite migraciones menos traumaticas y mas progresivas.

4)Es mas caro migrar que mantener la compatibilidad si, al revés que el caso 2) y en este caso nos topamos con los engreídos de la industria: el mainframe ya sea en sus variantes PL/1 o COBOL, están ahí, las empresas se resisten con uñas y dientes al cambio, por la sencilla razón de que debido al volumen y trafico de información, el riesgo de tener la producción caída es algo que no se puede asumir, punto. Es curioso que cuando hubo el problema del años 2000 en algunos casos se haya optado por una huida hacia adelante, parchando la infraestructura en vez de aprovechar la oportunidad de reemplazo. Y así como están las cosas, se requerirá mucho valor y cabeza fría para que una organización decida migrar sus aplicaciones, pero la verdad…. ¿de veras tiene sentido basar lógica de negocio en la posición de un carácter en un texto plano?

5)Entenderlo es mas complicado que parcharlo esta es la peor situación de todas, pues la limitación viene dada no por las características de la tecnología, si no por como esta tecnología no te coloca restricciones para hacer mal código, concretamente Visual Basic 6 cae en esta categoría, ya que como comente antes es perfectamente posible construir aplicaciones en VB6 con una arquitectura robusta y buenas practicas (y he visto buenas aplicaciones de este tipo), pero la propia filosofía del lenguaje no te impulsa a ello, recayendo totalmente en el desarrollador y la organización el montar algo ordenado, siendo que una vez empezado el trabajo esa reorganización es tarea imposible. Resultado: que esas aplicaciones se mantengan, crezcan y crezcan a golpe de parches, haciendo la migración algo temido por la organización, haciendo que VB6 ya sea considerado como el nuevo COBOL, con la diferencia de que el soporte y evolución quedo cerrado hace rato, así que solo resta esperar una nueva revolución que nos fuerce a dejarlo.

Esto es, dentro de mi experiencia, lo que creo que establece diferencias entre los destinos de diversas aplicaciones, me quedo con la curiosidad de saber cual ha sido el proceso por el que pasaron tecnologías como ADABAS, mainframes NCR y AS/400.

(*)Aunque yo lo consideraría de la mano de su hermano en mainframe: PL/1.

Lo tenia delante pero no sabia decir porque no me gustaba: Java

Posted on by ecardenas

Cuando uno llega a una situacion u opinion es porque ha recorrido un camino previo, nadie te ha teletransportado ahi, solo que a veces nos olvidamos de dicho camino.

Concretamente debo referirme a la predileccion como desarrollador que tengo para con la plataforma .Net, el porque termine ahi y lo prefiero frente a Java … tiene su historia.

Luego del paso obligatorio por Pascal, C/C++, COBOL tocaba enfrentarse a las herramientas de desarrollo “real”, con la que se hacian las cosas en las empresas, y sobre todo, las que permitian desarrollar para Windows. Tuve ocasion de hacer un curso de Gupta SQL Windows, el cual me dejo un mal sabor de boca.

Es por esa epoca que tambien me expongo ante Visual Basic 4/3, se comenta algo sobre Java, pero aun no recuerdo el como y porque (creo que lo que lei por ahi) termino en mi casa haciendo experimentos con Borland Delphi 1 y fue quedar seducido por la propuesta hecha: un poderoso lenguaje Orientado a Objetos, con una interfaz que cogia lo mejor de los conceptos drag and drop popularizados por Visual Basic.

Pero claro, lamentablemente en Peru Delphi era un lenguaje casi de “culto”, por lo que urgia revisar las cosas que iban apareciendo en el mercado y una de esas cosas fue algo que me comentaron a poco de terminar mi primera Feria del Hogar: un lenguaje llamado Java el cual prometia traer la interaccion a la web mediante los llamados “applets”, propuesta interesante la verdad, el caso es que no me pude poner a probar Java sino hasta el 97 en que pude instalar Windows 95, esto debido a que no habia opciones para correr Java en W3.11 como no sea mediante el proyecto ADK que no se en que habra terminado.

Intente darle su espacio a Java, pero entonces me topaba con unos problemas que para entonces eran criticos:
– Ausencia de un IDE lo suficientemente rapido, aun el Borland JBuilder era muy lento, siendo que aun VB (5 para entonces) era mucho mas rapido y ni que hablar de Delphi (3 y 4).
– No continuidad en el modelo de presentacion grafica, de un momento a otro se decidio que las AWT debian dar paso al modelo Swing.

El lenguaje en si no daba muchos problemas (regresaremos a esto), pues ya contaba con la base de saber C/C++, pero lamentablemente costaba mucho ser productivo, siendo que con Delphi implementar algo era relativamente simple (pero no tan innecesariamente simple como con VB). Tambien es conviente notar que como el enfoque era hacia dar “dinamismo” a la web, surgieron herramientas que proponian alejarte del codigo para generar applets (semi prefabricados) de manera mas agil, hablo de Kinetix y Jamba. Y claro, por otro lado teniamos a Kawa, que fundamentalmente era un gestor de proyectos que tras bastidores llamaba por linea de comandos al JDK.

Es asi que me volvi en uno de los pocos defensores de Delphi en Lima de esa epoca, hice experimentos con las opciones de desarrollar paginas con ISAPI, controles ActiveX incrustados, desarrollo en 3 capas mediante Midas, y claro un buen rato metido en el newsgroup non-technical de Borland asi como en ClubDelphi, circunstancias que me llevaron a conocer a Claudio Briceño (responsable comercial de Borland para Latinomaerica) quien me vino a visitar a mi trabajo de entonces, lo cual luego conduciria (gracias a la posterior coordinacion de un comunidad de Linux en el Peru) a la posterior presentacion de John Kaster en el Hotel Los Delfines para presentar los avances que hacia Borland en desarrollar Kylix un entorno Delphi para Linux, y si, ahi estoy yo… :

Luego me tocaria cenar tanto con Claudio y John a la espera de posteriores acciones que permitieran potenciar la presencia de Delphi en el mercado peruano, lo cual no logro a materializarse.

En esas circunstancias, veo que las cosas cambian, nadie habla de applets, todo se orienta hacia los servlets, y a los EJB, les doy una revision… nuevamente, cuesta hacer algo simple de manera rapida, se nos habla de que ya saldran los JSP….. Lo interesante es que a pesar de esas limitaciones Java estaba cogiendo un mayor arrastre, el cambio de lo “visual” hacia los modelos de componentes orientados a servidor habian probado ser buenos para la estrategia de Sun, ya que habia una demanda en el mercado por una solucion no atada a Microsoft, mas orientada a objetos y que fuera robusta, en ese sentido los Application Server lanzados por diversos fabricantes permitieron consolidar su posicion en el mundo corporativo.

Es en esas circunstancias que (me)ocurrieron varios eventos de manera casi consecutiva, Microsoft anuncia .NET prometiendo una plataforma totalmente Orientada a Objetos(*), soy admitido en una beca de Microsoft para estudiar VS 6 y ceso en mi trabajo de entonces.

Estudiar lo que ofrecia VS (VB + Interdev fundamentalmente) me hace ver ciertos detalles que no eran tan claros para mi, era perfectamente viable construir aplicaciones robustas con esas herramientas, pero que muchas veces la simplicidad te conducia a errores de diseño que penalizaban la performance y la mantenibilidad, siendo necesario un conocimiento serio de la arquitectura detras (algo en lo que los cursos de Certificacion enfatizaban bastante).

A pesar de haber “cambiado” de herramienta por razones de mercado, sabia que esto era algo transitorio, pues veia la fuerza que iba a arrastrar el lanzamiento de .NET, producto al que recibia con expectativas positivas debido a que el cerebro detras de esto era nada menos que Anders Hejlsberg quien habia sido arquitecto de Delphi en sus dos primeras versiones, del cual solo podria esperar que introdujera en la nueva plataforma la evolucion de las innovaciones que habian sido introducidas originalmente en Delphi.

(Para ese entonces Borland libera Kylix, el cual debo decir que nunca use)

Obviamente que apenas pude me consegui una de las primeras Beta de Visual Studio .NET, aparatoso como buena beta, ya dejaba ver que habia asumido totalmente el modelo de objetos, y por todas partes se notan los guiños a Delphi, especialmente en C# en el tema de la gestion de eventos, comprendi entonces que me encontraba ante una herramienta potente y sobre todo que introducia la programacion RAD y orientada a eventos al desarrollo Web, algo tan simple y a la vez potente era algo por lo que los desarrolladores habiamos estado esperando buen tiempo. Pero lo mas importante era que todo lo aprendido sobre OOP en Delphi se aplicaba directamente en la nueva plataforma, y a estas alturas creo que mi transicion fue mucho mas simple que si hubiera venido solo procedente de VB6, lenguaje que con todo lo flexible que era, te enmascaraba muchos detalles los cuales no te permitian una total potencia en el desarrollo.

Para cuando llegue a España ya habia experimentado con la Beta 2 (y una pre-Beta2 no lanzada masivamente pero que me fue facilitada en Microsoft Peru), por lo que seria cuestion de tiempo que me terminara involucrando en proyectos de .NET como ha sido hasta la fecha, incluyendo examenes de certificacion en el interin.

Han pasado los años y es gracias a CampusMVP que me entero de unos articulos de Ian Marteens(al cual ya habia leido por 1999) en los que se hacen interesantes comparativas entre Java y C#, enterandome de que la implementacion de los Generics en C# es mejor que en Java, pero confirmando algo que ya habia intuido en mis primeras peleas con Java: su implementacion de eventos es penosa, ya que como el mismo Marteens dice “Los diseñadores de Java eran personajes que odiaban los punteros, y nunca hubiesen aceptado implementar los eventos al estilo Delphi. De hecho, ni siquiera tuvieron en cuenta el soporte para eventos cuando crearon Java”. No vieran el alivio que tuve al leer esto, durante mucho tiempo creia que era yo quien podria estar haciendo algo mal cuando trate de implementar cosas en Java, pero como se puede ver en esta serie de articulos, hay errores (llamalos caracteristicas si quieres) en la implementacion del lenguaje, y era algo que alguien que provenia del entorno Delphi podia intuir, pero es bueno saber que hay bases formales para entender las ventajas de un lenguaje (lenguaje, no plataforma, esa es otra guerra) sobre otro.

Como digo, es un camino el que me ha traido hasta aqui y ese camino empezo con la experimentacion de Delphi, herramienta que a pesar de no trabajar con ella en años, no puedo sino recordar con cariño y agradecimiento por las bases que me dejo.

(*)Recordemos los fuertes ataques que recibia VB por no incluir algo tan simple como la herencia.