Hola, Ricardo.

>Comparto 100% con lo que decía tu profesor con respecto a la programación y los lenguajes.
>Pero creo que son cosas diferentes, la pena y lastima es que firmaron el certificado de defunción de VFP, no hay problema de criterio en trabajar y aprender una o mas herramientas nuevas.
>La pregunta es por que sacan a VFP cuando tiene un grado de madurez como lenguaje muy bueno y una comunidad excelente atrás de el.

Creo que estás mirando la mitad vacía del vaso. Dado que el core del producto está tan maduro, y que la mayor parte es ahora código VFP cuyos fuentes están liberados, más los fuentes de Sedna que también lo estarán, más todas las extensiones de VFP X, en realidad se puede valorar la mitad llena, que es que VFP no está muerto, y que desde ahora está principalmente centrado en cómo lo desarrolle la comunidad, y respaldado por 8 años más de soporte.

>No lo se, capaz que se para no competir internamente con VB.NET.

Si hablamos a nivel de recursos internos, podría ser. Piensa que el equipo de VFP quedará liberado después del release de Sedna y el SP 2 para dedicarse full-time (ya lo hace parcialmente desde hace bastante) a mejorar VB.Net, principalmente claro, en el área de manejos de datos.

>El ejemplo de VB es relativo, ya que VB.NET es una extención de VB, creo que en este caso no eliminas al lenguaje como el ejemplo de VFP, si no que "invitas" a la comunidad VB a que pase con una curva de aprendizaje más corta a .NET

La verdad es que la comunidad de VB fue empujada muchísimo más fuerte a pasarse a .NET, y para muchos la curva de aprendizaje ha sido peor de lo que puede ser para un desarrollador VFP que haya aprovechado realmente sus características OOP. La comunidad VB la pagó siempre mucho más caro que la de VFP desde el punto de vista de actualización entre versiones.

>Leíste la nota de UT Mag marzo de Les Pinter ? Me pareció muy interesante.

Realmente tomaría los comentarios de Les con cuidado. Muchas de las dificultades que menciona no me parecen tales, y me parece más un problema de comprensión de la plataforma. Aunque el manejo de datos es muy diferente, me parece exagerado decir que es mil veces más complejo; no es cierto que necesites el Enterprise Manager para generar datos de prueba (por cierto, esta herramienta no existe más en SQL 2005); la instanciación de objetos es mucho más prolija, controlada y natural en .NET que en VFP, si comprendes bien el sistema de tipos; el tema de la macro-sustitución tiene equivalentes en .NET, aunque en cualquiera de ambos ambientes es algo que se debe manejar con cuidado, etc.

Es cierto que muchas cosas podrían ser más sencillas en .NET (comparadas con VFP), y algunas están mejorando en las próximas versiones, pero también es verdad que hay muchas cosas que son más complejas o prácticamente imposibles en hacer en VFP. En resumen, cada plataforma tiene lo suyo. Dependiendo del tipo de aplicación, una puede ser mejor opción que la otra, pero no se pueden comparar generalizando.

Para mi lo importante es no tomar este tema del !VFP 10 a la tremenda. Yo me concentraría en pensar todo lo que la comunidad puede hacer con él.

Saludos,
/ms