Nothing runs like a fox (in the prairie)

No podía terminar esta serie dedicada a los diferentes “grupos de presión” que encuentro normalmente durante las charlas sobre LINQ sin mencionar a uno al que me une una relación muy especial: el grupo de programadores provenientes de FoxPro y que, al menos parcialmente, han comenzado a moverse hacia .NET Framework a raíz del anuncio de Microsoft de que no habrá más versiones del producto (sin bien la versión actual estará soportada hasta 2015).


La relación que me une a FoxPro es especial por varias razones:


a)      Fue el primer sistema con el que empecé a desarrollar cuando llegué a La Habana después de terminar la carrera; si bien aquello no duró mucho, porque al cabo de muy poco tiempo pasé a trabajar con Turbo Pascal y Turbo C/C++, ya más “en mi línea de preferencias” y de los que luego no me desprendería en muchos años.  De aquella época inicial, recuerdo que me inclinaba más por Clipper que por FoxPro, fundamentalmente por dos causas: 1. FoxPro era un intérprete, mientras que Clipper era un compilador a código nativo; y 2. Uno de los creadores de Clipper era Dennis (Denny) Dias, también guitarra solista de un excelente grupo de pop-rock de la época (y que aún sigue “dando guerra”), Steely Dan. No es que fuera mi ídolo ni mucho menos; los ídolos se forjan fundamentalmente en la adolescencia, y yo ya tenía mujer e hijo por aquel entonces. Pero esa combinación de ingeniero de software + guitarrista de rock, con notable éxito en ambas facetas, me inspiró siempre toda la admiración del mundo.


b)      Muchos buenos amigos, con los que tengo una excelente relación y a los que considero excelentes profesionales, utilizaron y siguen utilizando con notable éxito FoxPro.


Dicho lo anterior, debo ahora comentar sobre algunos “tópicos” que escucho frecuentemente con relación a FoxPro:


a)      FoxPro es un sistema de programación de propósito general. En mi modesta opinión, esto no es así. Para mí, FoxPro es una herramienta de desarrollo de propósito más bien específico, orientada al desarrollo de aplicaciones de gestión de bases de datos locales, de bases de datos cliente/servidor (dado el soporte para SQL incorporado al producto posteriormente a su surgimiento) o incluso de múltiples capas (dado el soporte también incorporado para la creación y consumo de servicios Web – ver la serie de posts de Ana María Bisbé sobre este tema y la interoperabilidad entre FoxPro y .NET en general); una clasificación en la que podría caer una buena parte de las aplicaciones de escritorio que se desarrollan hoy día. Según mi modo de ver las cosas, ésta es la causa fundamental por la que Microsoft ha decidido no continuar dedicando esfuerzos al desarrollo del producto – el gigante quiere centrar estos esfuerzos en el desarrollo de sistemas y lenguajes de propósito general.


b)      “Esto de LINQ ya lo tenemos en FoxPro desde hace mil años”. Lamentablemente, esto tampoco es así, según mi opinión. Quienes dicen esto pecan de tener una visión estrecha de LINQ, asociada únicamente a la ejecución de consultas contra bases de datos relacionales. Aquí remito al lector a un post mío anterior relacionado con este tema.


c)       “Esta aplicación con FoxPro yo la desarrollaría en un tiempo X,  y con .NET incluso a un experto le costaría 3 * XV. Podría ser muy cierto, en el caso de que la aplicación a desarrollar fuera del tipo de las aplicaciones para las que fue pensado FoxPro, y especialmente en el caso de un desarrollador con amplia experiencia en el desarrollo de aplicaciones similares utilizando FoxPro. A diferencia de FoxPro, C#, VB y las librerías de .NET Framework (incluyendo las de acceso a datos), así como las herramientas integradas en Visual Studio, sí son recursos de propósito general, pensados para ser utilizados en un contexto mucho más amplio, y no optimizados específicamente para el desarrollo de ningún tipo concreto de aplicaciones.


