Rescate emotivo1
Siempre me pasa -y supongo que a muchos-, que cuando llegan las fiestas de fin de año, Navidad y Año Nuevo, nos ponemos nostalgiosos y recordamos viejas épocas, como queriendo hacer realidad ese dicho de que «todo tiempo pasado fue mejor».
Hurgando en mis escritos de hace algunos años encontré un backup de una antigua web que tenía «colgada» en un servidor gratuito y que trataba sobre programación de sistemas, redes y GNU/Linux. Es del año 1999, es decir que si aún estuviese on line cumpliría 10 años. La quité porque estaba en un servidor de esos gratuitos que literalmente la habían arruinado de tanta publicidad que le incrustaron.
El hallazgo ¿fue una coincidencia casual o causal? No lo sé, lo cierto es que me puse a leer lo que publicaba en aquella época (todo tipeado dentro de HTML puro) y me di cuenta que los contenidos aún tiene vigencia plena. Por eso mismo les comparto este «Programación – Primeros pasos» que es un compilado de consejos sacados de mi propia experiencia que tal vez a alguno le sirva y al que no, al menos se divierta con su lectura. Juro que no le he quitado ni una coma.
PROGRAMACIÓN DE SISTEMAS
.: INTRODUCCIÓN
Antes de aprender cualquier lenguaje tienes que hacerte una pregunta básica: ¿para qué o por qué quiero aprender a programar? Descartando de que tienes una idea de lo que es la actividad y que te apasionaría hacerla, de esta pregunta surgirán muchas respuestas pero básicamente las podemos agrupar en dos y solo dos. La primera es económica: «para hacer dinero, para mejorar mi remuneración«; la segunda es espiritual o no material: «porque deseo que la máquina, PC, ordenador, computadora haga lo que yo quiera, porque es un desafío, porque se me antoja, porque mis neuronas piden fuego«. De estas dos premisas dependerá muy ciertamente todo tu futuro como programador. Puede que en algún momento se alternen o se junten pero deberás comenzar -como es lógico- motivado por alguna de estas dos razones.
.: LA PROGRAMACIÓN COMO MEDIO DE VIDA
La programación como medio de vida o por motivos económicos es el fin más común. Todos quieren ganar dinero haciendo programas sea en forma independiente o dependiente y he aquí el comienzo de un largo peregrinar. Pero a no desesperarse y ten en cuenta estos consejos útiles que te doy y que mi experiencia enseñó:
.: 1er. Consejo: Escoger un lenguaje sencillo
Escoge para empezar un lenguaje sencillo, que los programas se puedan hacer rápidamente y sin mayores complicaciones. Un sistema de programación cuya curva de aprendizaje sea breve y que no te lleve más de un año dominarlo completamente dedicándole concienzudamente un par de horas por día. ¿Por qué te digo esto? La mayor parte (o todo) del software que vas a vender será comercial y típicamente aplicaciones contables o administrativas. Un sistema que maneje base de datos sería lo ideal. Si es para MS-DOS, para una red Novell o para una consola linuxera el Clipper, Foxbase+ o Foxpro para DOS son los recomendables. Si vas a programar para MS-Windows el Visual Foxpro o el Visual Basic son las alternativas por su potencia en el manejo de lenguajes SQL y el acceso a Xbases muy transparente y flexible que tienen.
.: 2do. Consejo: No divagar y estudiar a fondo
¡¡¡No, no y no!!! ¡¡¡No divagues!!! Elige uno y apréndelo en profundidad. No empieces a probar uno u otro porque no solo perderás tiempo sino que luego empezaras a confundir las sintaxis y ya, en carrera creativa, se duplicaran tus dudas y por ende tus horas de trabajo. Todos los sistemas de programación tienen sintaxis similares, es decir cuya funcionalidad produce un mismo resultado pero varían en su forma y a veces hasta un simple punto y coma hace que el código no ande. Además, una vez que domines un lenguaje, aprender otro te será sumamente sencillo. Pero para empezar concéntrate 100% en uno solo.
.: 3er. Consejo: Planear todo, bosquejar y documentar
Planea «al detalle» lo que vas a hacer. No empieces directamente a codificar sin saber qué es lo que vas a hacer y por dónde tienes que seguir a cada momento. Arma el esqueleto de lo que vas a programar. Un bosquejo ayuda, orienta y simplifica. El tener todo organizado no solo ahorra tiempo y energía sino que luego te ayudará a recorrer el camino cuando las cosas no anden. Te dará las pautas de la lógica que seguiste a cada paso. La documentación que vayas haciendo será tu as, tu carta en la manga, para solucionar e inclusive para mejorar o cambiar el software cuando así se requiera. La documentación es el ABC de la lógica organizativa y gerencial de sistemas y sin ella serás un improvisado y eso el cliente siempre lo ve y jugará en tu contra.
.: 4to. Consejo: Comentar el código
Comenta tu código. Esto quiere decir que una vez que empieces a escribir el programa vayas describiendo lo que estas haciendo y por qué. Todos los sistemas de programación tienen un comando que permite introducir comentarios, úsalos lo más a menudo que puedas. Estos comentarios no se ejecutan, no ocupan lugar, te llevan minutos escribirlos y son como perlas en el maremagnun del código. Verás cómo destellarán con su propia luz y te ayudarán e iluminarán al momento de buscar conflictos y solucionar problemas. Los comentarios hacen a la buena creación del código y a la lógica organizativa y gerencial de la que ya hablamos.
.: 5to. Consejo: Dividir en subsistemas-Modularizar
Divide y triunfarás. La programación de un sistema se conforma de soluciones a los pequeños problemas. Es decir que un sistema es un conglomerado o conjunto de subsistemas unidos. Resuelve cada problema independientemente y de la mejor forma, con simpleza y eficiencia. Programa como se dice en la jerga «modularmente«. En lo posible haz que cada módulo creado funcione por si solo. Esto te permitirá reutilizar muchas de tus pequeñas creaciones y por consecuencia ahorrarás horas de programación. Para que te hagas la idea, un ejemplo típico sería un procedimiento que escriba los números en letras que lo mismo lo utilizarías para emitir un recibo que para hacer el reporte de una factura.
.: 6to. Consejo : Llevar cuenta del tiempo de trabajo
Lleva la cuenta horaria de lo que te lleva programar cada cosa. ¿Por qué? porque será la base de tus presupuestos. Los programas se cotizan por la carga horaria que lleva su realización, además, por supuesto de las licencias por uso y el costo por mantenimiento. Saber con una aproximación cierta cuánto te lleva hacer un software hará que lo que ganes sea equitativo y que no cobres en demasía o pierdas dinero, en definitiva seas «competente». También en el costo influyen otros factores como son el valor de mercado (la que cobran los demás) la plataforma para la que estés programando (DOS, Windows, Linux, Web, etc.) y otras cuestiones menores como costo por instalación, soporte técnico, cursos o tiempo para enseñar su uso, soporte magnético, soporte escrito (manuales) etc.
.: 7mo. Consejo: Leer manuales y pedir ayuda
Acude a otros medios de información. Cuando veas que se te cierra la mente, que las neuronas piden tregua y que no puedes resolver algunas cuestiones pide ayuda. De seguro a otros ya le pasó lo mismo que a ti y sabrán como sacarte del paso. ¿Dónde pedir ayuda? En primer lugar están los libros o manuales y por favor LEE LOS MANUALES (RTFM) porque en el 90% de los casos la solución está allí. En segundo lugar está el fantástico mundo del cyberespacio en donde hay miles de páginas con ayudas, tutoriales, código ya hecho y muchas personas dispuestas a darte una mano. En los grupos de noticias, en los foros y en los chats (IRC) se encuentra la fuente de la sabiduría pues allí convergen cientos o miles de mentes tan creativas como la tuya. Suscríbete a un grupo de noticias o a un foro, entra a cada momento y no solo pide sino que también entrega, sin egoísmos. Nadie nació sabiendo y compartiendo el conocimiento se hacen las cosas cada vez mejor.
.: 8vo. Consejo: Observar otros programas similares
Observa el software de otros para ver cómo lo hicieron. No se trata de copiar o de plagiar sino de aprender y con esa base hacer tu propia creación. Muchas veces no sabrás por dónde empezar y un software shareware te puede dar idea del comienzo y luego con tu impronta, con tu sabiduría y de acuerdo a tus necesidades harás un programa original. Ninguno es igual a otro puesto que cada uno busca su conveniencia. Un ejemplo es el caso de los programas de compactación (zipeadores) de los que hay muchísimos (cada día más) pero sin embargo cada uno tiene lo suyo, cada uno tiene una característica que lo hace original, a su vez, también comparten librerías similares y no por eso son copias o plagios.
.: 9no. Consejo: Dos cuestiones de las más importantes
Haz que el programa sea para el usuario. Esto quiere decir que cuando programes te pongas en el lugar del que va a usar el software y no en tu punto de vista de creador. Para empezar siempre es necesario hacer un estudio de la empresa en donde vayas a implementarlo. Es decir tendrás que ir y ver cómo circula la información en sus distintas etapas, cuales son las tareas que realiza cada empleado en su puesto, qué reportes o información necesitan y con qué recursos cuentan. Hablar con el gerente e interrogarlo sobre sus necesidades de información a corto, mediano y largo plazo. Esto constituye lo que se llama el «análisis del sistema» y es la base primordial sobre la que harás el bosquejo que te comenté más arriba para luego crear el programa en si.
En segundo lugar tienes que hacer de cuentas que el usuario final, el dataenter, no sabe nada de programación (siempre es así) por lo que tus interfaces o pantallas de ingreso y egreso de datos deberán ser sencillas de usar y agradables a la vista. Para este usuario las tareas tienen que ser indefectiblemente simples, precisas y concisas. Recuerda que él no ve ni le interesa el código y que lo que tu le brindas será la base para la toma de decisiones.
Este 9no. punto se erige como el más importante en el momento en que un buen gerente decide si vale la pena el software que hiciste o es una porquería ya que será la fiabilidad de los datos y la facilidad en su obtención el arma para su crecimiento corporativo o de negocios y con eso no se juega.
.: 10mo. Consejo: No seas conformista
No te creas un genio ni te conformes con tu creación. El código, programa, software o como quieras llamarlo que hiciste nunca es el mejor ni lo será y siempre necesitará arreglos. Mejorar constantemente la performance del código es no solo placentero y enriquecedor sino que además hace a tu dedicación en este difícil arte. Hacer un programa y nunca más tocarlo es como dejar de «regar» el árbol del conocimiento que plantaste. La mente del programador es un intrincado cerebro que pide siempre simplificar lo difícil, hacer trivial lo imposible, abultar la biblioteca de estructuras mentales incorporadas, por eso relee tu código y busca mejores soluciones a los problemas.
.: Finalmente…
Finalmente HAZ SIEMPRE COPIAS DE SEGURIDAD de cada cosa que pruebes porque más de una vez te arrepentirás de haber sobrescrito archivos en donde algún problemita ya había sido resuelto y por tu intensidad en la creación o en el hecho de mejorarlo lo borraste. La programación en el 100% de los casos se basa en el método científico de «ensayo y error«.
.: LA PROGRAMACIÓN COMO DESAFÍO INTELECTUAL O COMO ACTIVIDAD LÚDICA
La programación como un desafío o por interés particular no económico tiene finalidades diversas. Puede ser que te interese un lenguaje en especial para llegar a dominar mediante software el basto hardware que nos rodea, conocer sus «secretos», llegar al fondo de las cosas. Tal vez quieras participar de algún proyecto del tipo opensource (código abierto) en donde solo vale tu interés por los desafíos y tus ansias de conocimiento, el querer ayudar a los demás ofreciéndoles gratuitamente tu tiempo. A lo mejor es una cuestión de gusto, es decir, quieres aprender algún lenguaje porque sí, en una inclinación al ejercicio lúdico mental que te apasiona. En fin, muchas más podrán ser sus tus motivaciones y por ello el abanico que se te presentará será basto e interminable. En cualquier caso, aquí no hay consejo que valga. Lo único que es necesario tener en cuenta es que estudies lo que estudies, aprendas lo que aprendas, la importante es que te sientas bien haciéndolo y que no te acobardes con los problemas porque todo se resuelve. Sin embargo quiero aclarar algunas dudas que surgen en cuanto a los niveles de dificultad de los lenguajes de programación y que me parece más que adecuado comentarlas.
.: Niveles de dificultad en los lenguajes de programación
.: Assembler o lenguaje ensamblador
En una explicación breve y a grandes rasgos podemos decir que la electrónica de una PC se basa en circuitos lógicos cuyos estados se alteran en un tiempo dado por la presencia o no de energía. Por eso se dice que la PC funciona con una codificación real binaria, esto es: estado 1 si hay electricidad y 0 sino la hay (1 y 0, dos dígitos, binario significa dos) Simplificadamente es como decir que una computadora maneja en realidad unos y ceros lo que electrónicamente es cierto. Ahora bien, realizar un programa, generar instrucciones o datos en unos y ceros es una tarea titánica e imposible. Esto era así en las viejas épocas de las tarjetas magnéticas allá en los albores de la computación. El assembler surgió luego entonces como un primer intento de establecer un lenguaje de comunicación con la computadora más facilongo.
Y ¿qué es el assembler? Es justamente eso: un lenguaje simbólico que representa directamente datos y operaciones tal como las utiliza la máquina. Es casi como un conjunto de «reglas nemotécnicas» (léase bien el «casi») Por consecuencia directa nos permite acceder a los recursos más recónditos y manejarlos en forma vedada a otros lenguajes. En contrapartida: empleando instrucciones muy elementales como son las de un micro, ciertas tareas que serían triviales en lenguajes de alto nivel son muy pesadas cuando no imposibles. El aspecto más importante del assembler entonces está en saber cuándo utilizarlo y hasta qué punto y cuándo se convertiría en «una cosa de locos». Por ejemplo si queremos construir un driver para manejar una placa de video sería más que necesario hacerlo, por lo menos en gran parte, en assembler ya que nos daría la máxima performance, pero un programa de ABM (Altas, Bajas y Modificaciones) de artículos sería no solo engorroso sino un verdadero despropósito.
Aprender assembler no es tan difícil como muchos suponen, no es algo para los gurús, si bien requiere de mucha paciencia, empeño y tal vez algunas aspirinas. El tener por lo menos conocimientos ayuda enormemente sobre todo porque permite comprender mejor ciertas «instrucciones» de lenguajes de alto nivel y poder así utilizarlas mejor.
Un uso común y cada vez más extendido del assembler es en el cracking, conocido también como «ingeniería inversa» o «retroingeniería». Y si bien esta actividad es ilegal por cuánto viola los derechos de autor, vale aclarar que si se hace personalmente (en casa) y con fines educativos nos lleva a un nivel de conocimiento superior.
.: El «C» o el lenguaje de los sabios
Se podría decir y sin equivocación alguna que el C ostenta, como un aura sagrada, el nivel de complejidad máximo. ¿Será cierto? El C es tan difícil y útil como lo es cualquier otro lenguaje y por lo tanto tiene sus ventajas y desventajas. Si bien su curva de aprendizaje es larga y lenta no por eso es lo máximo. Para algunas cosas puede servir para otras quizás no. Particularmente no soy «fanático» de ningún lenguaje en particular. A pesar de haberme «hecho» en Foxpro no digo por ello que es el mejor lenguaje. Tengo perfectamente claro que para hacer un programa de dibujo o de tratamiento de imágenes el Foxpro definitivamente no sirve.
.: Mitos y leyendas apócrifas
Quiero compartir un ejemplo ilustrativo sobre estos mitos creados entorno a los lenguajes para que te clarifique un poco más la cuestión.
En aprender y dominar un lenguaje hay toda una inversión de tiempo y esfuerzo, hasta puede haber una tradición de trabajo detrás de él (como es mi caso con Foxpro) ¿Quién va a resignar a tirar todo por la borda? Lo que normalmente pasa es que no se lo juzga objetivamente el lenguaje sino que se juzga la actitud del que lo emplea.
Es como si nos preguntáramos «¿qué es mejor? ¿un martillo o un destornillador?«. Uno podría argumentar miles de cosas en favor de uno y de otro, pero a nadie se le escapa que son herramientas con objetivos completamente distintos. Ahora bien, si intentas fijar un tornillo a martillazos, o clavar una tachuela con un destornillador, probablemente puedas contribuir con nuevas argumentaciones sacadas de los pelos. Más aún, para quien sólo tiene un martillo, todas las cosas parecen clavos. Y si se aferra a la idea de instrumento único, multitud de tareas resultarán pobremente realizadas. Pero defenderá la supremacía del martillo con vehemencia.
Otra cosa a tener en cuenta es que muchos de los mitos (como el caso del C) generalmente son creados por gente que desconoce totalmente el lenguaje. Muchas veces el mito parte del que «le gustaría pero no lo hace«, del que «no entiende pero dirige» o del que «tiene un amigo que…» Las ventajas y desventajas de un lenguaje son evidentes solo para el que lo usa y lo conoce bien y que además lo pone en práctica, pero no para el que «toca de oído».
Finalmente saber assembler y C no te convierte en Einstein, ni te convierte en un gurú, te convierte en un programador lo mismo que el que sabe Delphi, Basic o Foxpro. Haz una prueba fácil… pon a un experto en C a crear un programa de ABM de artículos y ve cuánto tarda y pon con lo mismo a un experto en Visual Basic o Visual Foxpro y compáralo. A la inversa, pon el segundo a crear un driver para una placa de sonido y compáralo con al primero haciendo la misma tarea. Las conclusiones para ambos casos son obvias, ¿no te parece?
.: Hasta aquí llegué
Hasta aquí llega esta quizás larga pero valedera introducción. No he agotado los temas, muchos aspectos han quedado fuera de comentario que poco a poco iré agregando. Si quieres más lee la sección de «Comparativa de Lenguajes de Programación». Espero hayas disfrutado leyendo lo mismo que disfruté yo al escribirlo 🙂
- Este artículo fue publicado por primera en 1999, fue resctado del olvido en marzo del 2012 en mi web Joomla-GNU.com y hoy lo traigo nuevamente del pasado porque fue en ambos períodos el texto más leído de ambas webs. ↩︎
Colaboración a voluntad – No es obligatoria.
(¿por y para qué colaborar? Leer aquí)
Sé el primero en comentar