Visual Foxpro vs. Visual Basic

Antuan
26 de Junio del 2009
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 escritorio.
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Í CHAPEAU...
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 de 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 Y 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 FOX....





Baltasar
26 de Junio del 2009
¿qué has conseguido?
Yo hace años comencé con pascal, cobol, luego Dataflex, Clipper (uno de mis preferidos), C++, Delphi y de momento Visual.
COnozco algunos más, pero estos son los que realmente me han dejado satisfecho.
Y después de conocer estas herramientas, es que me atrevo a afirmar que lo importante, lo que realmente hace que una aplicación sea buena, no es la herramienta: es el programador. Pon en manos de cualquiera el FOX, y déjame a mí el clipper, tan obsoleto y tan arcaico; te atreverías a afirmar que mi aplicación sería peor? Yo no me atrevería jamás, a apostar por ninguna de las dos herramientas, sin antes saber de lo que es capaz el programador.
Repito, un lápiz es un trozo de carboncillo metido dentro de un trozo de madera. SI se lo das a un escritor, puede convertirlo en poesía; si se lo das a mi hija de tres años, te deja las paredes decoradas.

Saludos.