Es en esta última situación donde se abren diversas alternativas para un desarrollador con tales habilidades. ¿Cuál tomar si se nos presenta un proyecto con esas características? En mi humilde opinión, no es necesario ni recomendable dejar a un lado los conocimientos y habilidades ya adquiridos para mudarse a la plataforma predominante simplemente por el hecho de que “FoxPro ha perdido el apoyo de Microsoft”. Si la aplicación es una aplicación ideal para FoxPro, y no se prevé la necesidad a corto y mediano plazo de hacer un uso extensivo de las facilidades más novedosas que ofrece .NET (WPF, Workflow Foundation, por mencionar dos), probablemente la mejor opción será desarrollar la aplicación con Visual FoxPro, con la consecuente reducción de plazos de entrega y necesidad de aprendizaje “a marchas forzosas”. Después de todo, tampoco es como para “cortarse las venas”: el producto va a estar soportado hasta 2015, probablemente lo seguirá estando algún tiempo más y tiene una amplia base de seguidores que estoy seguro continuarán utilizándolo. Pienso además que bastante antes de esa fecha estarán disponibles herramientas de calidad que facilitarán la migración completa de aplicaciones FoxPro a .NET, e incluso hasta implementaciones completas de compiladores de FoxPro en código manejado, caso de que en el futuro interese acogerse al entorno de ejecución común, y también librerías que permitan acceder de una manera cómoda desde FoxPro a todas las funcionalidades de código manejado, en caso de que simplemente se desee “modernizar” la interfaz de usuario o hacer uso de ciertas facilidades de .NET desde FoxPro. Visite, por ejemplo, http://www.etecnologia.net o http://guineu.foxpert.com (mi agradecimiento a Pablo Roca por los enlaces).

En resumen, que si va a seguir “viviendo en la pradera”, mi consejo es que continúe, al menos de momento, con FoxPro. Nadie ha puesto en duda que, en la pradera, nadie corre como un zorro.

Nota: Como siempre, este post refleja única y exclusivamente mis puntos de vista personales, y no los de la empresa en la que trabajo ni de otras con las que colaboro.


 

Octavio Hernandez

Desarrollador y consultor en tecnologías .NET. Microsoft C# MVP entre 2004 y 2010.

