OT: Recuerdo de la Cruzada entre VB y VFP

Por fin he recordado y revisando mis archivos de mensajes anteriores.
Otro que ya no anda muy seguido por aqui es:

Alexandre Hedreville

El cual, con su Cruzada VFP me dejó anonadado. Y continuación me tomo la
liberta de volver a postear dicha cruzada, este documento me pareció de
lo mas "sensato" y profesional, con un toque de sentimiento. Lo coloco
para aquellos que con la última caida del servers de news de microsoft,
perdieron el post o aquellos que van empezando y no alcanzaron a verlo.


*--* * -- * --
Subject: Cruzada VFP
From: Alexandre Hedreville
Date: 13/03/2002 10:19 am
NewsGroups: Microsoft.public.es.vfoxpro

Tras tanto debate entre VB Y VFP...

Quisiera abrir mi propia cruzada... no tanto en contra de VB... si no a
favor de VFP..

Creo que la forma de defender VFP no pasa por atacar a VB si por mostrar
los puntos en los que esta herramienta es imbatible.Los puntos en los
que ridiculiza y hace frente a VB y mostrando las cualidades que la
hacen única y le otorgan ventaja económica o técnica..

Yo no me opongo a VB.. (ni a mí se me ocurriria, ni Microsoft me lo
permitiría), así que si alguien espera que en estas líneas se hable de
VB como si fuera un moro infiel que hubiese que cristianizar aa todo
trance, nada más lejos de mi intención.

Aunque considero que VB es una buena herramienta, EN EL DESARROLLO DE
APLICACIONES DE ESCRITORIO tiene grandes lagunas...

Es en estas lagunas donde VFP se muestra muy superior y por eso me
gustaría exponerlas

1º No tiene un lenguaje de bases de datos SQL embebido:
Pará qué, me dirás... puedo usar otras cosas...
Cosas como por ejemplo el DAO... ah! nó... que eso ya está obsoleto
despues de no se cuantos bugs y revisiones
Cosas como por ejemplo lo que había antes de DAO... ah! nó...
hombre... que ya tenemos el ADO
Ah!.. Sí... el famoso ADO... Vale, por fin funciona y parece que ya
es estable.. trabajo nos ha costado sr Microsoft...
Anda tú... que si no hubiesemos podido vender ninguna aplicación
desde los días de Foxpro DOS (que... fíjate tú... ya incorporaba SQL
embebido) hasta que hubiesemos tenido el ADO por la versión 2.0.. ó 2.5,
hubieramos tenido que vender rosquillas a la salida de los colegios...
DESAGRADECIDOS QUE SOMOS CON FOXPRO... el que nos ha venido dando
una potencia inagotable con su SQL embebido, potencia que ahora años
despues empiezan a rozar los demás lenguages con ADO...
No.. no.. desprecio ADO... ,es un buen invento..., si nó que
haríamos en las ASP... pero es que el SQL embebido de VFP da muchísimo
juego como para no echar de menos el ADO en las aplicaciones de

Por cierto, que se monta cada escabechina cada vez que alguien te
instala una runtime de ADO diferente a la que espera tu programa en VB,
que deja de funcionar cada dos por tres...
Es decir, que como te instalen un progama demo o shareware con una
libreria de ADO distinta a la que isntaló tu programa... RING.. RING...
RING... SI DÍGAME... ya te veo al teléfono dando soporte técnico

2º No tiene una base de datos nativa
Pará qué, me dirás... puedo usar otras cosas...
Si, pero tendrás que pagar por ellas... ¿o es que el SQL Server lo
regalan?
Bueno... puedo usar Access... dirás...
¿Pero acaso alguien es tan IGNORANTE e INSENSATO (lo pongo en
mayusculas y me reafirmo en ello) al comparar con las bases de datos de
VFP con las de Access?
Access no tiene procedimientos almacenados propiamente dichos...
No tiene la gestion de eventos de VFP...
No puede enlazar funciones de usuario a los campos de las tablas,
Su integridad referencial es irrisoria, por decir que la implementa,
mientras que VFP tiene una IR que si incluso no te gusta la puedes
sustituir por el código hecho a medida que te plazca.
Y la gestión de índices... no puedes usar funciones de usuario en
los indices. Algo tan simple como INDEX ON UPPER(Nombre) no es posible
en Access..
¿Te crees que realmente eso es admisible?.. Por no hablarte de la
velocidad, etc...
Ya... Ya... me dirás, pero tu tienes que hacer PACK porque te quedan
registros DELETED...
Vamos a ver... Si Access hace lo mismo, solo que lo oculta...
Como no reorganices la bases de datos verás tu a ver que rápido se
degeneran al hacer movimientos.
En access tienes que hacer PACK, solo que alli se llama reorganizar
o compactar pero el sentido es el mismo...
Esto en este aspecto pone a Access al mismo nivel que VFP... en
algún momento del día, mes, o año has de parar la aplicación para hacer
un PACK.
Ya... Ya... me dirás, pero las tablas de VFP se rompen más que las
de Access...
Bueno... en Access no puedes sustituir una tabla solamente, ya que
todas estan en el mismo fichero MDB (por lo que si pierdes una tabla en
access, mira a ver tu que va ha ser más grave, que pierdas una tabla o
que pierdas todo el .MDB porque una tabla ha fallado) en VFP siempre
puedes copiar y o sustitir el fichero físico de la tabla que va mal y
carretera... a funcionar...
Tambien puedes usar el MSDE...
Por cierto, si ánimo de cachondeo (je, je..). ¿Cuantas casas de
programación o desarrollos de software se han tomado el MSDE como
plataforma de real de trabajo, venta o producción?...
¿Acaso el MSDE ha pasado de las mesas de prueba al escritorio de los
clientes?
Pero si persistes en desarrollar en Access, comprate tambien una
licencia de Access por desarollador ya que crear las tablas de Acces
desde el IDE de VB es una pesadilla que no te quiero ni contar... A la
larga es más caro desarrollar con VB que con VFP

3º No tiene el concepto de clases y POO extenso
¿Has hecho alguna clase con herencia, polimorfismo, etc. en VB?...
VB no sabe ni lo que es eso...
Estoy hablando de clases en el sentido amplio del termino y no la
chuminada de hacer unas plantillitas de controles
¿Que sería de los programadores de C++ si no usaran clases?..
¿Que sería de los programadores de VFP si no usaran clases?...
Tendriamos que rehacer centenares de lineas de código cada vez que
tuviesemos que hacer una modificación.

4º Su lenguaje es un poco caótico...
Vamos a ver...
¿Como se retorna un valor desde una función en JavaScript?.. con
RETURN..
¿Como se retorna un valor desde una función en C?.. con RETURN..
¿Como se retorna un valor desde una función en VFP?.. con RETURN..
Y ¿en VB?...
¿Como se retorna un valor desde una función en VB?.. con una
asignación tal que así: NombreDeFuncion = ValorRetornado...
Pero bueno... ¿ Porqué no usamos RETURN como todos los demás?...
Cierto que esto no es algo muy crítico o grave.. pero yo voy al
hecho de que VB tiene UN LENGUAJE PLAGADO DE COSAS RARAS.
Tanto es así que no me extrañaría que aún subsistiera el famoso
GOTO del GWBASIC... (que tiempos aquellos... os acordais MKD$, OPEN FOR
INPUT #1 aquello si que era programar y no como ahora, todo a base de
dibujitos y controles)
¿Quereis ver cosas mas raras de su lenguaje?...
Por ejemplo una instruccion tal que así... IF Condicion1() AND
Condicion2() AND Condicion3() AND Condicion4() THEN
Para ejecutarla VB es tan tonto que ejecutaría las 4 funciones,
desde Condicion1() hasta Condicion4(), aúnque la primera función,
Condicion1(), fuese falsa.
En cambio VFP, que es muy listo, (je, je) pararía de ejecutar
funciones en cuanto una de ellas devolviera falso...
Anda fíjate tú... aúnque VFP no es compilado... mira que bien... es
más listo y rápido que VB porque sabe cuando debe parar de evaluar...
Pero... ¿Es esto algo único e inimitable de VFP?... No... C++,
JavaScript, Java y un etcetera de lenguajes hacen lo mismo que VFP
No... si cuando digo que VB es un lenguaje raro y caótico...
Es más se dice que VFP no genera un EXE en el termino de EXE puro y
duro, que si interpretado, que si patatin... que si patatan...
Pero ni falta que le hace...
Vamos a ver... ¿Que haríamos nosotros si no pudiesemos ejecutar
macros con la famosa &?...
Eso solo es posible y gracias a que VFP no genera exes puros y
duros y no por ello es más lento que VB.
Si el caso, no es usar la fuerza bruta, más vale maña que fuerza, y
en eso el lenguaje de VFP gana al VB..
Ademas el no generar exes puros en el sentido de la palabra (por
cierto que el VB tampoco los genera. Podríamos decir que genera exes más
exes que los de VFP pero tampoco son realmente exes... exes, siguen
necesitando una runtime) nos permite ejecutar secciones de codigo al
vuelo...
Código generado ON THE FLY según lo vaya necesitando el propio
programa... Imginaos... el propio programa puede escribir sus rutinas
compilarlas y ejecutarlas... TODO EN TIEMPO DE EJECUCION... esto no lo
puede hacer el VB ni de coña...
AH! ¿y que tal el control de errores en VB?
Brilla por su ausencia, de echo hasta el VBScript sigue padeciendo
estos mismos problemas... (pero Microsoft se empeña en usar Basic hasta
en la sopa).
Menos mal que frente a VBScript aún nos queda JavaScript y ahí la
cosa mejora en cuanto al control de errores.
Vamos a ver.. en VB ¿aún seguimos con el obsoleto ON ERROR RESUME
NEXT?...
¿Pero habeis indagado las DECENAS de posibilidades para controlar
errores que da VFP?...
ON ERROR... etc... ¿y para recuperarse de un error?... RESUME,
CANCEL, RETURN, RETRY... etc...
Y aquí no se acaban las cosas.. casi todo objeto y control tiene un
método que se puede programar para interceptar el error generado por el
objeto...
Vamos.. incluso Microsoft sabe que esta es una laguna grave de VB y
en JavaScript hansentido verguenza y al menos ya han programado un TRY..
CATCH...

