jueves, mayo 01, 2008

To Be(sual) or Not To Be(sual)

Esa es la cuestión...... Visual o no Visual.

Tengo haciendo programas en Clipper desde hace mas de 20 años, desde tiempos del Summer'87 (sí, sí, son un Clippersaurio) y poco menos de la mitad de esos 20 años me he dedicado a hacer programas para Windows, Primero con FW desde Windows 3.1, Windows 95, 98, ME, 2000y así hasta Xailer con Windows XP y Windows Vista, tengo que reconocer que hasta hace menos de 3 años mi conocimiento sobre lenguajes de programación basados en herramientas visuales era muy poco.

Hace 10 años, cuando publicaba la revista Clipper Plus, me habría sorprendido mucho lo que el día de hoy estoy escribiendo, que sin duda será "tragarme" mis palabras de hace 10 años.

Hace 10 años hablaba en mis artículos de temas de programación para Windows sin depender de ningún "Visual" algo, claro, después de una traumática experiencia con "CA-Visual Objects", no me quedaron muchas ganas de seguir trabajando con ningún "visual" de ninguna marca o fabricante, mi idea era mas la de la programación procedural, "a lo Clipper" y en su momento hubo algunas herramientas que me permitieron seguir programando para Windows usando el lenguaje Clipper que ya sabía y dominaba, herramientas como DolceVita, que fue el primer intento de hacer una librería para desarrollar aplicaciones para Windows con Clipper, dBFast, ese si que era un buen producto, muy corto de pretensiones, pero la idea era muy buena, por su puesto pasé por Clip4Win (eramos distribuidores de Grupfish Inc en aquellos felices días), aunque en aquellas primeras versiones se programaba a punta de funciones y que había que hacer 1000 lineas de código para generar una sola ventana que dijera "Hola Mundo", la programación Orientada al Objeto vendría 2 versiones después; hasta que finalmente llegué con un producto que me acomodó y me gusto: FiveWin, Clipper para Windows tal como estaba acostumbrado a programar, es decir, a buscarme la vida escribiendo mi propio código para todo.

Y yo como muchos programadores de Clipper me quedé ahí muuuucho tiempo, mientras todo al mi alrededor se movía y evolucionaba por los derroteros de los "VISUALES", y yo veía como se me iba algún cliente porque caía seducido por una aplicación en Visual Basic o en Delphi, incluso muchos de mis clientes que se dedican al desarrollo de aplicaciones a nivel comercial me abandonaron en pos del sueño "visual", y pensaba para mi mismo en una mezcla de sentimientos encontrados: Frustración por un lado, y enfado por otro..... "pero volverán" ... y adivinen que ..... ¡ NO VOLVIERON !.

¿ Y saben que fue lo peor de esta experiencia ?, no fue la perdida de clientes, afortunadamente muchos de mis clientes me siguieron; hoy todavía conservo clientes desde 1994, que fue en el año que empezó operaciones formales CiberTec.

Lo mas frustrante de la experiencia, fue que los que se fueron parece que no estaban equivocados, que el equivocado era yo, y mis conceptos de "control absoluto" los cuales se enfrentaron a conceptos como "velocidad de desarrollo" y mientras yo tiraba líneas y líneas de código para hacer una ventana, ellos simple y sencillamente tiraban 2 clicks del ratón presionaban un botón, y..... ¡ abracadabra !, una ventana.

Ahora me doy cuenta de una cosa, dado que la tecnología avanza a pasos agigantados, los lenguajes de programación también tendrían que haber avanzado, cada vez tenemos mejores equipos de cómputo, por ende deberíamos tener mejores lenguajes de programación para hacer mejores programas ¡ y los tenemos !, tenemos lenguajes potentes como Java o C, y sin embargo estos lenguajes se pueden programar "a pie", tirando líneas y líneas de código como enajenado, pero también se pueden utilizar con un IDE y programar de manera visual y eso no le quita el menor mérito a las aplicaciones finales.

¿ Como llegué a tan sesuda conclusión a estas alturas del partido ?, pues después de darme cuenta que los "Visuales" no pueden ser tan malos, si lo fueran.... ¡ no habría tantos !, Visual Basic, Delphi, Visual FoxPro, Visual Studio, Eclipse, Visual J++, Visual C++, Visual Objects, Xailer, Visual xHarbour, Visual xBase++..... ¿ realmente estarán equivocados todos esos fabricantes de "visuales" y los que programamos no visual somos los que estamos en lo correcto ?.... humm... va ser que no.

Borland te regala el Compilador Borland C++ que es el que la mayoría usamos para compilar con (x)Harbour, sin embargo lo que Borland te regala es solo una parte pequeña de un producto mas grande que es el C++ Builder (este es comercial y se vende), un entorno integrado de desarrollo, con IDE, diseñador de pantallas, Debugger, etc, etc. etc..... en este punto me pregunto.... ¿ cual aplicación es mejor ?, la que esta hecha con miles de lineas de código hechas a mano para hacer una ventana con C puro y duro, o aquella que fue hecha usando el IDE que viene incluido con el mismo lenguaje de programación; al final de cuentas el resultado en pantalla será el mismo, y quizá a el código fuente de ambas será muy parecido, si bien el código escrito a mano estará mas optimizado, apuesto a que el 70 u 80% del código sera muy similar entre lo que el programador no visual escribió y lo que generó la herramienta de desarrollo visual.

Otro ejemplo, el Pelles C... que es un compilador completo de C++, un clon del Visual C de Microsoft, y ¿ que parte es la que el programador de FiveWin usa de esta poderosa herramienta ?..... ¡ el editor de recursos ! y alguno que otro el compilador de recursos, ambos forman parte de un todo, y sin embargo nos limitamos a tomar una o dos partes pequeñas de ese todo y usarlas, cuando podríamos aprovechar y usar toda la herramienta.

Ahora bien, yo pienso que hay lenguajes que no fueron diseñados para tener una parte de desarrollo Visual, Clipper es uno de ellos, ¿ Alguien se acuerda del IDE de Clipper 5.3 ?, la idea no era mala, el problema era la ejecución, el diseñador de pantallas apestaba, hacía código innecesario, lo que tu hacías con un @ ... BOX, el IDE lo hacía con 20 líneas de código, y luego el código era totalmente ilegible por el programador Clipper "comandero", porque no usaba comandos en absoluto, todo eran llamadas directas a las funciones y a los objetos hasta el día de hoy, 15 años después del lanzamiento de Clipper 5.3, no conozco a nadie que utilice el IDE.

Sin embargo, hubo una herramienta para Clipper, un generador de aplicaciones llamado Zachary, que era un sistema de desarrollo visual para Clipper, tu ibas diseñando el diccionario de datos, diseñando las pantallas a partir de los datos y luego Zachary iba escribiendo el código en Clipper para MS-DOS, y no creas que chapuzas de código, no no no, código bien optimizado y funcional, sin duda una de las herramientas mas finas que haya yo usado, el abuelo de los IDEs y visuales de la actualidad.

También hay lenguajes que nacieron con el IDE en la cabeza, como Visual Basic o Delphi, es decir, la estructura y componentes del lenguaje se diseñaron para poder soportar una herramienta de desarrollo visual, para esto colaboró enormemente el paradigma de la Programación Orientada al Objeto.

POO y desarrollo visual son conceptos que hacen "click", no es lo mismo escribir :



Que hacer lo mismo pero de modo visual:



Es decir, ¿ para que voy a escribir código, si tengo algo que lo escribe por mí ? y me permite ver como va a quedar mi browse desde tiempo de diseño. El resultado del código generado por el diseñador visual es este:


Algo muy similar a lo que yo hubiese tenido que teclear si lo hubiese hecho a mano.

Los lenguajes orientados a objetos tienen esa ventaja: Mediante una herramienta visual, puedes asignar desde tiempo de diseño propiedades y eventos y la manera en que quieres que se vea o comporte un objeto, dejándote tiempo al no tener que volver a escribir código para integrar el diseño visual en tu código fuente, el diseñador lo hace por tí.

To Visual or not to Visual, That is the question......

Los lenguajes no visuales están muy bien para aprender como se debe programar, te dan lógica, estructuración de pensamiento y disciplina, yo le agradezco mucho al Pascal y al C por haberme enseñado lógica de programación, y por su puesto hay cosas que no sería posibles hacerlas con un visual, si yo necesito leer un puerto serie, entonces lo mejor es escribir esa rutina de lectura en lenguaje "C" y posteriormente integrarla al entorno visual, si yo voy a escribir un sistema de contabilidad, sería una locura hacerlo en "C" puro y duro, me llevaría un montón de tiempo, a menos que utilice la herramienta visual incluida con el C.

A pesar de su alto valor didáctico, los lenguajes de programación no visual, son buenos para muchas cosas pero muy malos para otras tantas porque carecen de una cosa MUY importante para los tiempos que vivimos: VELOCIDAD DE DESARROLLO.

La tecnología avanza demasiado rápido, de los tiempos del Clipper Summer 87 al año 2008 ¡ han transcurrido 21 años ! ¿ porqué entonces seguir usando tecnicas de programación que de hace 20 años ?, si ahora tenemos objetos, es todo un mundo nuevo, mas eficiente, complicado de entender si no te haz actualizado, pero el futuro está ahí, en la programación Orientada al Objeto.

El punto es que dada la velocidad en que avanza la tecnología de hardware, existe la urgencia de desarrollar aplicaciones de software mas rápido, para llevarle el paso al avance tecnológico, esa misma necesidad ha llevado al desarrollo de herramientas que permiten hacer aplicaciones mas rápido: Los visuales, tonto de mí, no supe ver esto hace 5 años.

Desconozco la estadística, pero quiero pensar que por lo menos 7 de cada 10 programas de software que se utilizan actualmente en el mundo están hechos con una herramienta visual, lo que nos lleva a pensar que 7 programadores de 10 son muy listos, y hacen software mucho mas rapido que 3 que programan en un entorno no visual.

Una cosa que me han comentado muchos programadores de los "Visual Algo" que conozco: Los que han programado en un lenguaje NO visual antes, difícilmente regresarían, el resto no sabe siquiera que es un lenguaje de desarrollo no visual, usan Delphi, pero no saben que hay un Pascal que no es visual, o usan Visual Studio, pero no se meterían a hacer nada en C puro y duro.

Yo me llevaba muy mal con los visuales, hasta que comencé a conocer las bondades de los mismos, me ha llamado mucho la atención cosas como la tecnología RAD (Rapid Application Development), todavía estoy reacio a que un programa escriba código por mi (el programador soy yo, se supone que yo deba de escribir el código), pero al darme cuenta que muchas herramietnas escriben código mas optimizado de lo que haría yo, ahorrandome con esto tiempo y esfuerzo, pues no me queda mas remedio que darle la razón a tanta gente que utiliza herramientas visuales.

Por otro lado, hay que reconocer que para aplicaciones para el usuario final, los visuales son una muy buena y rápida opción sin embargo, para progarmación a "bajo nivel" manejo de dispositivos, puertos, almacenamiento etc, lenguajes no visuales como el C siguen siendo los reyes del bajo nivel.

¿ Así que porqué no darle una oportunidad a una herramienta visual ?, solo por probar digo yo, total, si no nos gusta pues siempre podremos volver al desarrollo no visual, pero si nos gusta lo que no nos gustará será tener que regresar, es si es un viaje sin retorno.

5 comentarios:

Walter Negro dijo...

En los estudios secundarios me recibí de técnico electrónico. Una de las materias del último año era Televisión. Dada la complejidad de un televisor y su relación con casi toda la gama de temas de electrónica, ameritaba la existencia de una materia de dedicada exclusivamente.
Las señales dentro de un televisor son muy variadas y la herramienta por excelencia para descubrir problemas es el osciloscopio, que representa en una pantalla la señal en su forma gráfica, sin embargo, el profesor nos enseñaba mucho más a usar el voltímetro, porque "en muchos casos la única herramienta que dispondrán es un voltímetro y eso les deberá alcanzar para encontrar la mayoría de las fallas".
Ese profesor enseñaba a usar la herramienta (osciloscopio) pero más nos enseñaba a pensar.

Uno de las principales contras de la "programación visual" es el atrofiamiento mental que produce a quienes comienzan directamente a programar usando un IDE o RAD.
Las herramientas visuales deben usarse como eso, como herramientas, de ayuda y no como addons del cerebro.
Hoy tenemos IDE donde no hace falta cerrar las estructuras ni los paréntesis ni las cadenas de caracteres, donde no hay que recordar parámetros ni tipos y hasta asistentes que nos traen buena parte de código y sólo hay que escribir un poco.
Y esto esta muy bueno, en manos como herramienta, pero cuando se transforma en addons cerebral, un encargado de seleccionar personal puede pasarse muchos días hasta encontrar una persona que al menos piense un poco.
Que las universidades enseñen a programar usando herramientas visuales es un desprestigio para una casa de estudios que tiene que enseñar a pensar.
Si 7 de cada 10 programadores usan herramientas visuales, quizás 1 de cada 20 no lo use como addons cerebral.
Y esto lo digo después de haber participado en la búsqueda de personal para lenguajes relacionados con xBase y para C/C++.

Rene Flores dijo...

Walter:

Me encantó el comentario del televisor, tienes toda la razón, el problema de los visuales es que no te enseñan a programar, te enseñan a pintar ventanas, pero no te enseñan a pensar.

La gran mayoría de los programadores visuales ignoran que hay lenguajes no visuales, o si saben que existen, nunca han pasado por ellos.

¿ Te acuerdas de los diagramas de flujo ?, eran el primer paso para realizar un programa, y también con ellos se dabanlos primeros pasos para el pensamiento organizado, hoy en día los diagramas o se hacen al final, o simplemente no se hacen.

Y veo que también estas sufriendo por lo mismo que nosotros, no hay personal que quiera programar, bueno si hay, pero casi nadie quiere ponerse a usar el cerebro, en vez de "add-ons cerebrales".

Anónimo dijo...

A que te referies explicitamente a "darle chance" a algun Visual?
A que Visual le daras ese "chance"?
A Alguno que maneje lenguaje clipper?
Haras algun dia algun otro articulo alusivo a este "chance" a los Visuales ?

Rene Flores dijo...

Obviamente me estoy refiriendo a Xailer, la formas mas rapida y visual de tener aplicaciones basadas en Clipper, pero 100% orientado a objetos.

Anónimo dijo...

CASI todos en este blog hablan como una abuelita cuando aprende a usar la computadora, solo volteen a su alrededor, el mundo les lleva una vida de ventaja. Para muestra basta un botón. Creswin es como un triciclo mal hecho en una pista de carreras. Espero que no borres mi comentario.
Saludos