10 comentarios en “Nothing runs like a fox (in the prairie)

  1. Muy bueno el artículo, lo que sucede es que los programas que se realizan ahora mismo tienen muchas mas especificaciones, ya no se pide que se haga un buen mantenimiento y un informe, si no que tienes que enlazar con Outloock, Sharepoint, Sistemas de comercio electrónico, etc, etc.
    Y aunque muchos estan resueltos, algunos son dificiles de implementar, y todos sabemos que apostar por este lenguaje hoy en dia es un suicidio, el problema es que aquellos programadores que realizaban ciertas tareas sobre todo las relacionadas con datos que han pasado a .net se encuentran con una herramienta que en muchos aspectos deja mucho que desear, si vemos por ejemplo como funcionan los dataset y otros relacionados con los datos. A estos desarrolladores no les queda mas remedio que perder el tiempo en desarrollar soluciones para ciertos aspectos que en fox estaban resueltos y se preguntan cosas como y porque no integraron Fox en .net, al igual que con tantos lenguajes como Cobol, es increible que hayan abandonado un parque de tantos desarrolladores sin haber ofrecido al menos una solución mas adecuada en cuanto al manejo de datos, que al final es uno de los aspectos mas utilizados en la mayoria de las aplicaciones que desarrollamos.

  2. Hola, Juan!

    – Indudablemente, la necesidad de integración con SharePoint u Office aconsejaría una migración a .NET…
    – Efectivamente, yo también pensé alguna vez en por qué no se hizo una integración con .NET, un FoxPro/CLI… Tal vez falta de visión del equipo, o tal vez que no vieron la forma de librarse de COM… Esperemos que alguien lo intente en un futuro cercano.

    Saludos – Octavio

  3. Cuando .NET era una versión Beta, tuve la oportunidad de preguntar porqué no se integraba FoxPro a .NET o si había planes para hacerlo, y la respuesta era un simple NO.

    No querían hablar de FoxPro en .NET ni por asomo.

    Desconozco si era por complejidad o por falta de interés como apuntas Octavio, pero en mi opinión (y lo saben bien muchos usuarios de FoxPro y de Comunidades como PortalFox.com), creo que fue un error el no integrar a FoxPro dentro del paradigma .NET.

    Abrazotes.

  4. La pena, es que no hayan aprovechado los recursos que tenian, al menos para mejorar .Net, en esos aspectos en los que foxpro tenia algo que aportar, los que venimos de este lenguaje hechamos de menos varias cosas, el acceso a los datos, que en mi caso se realizaba a traves de vistas contra Sql Server, la velocidad de compilación, su herencia visual y la facilidad del lenguaje, creo que el EDM nos ofrecera una solución mas robusta en cuanto al manejo de datos, pero otros aspectos en .Net estan desgraciadamente a años luz de este producto, por eso cuando desarrollamos en .Net siempre pensamos porque tenemos que invertir mas tiempo en hacer algo que antes estaba resuelto, y mucha gente se ha encontrado abandonada porque la alternativa en este caso “.net, delphi y otros” suponian un cambio radical y muy costoso.

    La decisión de dejar foxpro a sido reciente, pero todos sabiamos que Microsoft no apostaba por este producto desde hacia muchos años. En cualquier caso Microsoft ha abandonado tambien otros productos como “Visual Basic” que si bien tiene continuidad en .net, no tiene nada que ver.

    Jorge asi es, no querian ni hablar de foxpro, nunca supimos porque, pero se palpaba en el ambiente, desde la versión 3.0 fueron abandonando este lenguaje paulatinamente.

    En fin, muchos pasamos a .net hace varios años y otros lo estan haciendo ahora, desde luego son arquitecturas mucho mas complejas que nos aportan infinidad de soluciones y que pueden hacer casi cualquier cosa. Aún asi hecharemos siempre en falta, la velocidad y robustez de nuestro querido fox.

  5. (Con el tiempo suficiente 🙂 sería interesante reconstruir la historia de cómo se llegó al modelo de acceso a datos que tenemos hoy y cómo se abandonó el modo “conectado” (basado en cursores) en favor del desconectado. Probablemente a partir de ese momento FoxPro quedó “condenado”…

  6. Octavio, no creo que eso fuera la razón. Siempre es posible hacer una abstracción para ofrecer un modelo desconectado bien sea con FoxPro, Clipper o dBase. Al final y al cabo es una fuente de datos.

  7. Yo recomiendo a los foxeros que aprendan .NET lo más pronto posible, lo cual no implica dejar a VFP. Es cierto que el trayecto es tortuoso en algunos aspectos pero uno termina finalmente descubriendo que, al menos con C#, las cosas merecen el esfuerzo. Hay que pensar en el mercado y futuro de la programación, que aunque no podamos preverlo, es importante estar preparados en el carril menos riesgoso.

  8. Anónimo,

    Puede que tengas razón, lo decía porque me parecía que FoxPro estaba demasiado “atado” al modelo basado en cursores, pero hace mucho que le perdí la pista, no estoy al tanto de las cosas que se fueron introduciendo desde hace bastante… Lo que sí pienso que no hubiese tenido mucho sentido hubiese sido crear un nuevo FoxPro en el que todo el acceso a datos fuera diferente…

    Ricardo,

    Creo que has expresado exactamente lo que yo quería decir, aunque hice más énfasis en la vertiente de “no dejar FoxPro” que en la de “aprender .NET lo antes posible”. ¡Gracias!

  9. Bueno amigos, primero quiero felicitar a la persona que hizo este articulo, esta muy bueno. En mi humilde opinion al igual que muchos foxeros, tenemos claro del poderio y las facilidades que foxpro tiene en su actualidad y mas aun los que como yo necesitamos aun mas profundizar ventajas de foxpro que aun no hemos utilizado.
    No obstante es una realidad presente que desde los inicios de lo que es el desarrollo de .net habia una sentencia clara a lo que foxpro se refiere, y parte de las cosas que microsoft dejo clara en ese entonces fue el desarrollo de esta nueva tecnologia iba estar apoyado y forzando a todos los que utilizamos su tecnologia para que fueramos en esa via de utilizar .net como parte de las herramientas de desarrollo en el futuro.
    Yo creo que simplemente tendremos una division en cuanto al desarrollo de las aplicaciones en el futuro, y como bien dice en el articulo se haran aplicaciones centradas en lenguajes como foxpro para empresas que no tengan ese tipo de necesidad y otras que tendran requerimientos basados en la facilidad y ventaja que tiene .net
    No creo que haya necesidad de abandonar por completo a foxpro que tantas cosas buenas hemos aprendido con los anos con el, pero si ir aprendiendo a desarrollar en otra herramienta como .net (en mi caso c#) para estos requerimientos que tienen algunos de los casos que se nos presentan en nuestro diario vivir.

    Y de esta forma fortalecernos mas como desarrolladores de soluciones de negocios. Saludos foxeros.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *