El nombre que utilizaremos para este híbrido que os planteo será CSharpFox y el nombre corto CSF.
Recordar de donde venimos...
Para los nuevos en este blog, incluso para los foxpreros dejaré claro que FoxPro ya es de por si un framework desarrollado con Microsoft C++ y que si entramos en detalle VFP 9.0 está desarrollado con Microsoft C 7.1 (nos lo deja bien claro nuestra querida librería msvcr71.dll, incorporada junto los runtimes de Foxpro), y que si profundizamos aun un poco más las aplicaciones que se están compilando últimamente utilizan msvcr8.dll y msvcr90.dll (aun en 32 bits), creo entonces indiscutible que FoxPro como lenguaje de programación de tipo framework no llega (sin problemas) al mencionado por Microsoft, soporte y actualizaciones hasta el 2015.
Antes de hablar de a donde os quiero llevar, hablemos primero de lo aprendido, especialmente los que ya somos veteranos...
No nos podemos fiar lo más mínimo de Microsoft. Cualquier otra tecnología de otros fabricantes (lenguajes, S.O., aplicaciones ofimáticas, etc.) ha sido siempre más estable y duradera, en lo que a compatibilidad hacia atrás se refiere, que cualquier producto desarrollado o comprado por Microsoft.
Una refinada estrategia...
En lo referente a las posibilidades, algunos, en especial los que hacemos aplicaciones de escritorio, no podemos abandonar desarrollar proyectos bajo las plataformas de Microsoft. Todo esto nos lleva, mejor dicho nos obliga, a definir una refinada estrategia que nos permita sobrevivir como desarrolladores en esta selva amazónica de fabricantes, sistemas operativos, versiones comerciales, descatalogación de productos, etc. en la que nos tenemos que desenvolver.
En lo referente a FoxPro, cuyo origen no está en Microsoft, sino en quien se lo vendió, una compañía llamada FoxBase (donde se desarrollo la tecnología RUSHMORE), y que Microsoft incorporó, incluidos los ingenieros de Foxbase, a productos suyos como el EXCEL podemos desgranar sus características osea decir lo siguiente:
- Su capacidad para almacenar datos SQL de manera nativa (embebido), para usos internos de nuestros programas o pequeñas aplicaciones de escritorio.
- Sus potentes funciones para el tratamiento de texto a un nivel muy alto.
- La Macrosustitución (ya que es un lenguaje interpretable) como elemento para resolver problemas que no podrían resolverse de ninguna otra manera.
- Un motor básico, pero funcional, para la salida de información(generación de Reports) necesario en cualquier aplicación aunque no esté orientada a datos.
Con todo esto, si lo tenemos que abandonar por imperativo legal de Microsoft, simplemente tenemos que elegir un nuevo lenguaje que incorpore o nos permita incorporar las propiedades de Foxpro anteriormente mencionadas.
Ahora bien, ¿ A donde podemos ir, según mi humilde opinión ?
Yo diría que "A TOMAR VIENTO" pero como no quiero ser pesimista, mi devoción por la programación y el tener que seguir obteniendo el pan nuestro de cada día... os daré suficientes pinceladas como para que juntos podamos encontrar una senda clara en la mencionada selva amazónica.
Mi aventura personal...
Los primeros pensamientos que estallaron en mi mente al conocer la definitiva discontinuación de Visual FoxPro por parte de Microsoft, me los guardaré ya que no quiero perder la compostura, ni crear una mala impresión, ante quien esté sumergido en la lectura de este artículo.
He de reconocer que los peor parados eran los programadores de VisualBasic, ya que no sólo existía la migración a VB .NET sino que les cambiaba el paradigma.
Una vez superé la fase de incertidumbre y odio desmesurado hacia mi querido Goliat (Microsoft), pues tenía la certeza de que David (un servidor) no acertaría, ni de cerca, si intentaba lanzar la piedra, empecé un profundo y sosegado análisis de las posibilidades que se abrían ante mi.
Mi primer descubrimiento...
Éste fue el indice TIOBE: (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html), hacía visitas a este sitio una vez al mes para ver hacia donde migraban los lenguajes más punteros.
Por otra parte, todos los meses realizaba búsquedas en Google con las palabras (FoxPro, Visual FoxPro, etc.) anotando en una Excel los resultados obtenidos, osea la cantidad de sitios (según Google) que apuntaban a las mismas.
Hice lo mismos con JAVA y C# .NET y así, pasados un par de años, descubrí varias cosas:
- FoxPro caía vertiginosamente, hasta el punto de salirse del índice.
- JAVA era imbatible pero su gráfica no denotaba estabilidad.
- .NET (C Sharp) no paraba de crecer con una estabilidad envidiable.
Al compara todos estos datos con los obtenidos en TIOBE certifiqué como FoxPro se salía del Indice. JAVA tenía altibajos ( por lo leído era cuando un organismo realizaba un gran proyecto poniendo gran cantidad de desarrolladores a programar con este lenguaje). C SHARP crecía muy lentamente pero sin parar y VB .NET estaba a años luz en el mencionado indice.
Con todos estos datos empecé a investigar sobre JAVA y C SHARP, descartando C y C++ pues eran demasiado lentos en tiempo de desarrollo. Finalmente me decanté por C SHARP, quien me iba a decir que me quedaba de nuevo con Microsoft.
Las razones de mi decisión fueron las siguientes:
- JAVA se había complicado por su vejez y la adaptación a las tecnologías que surgían a través del tiempo, C SHARP empezaba de nuevo y eso era una ventaja.
- C SHARP fue aprobado como un estándar por la ECMA (ECMA-334) e ISO (ISO/IEC 23270) con lo que Microsoft, aunque lo abandonase, no podía demandar a terceros por ontinuarlo.
- Detrás de C SHARP estaba Anders Hejlsberg arquitecto principal para el equipo que produjo DELPHI.
- Casi a la misma velocidad que avanzaban las versiones del NET FrameWork se desarrollaba el proyecto Mono actualmente impulsado por Novell para crear un grupo de herramientas libres, basadas en GNU/Linux y compatibles con .NET según lo especificado por el ECMA.
- C SHARP, o mejor dicho los lenguajes .NET Disponían de interesante y poderosisimo IDE (SharpDEvelop) http://www.icsharpcode.net/opensource/sd , totalmente gratuito y del cual disponía el código fuente.
- Microsoft habia sacado versiones Express de sus IDE de pago para pequeños desarrolladores, algo impensable años atrás.
Para mí son suficientes, pues continuaba con Microsoft pero si se le ocurría dar un inesperado giro ya no estaba bajo su yugo.
El gran inconveniente...
Después de 15 años programando con Foxrpo me había creado un paquete de clases, herramientas y librerías las cuales me permitían abordar proyectos en tiempo récord, con el consiguiente beneficio.
De la misma manera he tenido que diseñar clases, herramientas y librerías de terceros para abordar proyectos en tiempos récord Mi sorpresa ha sido descubrir que con C SHARP ha sido mucho más rápido conseguirlo, supongo que será por mi experiencia y porque tengo claro lo que quiero.
Los pasos a seguir...
Había que plantearse una secuencia de pasos a seguir u objetivos a conseguir, y estos eran:
- Encontrar, desarrollar y mejorar una librería .NET (compilable a 32 y 64 bits) para acceder de forma nativa a los DBF de FoxPro, poder crearlos y utilizarlos, con lo cual queda resuelta la capacidad del lenguaje para tener un sistema de datos propio.
- Encontrar, desarrollar y mejorar una librería .NET (compatible a 32 y 64 bits) para disponer de un poderoso paquete de funciones para el tratamiento de texto a semejanza de nuestro FoxPro.
- Desarrollar un sistema que me permita la Macrosustitución en C SHARP. .
- Encontrar, desarrollar y mejorar una librería .NET (Compatible con 32 y 64 bits) para disponer de un sistema de reports nativo lanzando los mismos en HTML al navegador o en PDF.
- Construir las aplicaciones en C sharp de la misma manera que se hacía con el Framework de Foxpro.
Con todo ello, estoy cerca de obtener la productividad que obtenía con Fox, y me siento bastante orgulloso por ello.
En el próximo artículo empezaré a desgranar como podemos implantar la filosofía de Foxpro en C Sharp y en nuestras aplicaciones, y cuantas son las similitudes entre estos dos lenguajes. A partir de aquí a nuestro híbrido lo llamaremos C SHARPRO.
No hay comentarios:
Publicar un comentario