Lo mejor del lenguaje de VB es la declaración de variables, sus
tipos y las struct para acceder a la API de windows... BRAVO AHÍ

Pero eso no quiere decir que desde VFP no se puede acceder a la
API... se puede, solo que cuesta mas... Y ademas en cuanto a la
declaración de variables y sus tipos VFP 7 va mejorando en cuanto a
eso...

4º El IDE de VB es mejor que el de VFP
Cierto... BRAVO AHÍ CHAPEAU... ahí hay que decir que es mejor el IDE

VB que el de VFP...
Pero honestamente, no se debe al lenguaje en sí mismo...
Es decir, el entorno de desarrollo no es el lenguaje y lo que yo
critíco aquí es el lenguaje. Digamos, el motor del producto, no la
carrocería
El IDE de VB es mejor, porque microsoft ha invertido mucho más
dinero en él.
VALE LO ADMITO EL IDE DE VB ES MEJOR QUE EL DE VFP
PERO NO CAMBIO LA VENTANA DE COMANDOS DEL VFP NI POR LA MITAD DEL
IDE DEL VB
Y es que la ventana de comandos, es una pasada
Vamos que si Microsoft implementa una ventana de comando en el IDE
de VB me paso a VB..(je.. je.. crédulos)

5º Su futuro...
¿Como?... TU.. UN DEFENSOR A UTRANZA DE VFP, ¿OSAS PONER EN DUDA EL
BRILLANTE FUTURO DE VB?...
Vamos no te acalores deja que te explique...
Vamos deja que un foxero te explique esto del futuro incierto de tu
herramienta de desarollo.. que los foxeros sabemos bien y por desgracia
sobre esto de tener una herramienta de desarrollo con un futuro incierto.
El futuro... porque microsoft quiere pasa por la plataforma .NET
Que bien... ya tienes VB .NET..
El problema es que VB . NET es radicalmente distinto a VB... tanto
en controles como en conceptos, por fin soporta clases, etc...
Para que lo entiendas... si viniste de programar en Clipper o en
Foxpro Dos cuando llegaste a VFP... ¿como te fué el cambio?..
El cambio de conceptos fue inmenso y brutal... apenas pudiste
aprovechar los viejos métodos de hacer las cosas.
Tuvimos que cambiar nuestra mentalidad por completo y adecuarla a la
nueva herramienta, al nuevo entorno de trabajo y al nuevo modo de trabajo.
Aunque teniamos conversores y transportadores... no nos sirvieron de
nada.. tuvimos que rehacer todos los formularios de nuevo...
Las herramientas de migracion de Foxpro Dos o Foxpro Win no nos
auxiliaron mucho en este proceso...
Pues... quiero que entiendas que lo mismo te sucedera al migrar de
VB 6.0 a VB .NET
NO CREAS POR LO MAS REMOTO QUE VA A SER ALGO TAN SIMPLE COMO COMPILAR

LISTO...
MUCHO ME TEMO QUE VAS A TENER QUE REHACER DE NUEVO LAS APLICACIONES
SI QUIERES QUE TE QUEDE ALGO DECENTE


Cabría exponer muchos otro puntos más...
Pero como ya he dicho al principio, esto no es una cruzada contra VB, es
más bien una defensa de VFP... ya que VB ya tiene quien lo defienda...
Creo que con estos puntos se pueden tomar decisiones en cuanto
implementar aplicaciones de escritorio, porque en el entorno de
Cliente/Servidor y de internet hay otros factores más importantes a
tener en cuenta que si se elije VFP o VB como herramienta de desarrollo,
ya que en esos otros entornos la herramienta de programación carece, por
así decirlo, de importancia crítica frente a otras consideraciones..

En fin. VB es una excelente herramienta pero NOTHING RUNS LIKE THE

Saludos, Alexandre Hedreville


777


Esparta Palma wrote:

>
> Hola compañeros, este Off Topic es para ver si alguien sabe que es lo
que ha pasado con esos personajes tan concurridos por este medio y que
por alguna razón "X" ya no estan en constante comunicación, para saber
si estan bien y cómo les ha oido.
>
> Quizas soy uno de los que tiene poco tiempo por aquí (aprox. 1 año y
medio), pero recuerdo a varios colegas que me han ayudado ya sea directa
o indirectamente con su experiencia, entre ellos (y quizas por fallas en
mi memoria principal) menciono algunos:
>
> Alex Wieder
> Martín Soto
> Leonardo Daniel
>
>
>
> Sé que otros mas tendran a alguien perdido, sería buena idea
colgarlos de este thread.
>

Apoya a Visual FoxPro usándolo legalmente
¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º
Espartaco Palma Martínez
SysOp PortalFox ( http://www.PortalFox.com )
email:
Acapulco, Guerrero. México