Don't Panic!

A la hora de programar, uno de los errores más comunes en los que se puede caer es el de rendirse prematuramente y entrar en pánico: relegar el funcionamiento de nuestras ideas a la suerte y cambiar pequeñas cosas progresivamente, en intentos mecánicos y poco planificados, con la esperanza de que esa "magia oscura" que reina sobre los programas, finalmente comprenda lo que queremos decirle y la computadora haga lo que debe.

Hmm, súmale uno...
Bueno, no, réstale uno...
¿Y si cambiamos el menor por menor o igual?
¿...o mejor por mayor o igual?
¿...o mejor por un no igual?

Una vez aceptamos la verdad, resolver cualquier problema se hace mucho más sencillo y natural. El secreto es elemental y, sin embargo, completamente elusivo en nuestros primeros años como programadores: no hay tal cosa como la magia oscura. Todo lo que un programa hace es consecuencia lógica de aquello que escribimos, con reglas bien establecidas y concretas que podemos seguir meticulosamente, si tenemos la disposición y la paciencia para hacerlo.

Por esto, la mejor metodología a seguir cuando se programa es la de planificar antes de echar la primera línea de código, entender lo que se está haciendo e investigar cuando hayan dudas. En resumen: no entrar en pánico. Incluso las tecnologías que podrían parecer más extrañas se fundamentan en ideas y reglas básicas que pueden entenderse con calma y detenimiento.

En una época en la que la información es completamente ubicua, no tiene sentido estancarse al intentar entender un problema. Con tanta gente que programa, ha de haber al menos otra persona que se ha topado con un problema similar. ¡Ojo! Esto no quiere decir que en internet estará la solución exacta al problema, ni que se resolverá con un simple copy+paste (no suele funcionar así e, incluso si funcionara, de nada sirve arreglar un problema si no se entiende cómo se arregló, pues nos estamos condenando a repetirnos y a caer en los mismos problemas).

Una de las mayores fortalezas que puede desarrollar un programador es el reconocimiento de patrones. Y no me refiero a la técnica relativa al aprendizaje de máquina, sino a reconocer patrones en lo que hacemos y saber aprovechar esos patrones para ayudarnos a hacer nuestro trabajo. Muchas veces, las ideas se repiten y son aplicables a una gran cantidad de tecnologías y aplicaciones. Por eso, debe ser prioridad de cualquier programador aprender todo lo que pueda, sobre todo lo que pueda. Cuanto más experiencia tengamos, más fácil será reconocer patrones en las herramientas que usamos y los problemas que resolvemos.

Aunque parezca material de charla motivacional, el trasfondo es muy cierto e importante. He visto pasar mucho que la gente se hunde en sus propias inseguridades, temerosos de detenerse, pensar, entender y actuar. No me considero alguien particularmente brillante o talentoso, pero en la medida de lo posible intento no entrar en pánico. Todo problema que surge en nuestras vidas como programadores tiene una explicación y, en la mayoría de los casos, la solución está en nosotros mismos; sólo hace falta ser perseverantes, investigar y no conformarse con resolver sin entender lo que estamos haciendo. Con el tiempo, los patrones se harán evidentes y podremos resolver más y más problemas. ¡Es un ciclo de aprendizaje que crece y se realimenta a si mismo! Y todo comienza con no entrar en pánico. :)

Gracias por leer, hasta una próxima entrada. :D

El camino del bien

Una de las materias que doy en la USB es Lenguajes de Programación I, en donde se discuten las diferentes características de un lenguaje de programación de forma tanto general (conceptos abstractos) como específica (ejemplos concretos con lenguajes existentes). Es una materia sumamente entretenida, tanto de impartir como de escuchar, y es central al conocimiento de todo buen profesional de la computación.

¡El poderoso camino del bien! :D

Esta ya es la tercera vez que he dado esta materia, con una separación de 2 años entre cada ocasión. La última vez, fue en Enero del 2014. Ese trimestre, como muchos recordamos, fue el trimestre de las marchas y las guarimbas. El trimestre se extendió, durando casi medio año. Sin embargo, durante el mismo preferí aprovechar el tiempo para crear material que ayudara a las personas a prepararse mejor para la materia. Fue así como creé una serie de guías, sobre alcances y asociaciones, composición de máquinas (diagramas de T), iteradores y recursión de cola. Estas guías se caracterizaban por contener una sección llamada "El camino del bien", que mostraba procesos paso a paso para resolver problemas relacionados al contenido que cubrían.

El trimestre en que fueron creadas las guías, el grueso del salón salió muy bien. Me dijeron además, que las guías les habían ayudado mucho a prepararse. Esto me llenó de alegría y me inspiró para hacer otras guías en otras materias, como Traductores e Interpretadores, Algoritmos I y II, etc. Aún en trimestres posteriores he escuchado de personas que se han beneficiado de estudiar usando estas guías. ¡Pero hace falta más!

Como proyecto personal, quisiera crear una serie de guías de nombre "El camino del bien" (en honor a esas primeras guías del curso de Lenguajes de Programación I). Estas guías cubrirían una gran parte de la carrera, al nivel que pudiera manejar alguien con un conocimiento bastante limitado (como es mi caso). La idea de crear estas guías cumpliría varios objetivos puntuales:

• Ayudar a las personas a preparase mejor y a comprender mejor esta genial área del conocimiento que es la computación.
• Dejar material de apoyo que sirva como base para dictar cursos de alta calidad.
• Apoyar el aprendizaje de personas que no dominan completamente el idioma Inglés, sirviendo como una primera referencia que luego podría profundizarse con otro material.
• Reforzar los conocimientos propios. ¡Enseñar es aprender dos veces! :D
• Inspirar a otras personas a seguir iniciativas similares y juntos aumentar la cantidad de material y conocimiento disponibles.

Este es un proyecto en el cual quiero trabajar desde hace un tiempo, aunque confieso que no he conseguido el tiempo para hacerlo. Aún así, un buen amigo y profesor una vez me dijo: "La diferencia entre 'sería fino que existiera' y 'existe', es el momento en el que decides hacer algo al respecto" y definitivamente, eso haré. Tengo como objetivo a corto plazo comenzar a escribir algunas guías. Sin embargo, aún estoy decidiendo sobre cuál tema. ¡Cualquier recomendación es bienvenida!

Las guías no serían exhaustivas, claro está. Sería arrogante pensar que puedo explicar todo mejor que cualquier otra persona. La idea de las guías sería sentar una base y luego hacer referencia a material más profundo disponible en línea.

Y bueno, éste es uno de tantos proyectos que me encantaría llevar a cabo y es lo que quería compartir por ahora. ¡Hasta una próxima entrada! Sigan siempre el camino del bien. :D

Mayo y Junio. ¡Wow!

Este último par de meses me tiene sin palabras (aunque irónicamente esté escribiendo usándolas, jajaja). Y es que Mayo y Junio han sido tan excelentes que poco puedo creerlo. Este par de meses viajé al otro lado del mundo, conocí a mucha gente genial con quienes compartí lo que me apasiona y hasta gané un premio inesperado. Estoy sumamente agradecido por todo y motivado a continuar trabajando lo que me encanta.

Coleado con los organizadores de las JOINCIC, jajaja. ¡Pura gente genial! :D

El mundial:

Hace ya un poco más de un mes, se celebró la final mundial de los maratones de programación ACM-ICPC, en nada menos que Tailandia. Desde que el genial equipo RAM clasificó, la mayor preocupación fue la de cómo llegar hasta el otro lado del mundo a participar. Los gastos de hospedaje, comida e incluso entretenimiento los cubriría ACM, pero los pasajes debíamos conseguirlos nosotros.

Después de mucho hablar, realizar campañas de crowdfunding y reunir dinero, no teníamos lo suficiente para ir. Algunas oportunidades que podían ayudarnos se cayeron a último momento y llegada la semana antes del evento, todo parecía apuntar a que no podríamos asistir. Pero un grupo maravilloso de personas (que prefieren mantenerse anónimos) decidió que era injusto que no fuéramos, habiendo intentado tantas cosas y clasificado justamente. Así, decidieron apoyarnos completamente y patrocinarnos los pasajes. ¡Iríamos a Tailandia!

El viaje fue largo y cansado. 3 días de viaje hasta Tailandia: 6 vuelos, 172 horas en total. Pero ahí estábamos y todo había valido la pena. La experiencia fue alucinante. Nos reencontramos con viejas amistades e hicimos otras nuevas. ¡Participamos junto a los mejores programadores del mundo! Vimos espectáculos increíbles. Realmente, fue una experiencia sumamente enriquecedora para todos. Finalmente el equipo quedó de 115 sobre 128 equipos. No es la mejor posición, pero hay que considerar que esos 128 equipos fueron clasificados de entre más de 20.000 equipos de todo el mundo. Además, los chicos clasificaron al mundial en su primer intento, apenas en 2do año de la carrera. Ese es un logro que muchos quienes entrenamos durante toda nuestra carrera (me incluyo) no alcanzamos. ¡Son chicos admirables y estoy orgulloso de ser su entrenador!

Las 9nas JOINCIC:

Volviendo del mundial, tuve una semana para preparar la charla que daría en las JOINCIC. De entre los temas que les propuse, los chicos votaron y decidieron que querían escuchar sobre "Algoritmos y Estructuras para Videojuegos", además me pidieron dar una mesa de trabajo introductoria para los maratones de programación. ¡Que genial ser parte de otras JOINCIC!

Cuando la fecha se acercaba, hubo algunos problemas con las ponencias y me pidieron que hablara también sobre los maratones de programación y la experiencia en Tailandia. Preparé también esa charla. Luego me pidieron que hablara sobre cualquier otra cosa que quisiera y hablé sobre la relación que hay entre la lógica y la programación (sin duda, la charla más oscura de las tres, jajaja).

Disfruté muchísimo dando esas tres charlas y la mesa de trabajo. Además, tuve el gusto de ser invitado a un conversatorio sobre la actualidad de la computación en Venezuela. ¡Fue genial ser parte de todo esto! Además, muchas personas se me acercaron luego y me comentaron que les gustaron mis charlas y que se sintieron motivados por ellas. Pocas cosas te llenan tanto el alma como saber que has inspirado a alguien más. Y además hubo muchísimas charlas divertidas de otras personas. Definitivamente, el evento fue un éxito total. Compartí una genial semana con geniales personas hablando de cosas geniales. ¡Fue lo máximo! :D

La semana de la Carrera:

Una semana después de haber terminado las JOINCIC, ya estábamos en plena semana de la carrera. El CEIC siempre organiza diferentes eventos en torno a la semana, como ponencias, caimaneras y el infaltable compushow. Tuve el gusto de dar la primera ponencia de la semana, hablando sobre los maratones de programación e invitando a todos a participar. Otra excelente charla la dio la prof. Carolina Chang, sobre educación STEM. Además, la relacionó con la charla de maratones y con su actividad en robótica, lo que me pareció absolutamente brillante. :)

El Jueves se celebró el minimaratón de programación, en el que un montón de gente se animó a competir y resolver problemas. Muchos de los competidores apenas están viendo lógica y aún así hicieron un excelente trabajo. Además, se estrenaron los chicos que han venido entrenando el último año como organizadores y colaboradores. ¡Fue todo un éxito! Estoy sumamente orgulloso de todos. Lamentablemente yo no pude asistir, ya que estaba en otro compromiso, pero aún así sentí toda la buena vibra del evento. Además ese "otro compromiso" también fue un éxito total. Estaba reunido en la UNE con un grupo de profesores y estudiantes interesados en colaborar académicamente con la USB, particularmente en el área de lógica difusa aplicada. Fuimos a darles una charla y creo que quedaron muy satisfechos, lo cual me llena de alegría y motivación.

El Viernes fue el CompuShow y como siempre fue lo máximo. ¡Que buenos los videos! Y que genial toda la organización. El evento completo duró poco menos de 3 horas y aún así, fue entretenido hasta el final. También tuve la oportunidad de presentar el premio a CompuPro, que lo ganó muy merecidamente Alfredo Fanghella (se le va de las manos las intervenciones en clase de Lenguajes, jajaja). Pero lo más increíble y totalmente inesperado: ¡Gané el premio a CompuMaster! El premio que dan los estudiantes por votación al mejor profesor de la carrera. Aún no puedo creerlo. Aunque muchos años pensé en que podría decir si algún día lo ganara, con los nervios lo único que pude medio decir fue "gracias", jajaja. ¡Gracias a todos por esta gran alegría! Vale mucho más para mi de lo que se podrían imaginar.

Graduaciones:

Hace unos días tuve el gusto de asistir al acto de graduación de un gran grupo de amigos y personas increíbles. A muchos de ellos les dí clase y ahora, con el mayor orgullo, puedo llamarlos colegas. El acto fue muy emocionante; con cada nombre que sonaba y cada persona que pasaba, me llenaba un poco más de orgullo. ¡Fue genial acompañarlos en su día! <3

El día a día:

Además de los momentos notables, el día a día ha sido genial. He disfrutado muchísimo de las clases que estoy dando. Además, he compartido muchos buenos momentos con personas realmente geniales. ¡Gracias por estos dos geniales meses!

Y esta nota abrumadoramente positiva es lo que quería compartir hoy, jajaja. Gracias por leer (a quienes lo hayan hecho, jajaja) y hasta una próxima entrada. :D

Ni ciencia, ni tecnología, sino todo lo contrario

Desde que inicié mi carrera, he estado en una disyuntiva que me ha acompañado a lo largo de mi crecimiento como persona y como profesional; y ésta trata de saber si soy más del tipo técnico o del tipo científico. Me gustan actividades que involucran cada tipo y no me gustan tanto otras, que pertenecen a ambas igualmente. Entonces, ¿cómo me identifico?

Hmm...

A lo largo de mis estudios de pregrado, siempre quise convencerme a mi mismo que era del tipo científico. Despreciaba de asuntos puramente prácticos, e intentaba aprender más y más sobre ciencias avanzadas en computación. Sin embargo, siempre me ha molestado el empirismo científico. Y aunque respeto su utilidad, no me siento cómodo aplicándolo y razonando sobre él. Siempre he preferido las análisis formales y precisos, que no dependen de estadísticas y suposiciones.

Además siempre me ha gustado programar. El detalle, es que no me gusta programar cualquier cosa. Las aplicaciones web, móviles, etc., no me llaman la atención. Las tecnologías nuevas normalmente me tienen sin cuidado. Sé manejar una buena cantidad de lenguajes de programación, pero las herramientas industriales construidas alrededor a estos me son ajenas. Los programas que me gusta implementar son de problemas algorítmicos retadores, o de soluciones elegantes a problemas conocidos. En otras palabras, me gusta jugar con la programación. La veo como un arte, una forma de expresión, un gusto absolutamente puro.

Me gusta programar, y me gusta el pensamiento científico, pero nunca me sentí completamente cómodo siendo de un sólo tipo; cosa que usualmente no veo en otros colegas. Conozco gente que es sumamente práctica (que incluso puede usar conocimiento científico en aras de mayor practicidad) y conozco gente sumamente científica (que incluso puede hacer uso de herramientas computacionales prácticas para apoyar sus experimentos). Pero yo no logro identificarme con ninguno de estos grupos.

Continué con esta disyuntiva, y conocí nuevas ciencias, nuevas herramientas y nuevos tipos de pensamiento. Conocí a personas con pensamientos divergentes e ideas innovadoras. Comencé a leer un poco más sobre diferentes temas y eventualmente me di cuenta... No me identifico con el tipo científico, ni con el tipo técnico, por que no pertenezco realmente a ninguno de estos grupos. Soy una persona que pone en duda todo lo que aprende; que le apasiona tomar cualquier tema y hacer preguntas, y más preguntas, y quizá luego más preguntas; que prefiere el pensamiento abstracto y detallado incluso sobre las cosas más básicas. He comprendido, que mi tipo de personalidad y llamado intelectual, va más hacia la filosofía.

¿Ahh? ¿Filosofía? Así es, pero no la filosofía poética que en bonitas palabras revela poco más que edificios sobre cimientos de arena. Más bien de la filosofía formal, entendida como un proceso estricto de razonamiento cuya repercusión pudiera ser elevada, pero de formas mundanas. La aplicación racional del pensamiento a los temas más diversos, y también a todos los temas, agrupados, abstraídos. Me he sentido más cómodo hablando y pensando sobre este tipo de temas. Y me he dado cuenta que siempre ha sido así. Reviso las cosas viejas que he escrito y es consistente con esto. Además siempre me ha gustado más plantear las preguntas, o incluso plantear soluciones abstractas, que realmente implementar una solución o medirla.

Ahora que he entendido esto, no estoy seguro de qué seguiría. Posiblemente busque hacer un PhD eventualmente, pero con énfasis en el "Ph" (por Philosophy) y no tanto en la componente científica. Además, quiero continuar leyendo y aprendiendo sobre diferentes corrientes de pensamiento, para eventualmente consolidar la mía propia. Ahorita estoy leyendo a Descartes (que me parece genial). El siguiente en la lista es Kant (considerándome inclinado hacia el racionalismo, leer la crítica de la razón pura me parece necesario para consolidar una posición integral y bien informada).

Y bueno, este pequeño descubrimiento personal es lo que quería compartir por ahora. Los dejo hasta una próxima entrada. :D

Training Camp Argentina

Hace ya un par de semanas que estoy de vuelta en Venezuela. De regreso de dos semanas que fueron testigo de un increíble viaje. Un inolvidable evento en donde conocí a excelentes personas a la que les apasiona programar y resolver problemas, y en donde pudimos juntos aprender y mejorar con la ayuda de excelentes guías, más allá de cualquier expectativa. Dos semanas que estuvimos en el Training Camp de Argentina, para las competencias de programación ACM-ICPC.

El último día, foto final con casi todo el mundo. :)

Hace alrededor de 3 meses, la USB participó en la final mundial de los maratones de programación ACM-ICPC, en Marruecos. Ahí conocimos a bastante gente chévere y compartimos nuestra pasión por resolver problemas difíciles e interesantes. De este evento, con la ayuda de nuestro director de sede (Trino Gómez), obtuvimos una invitación especial para el campamento de entrenamiento "Training Camp Argentina", que se celebraría en Julio de 2015. En un principio iba a ir un sólo equipo con integrantes mixtos (de diferentes universidades), pero finalmente fuimos invitados un equipo de la USB y un equipo de la UCV (y yo, como coach de ambos equipos).

Y así empezó la aventura. ¿Cómo podríamos ir? No es secreto para nadie que a los Venezolanos nos cuesta salir del país por el motivo del control de divisas. ¿Cómo resolveríamos? Ya habíamos tenido la experiencia después de Marruecos de conseguir pasajes económicos, siempre y cuando se tratara de asuntos académicos y una vez más pudimos contar con esa gran ayuda. Pero aún quedaba el hospedaje, la comida, el transporte dentro de Argentina, etc. Esperanzados, lanzamos una campaña de recolección de fondos por internet y el resultado fue abrumador. El gran corazón y disposición para ayudar de tantas personas es algo que aún me conmueve y agradezco enormemente. Logramos recolectar suficiente para nuestros gastos allá. ¡De verdad, muchísimas gracias a todos!

El campamento fue en la ciudad de Bahía Blanca (a unas divertidas 11 horas en autobús desde Buenos Aires). Es una ciudad bastante pequeña y tranquila, pero con un tímido encanto. El día que llegamos hacía 0°, lo cual es una experiencia divertida para quienes venimos de un país tropical. A mi particularmente ME ENCANTA el frío y no podría haber sido más feliz a esa temperatura (la gente allá nos cuenta que en verano puede alcanzar casi los 50°; ya he vivido esas temperaturas y no juegan, jajaja).

En Bahía Blanca paseamos y conocimos un poco, pero principalmente y más importante: El campamento. Todo el evento fue en la facultad de agronomía de la Universidad Nacional del Sur (sip, agronomía... y sip, tenían monstruos de computadores allá, jajaja). Cada día llegábamos a las 9:00am. y teníamos entre 3 y 4 horas de clases y discusiones, el almuerzo (que abrieron un kiosko que vendía comida bastante buena por un muy accesible costo) y finalmente un simulacro de competencia de 4 a 5 horas, para salir a eso de las 7:00pm. Fue INTENSO, pero también muy divertido y enriquecedor. Además, la organización del evento fue impecable. Todo estuvo siempre en su lugar y los anfitriones estaban más que dispuestos a ayudar siempre. De verdad, han ganado mi admiración y respeto por tan excelente trabajo y por ser además excelentes personas a la vez.

Las primeras clases fueron bastante básicas, pero fueron aumentando el nivel poco a poco. Los problemas en los simulacros de competencia eran bien serios. Algunos días fueron más sencillos que otros, pero siempre lograba hacer sólo entre 3 y 6 problemas (de 10 a 11 que había diariamente) y pocos de ellos eran sencillos. Fue realmente divertido y me sirvió mucho para quitarme el óxido y volver a estar en forma de competidor. Como entrenador de los equipos de la USB es mi responsabilidad continuar aprendiendo y mejorando, para poder ser un mejor apoyo para ellos y que cada vez más demos una buena competencia en el mundo.

Conmigo fueron dos equipos. Uno de la USB llamado RAM (Rubmary, Augusto y Mathías) y uno de la UCV llamado NPI-Complete (Rodolfo, Samuel y Germán). Ambos equipos aprovecharon muchísimo el campamento y quedaron en buenas posiciones, considerando el nivel de los equipos restantes en el campamento (habían muy buenos equipos de todas partes de latino-américa). Estoy sumamente orgulloso de ambos equipos y del excelente papel que hicieron durante el campamento, tanto en lo técnico como en lo personal. ¡Bravo! :D

Los últimos dos días decidimos (los de RAM y yo) regresar a Buenos Aires y pasear un poco. Buenos Aires es posiblemente mi ciudad favorita en el mundo y las veces que he tenido la oportunidad de visitarla siempre termino más y más enamorado de ella. En dos días recorrimos mucho de la parte turística de la ciudad y caminamos como si no hubiera un mañana, jeje. De verdad fue una muy genial experiencia, que culminó en la visita de mi local favorito: Antares, hogar de la mejor cerveza que he probado en mi vida. Todas son excelentes, casi sin comparación, pero la Indian Pale Ale de Antares es la campeona incuestionable para mi, tan excelente como la recuerdo. <3

Y bueno, esto fue un resumen muy resumido de este genial viaje y que quería compartir por acá. ¡Gracias por leer! Y espero seguir contándoles de experiencias geniales como ésta, mientras seguimos creciendo y mejorando. ¡Hasta una próxima entrada! :D

¡Semana de la Carrera!

Estos últimas días me han regalado muchísimos éxitos y cosas buenas. Las iré contando poco a poco, y ahorita quiero comenzar con lo que fue una excelente semana de la carrera. Tuve el gusto de poder ayudar durante una buena parte de la misma y de recibir algunas muy gratas sorpresas en el proceso.

¡Semana de la carrera FTW!

El Lunes de esta semana fue un día de programación y competencia mientras se celebró el segundo minimaratón de programación bajo la gestión del CEIC 2014-2015. Una vez más una excelente organización bajo el liderazgo de Wilmer Bandres que, no sólo es un excelente competidor, sino una excelente persona preocupada por ayudar a las generaciones futuras a alcanzar su potencial. Tuve el gusto de formar parte de esa experiencia, acompañando y dando apoyo moral durante el evento. Aunque firmé como "jefe de jurados", el crédito es para Wilmer. Yo también pasé por eso en algún momento, jajaja. Lamentablemente, la firma de un profesor vale más en un certificado. Pero quería dejar claro de quién es el crédito realmente.

El Martes de esta semana fueron las infoelectivas e infoagrupaciones, donde tuve la oportunidad de hablar sobre las cadenas de "lenguajes de programación" y "diseño de algoritmos" (y de algunas otras, un poco coleado, jajaja). Siempre es divertido ver las expectativas de la gente e intentar guiarlos para escoger algo que pueda gustarles y serles útil. Además, por supuesto, pude hacer publicidad de un par de cadenas electivas geniales, jajaja.

El Miércoles de esta semana fue el tan esperado Compushow. El evento quedó geniaal, y mucho más aunado a que recién fueron las JOINCIC y el tiempo para la organización debió ser muy limitado. ¡El video que hizo la gente del MAC quedó sencillamente genial! Tomaron un chiste viejo y malo y le dieron un toque fresco. Además tuve la oportunidad de presentar la nominación de "compucuchi" y de pensar rápidamente tras la cortina lo que iba a decir (la gente se rió, así que me imagino que no fue tan malo, jajaja).

Tuve el gusto de estar nominado en tres categorías: Compugordito, Compucompadre y Compumaster. ¡Y gané en los dos primeros! El premio de Compugordito es gracioso, por que realmente ya no gordeo tanto en la sala, pero la fama es una cosa seria, jajaja. Lo que si me sorprendió y me dejó casi sin palabras es haber ganado el Compucompadre. ¡Wow! Que chéveres son todos. :3 En ese momento di un minidiscurso y lo que dije aún lo creo: "En la descripción de la categoría decía 'el computista más pana', pero no es difícil ser pana de todos cuando todos en computación son tan geniales y panas para empezar". De verdad gracias por esa muestra tan grande de cariño. Vale mucho, así como toda mi gente computista. ¡Son lo máximo!

Muchos me han dicho que votaron por mi en Compumaster, pero ese premio si no lo gané. El ganador fue Ernesto Hernandez-Novich, un excelente profesor y amigo, modelo a seguir para muchos de nosotros. Nada más estar nominado entre tantos de mis profesores, a quienes tanto admiro y respeto, ya es un motivo de enorme orgullo para mi. ¡Gracias a todos por ese honor! Seguiré, mientras pueda, haciendo esto que tanto me encanta de dar clase y compartir el compugallismo con todo el que así lo desee. :D

El Jueves di un coloquio llamado "Chose your weapon: Cómo saber qué lenguaje/herramienta usar al enfrentar un problema de la vida real". Básicamente fue un reboot extendido de la charla que di en las 7mas JOINCIC, el año pasado. La charla era a la 1:30pm y para casi las 2:00pm. sólo habían como 10 personas. Después de un rato llegaron más (muchos del CEIC, evidentemente para que no se sintiera vacío su propio coloqio, jajaja). La cantidad de asistentes era esperada en mi opinión; cada quien está metido en su mundo y ya invirtieron tiempo en las JOINCIC una semana atrás. Pero al menos pude ayudar al CEIC dando un coloquio y me divertí mucho dándolo (creo que los asistentes se divirtieron también, o al menos se rieron, jajaja).

El Viernes si no hice nada... Nadaaaa... xD Bueno, nada de la semana de la carrera. Como siempre tuve 20.000 reuniones y cosas que hacer, jajaja.

Y bueno, esta fue la semana de la carrera para mi. Quizá no suene a mucho, pero para mi fue una excelente semana de la cual estoy más que agradecido. ¡Gracias por leerme y hasta una próxima entrada! :D

Cómo Programar

¡Me encanta programar! Es una de las cosas que más me divierte y me llena de mi carrera. Programar es una actividad que involucra tanto la creatividad, como la habilidad técnica y hacerlo bien puede potenciar incluso múltiples regiones de la mente.

¡Programar siempre es emocionante! :D

Sin embargo, quienes me han visto programar sabrán que yo suelo programar "extraño".

¿Cómo así?

Yo puedo pasar horas sólo viendo la computadora o incluso estar aparentemente procrastinando por la web, pero eventualmente abro el editor y básicamente escupo todo el código en cuestión de minutos. Algunos confunden la procrastinación con flojera, pero es muy al contrario. Cuando parezco estar haciendo nada, en realidad estoy pensando y planificando como voy a programar lo que necesito: las estructuras que hacen falta, algoritmos eficientes y patrones reutilizables de otras cosas que ya haya hecho. De repente, sale todo ese código y la gente se queda sorprendida con la velocidad en la que se me ocurrió todo. Pero la verdad, es que no hay realmente ninguna velocidad extravagante involucrada. Sólo una metodología de pensamiento diferente, donde primero se diseña y luego se programa. :)

La gente de Sistemas de Información, a pesar de sus documentos infinitos (los cuales, hay que confesar, contienen mayormente información inútil), tienen sin embargo un concepto acertado: Para programar bien, primero hay que planificar. Lamentablemente esto se enseña en torno a requerimientos y, en menor medida, a herramientas y patrones. Pero realmente no se enseña a planificar y diseñar soluciones con tipos de datos y algoritmos adecuados. Se enseña muy bien a tener claro lo que se desea hacer, pero muy poco se ahonda en tener claro cómo hacerlo.

Por todo esto, quisiera compartir con ustedes cuales son las reglas fundamentales en mi proceso al programar (al menos en la mayoría de los casos):

• Regla fundamental No. 1: No echar ni un caracter de código, hasta haber planificado la estructura y funcionamiento básico del programa. Esto ahorra muchísimo trabajo al final, en especial de refactorizaciones constantes. Al principio no se verán resultados tangibles, pero cuando comiencen a aparecer será tan veloz que parecerá algo mágico, jajaja.
• Regla fundamental No. 2: Los lenguajes y herramientas son diversos por algo. Cada problema tiene diferentes características y diferentes herramientas pueden ser mejores o peores en determinados momentos. Es importante conocer y dominar varias formas de pensar y resolver problemas para así poder seleccionar la más adecuada en cada situación. Por poner un ejemplo, creo que nadie duda que hacer una aplicación web en C sería un dolor de cabeza, pero para programar sistemas de operación pocos lenguajes se le comparan. ¿A su vez, cómo sería programar un sistema de operación en un lenguaje como Ruby? Cada herramienta tiene su dominio y por esto es importante saber distinguir entre ellos.
• Regla fundamental No. 3: Pensar a futuro. Este es un hábito difícil de adquirir, pero sumamente útil si se domina. La verdadera parte complicada al programar está en diseñar la solución. Una vez el diseño de estructuras y algoritmos está completo, efectivamente programar la solución es en verdad un trabajo mecánico. Como tal, consume muy poco procesamiento mental realmente. Por lo tanto, es posible (aunque repito, difícil en un principio) seguir planificando a futuro mientras se programa lo que ya está planificado. Algo así como el pipeline del procesador que mientras ejecuta una instrucción ya interpreta la siguiente. Esto hace que la programación sea un poco más fluida y rápida. Además mantiene la mente activa y evita los peligros de contraer flojera crónica entre "sprints" de implementación.
• Regla fundamental No. 4: ¡Reutilización por siempre! Y no sólo me refiero a reutilización de código, sino también de procesos mentales. Muchos problemas son parecidos o tienen componentes parecidas entre si. Aunque finalmente el código no sea el mismo (por una u otra razón), el proceso mental que llevó a solucionar un problema puede llevar a solucionar otro. Por ejemplo, si se pasó un par de días resolviendo una conexión entre una aplicación web y una base de datos de forma eficiente, el mismo proceso puede reutilizarse si en algún momento se debe conectar eficientemente una aplicación móvil a una base de datos local (a pesar de que muy posiblemente, el código sea bastante diferente).
• Regla fundamental No. 5: Nunca perder la práctica. Es importante mantenerse programando y no únicamente en un área específico. Se debe intentar explorar nuevas áreas sin descuidar aquellas que ya se han explorado antes. Por ejemplo, a un programador web deberían poder asignarle un trabajo de bajo nivel (implementar un driver, por ejemplo) y no debería ser el fin del mundo para él, sino sólo un reto más a superar y una nueva oportunidad para aprender y practicar algo diferente.

Las tres primeras reglas fundamentales, potenciadas con la cuarta y la quinta, hacen que un programador luzca como un verdadero mago. Después de unos minutos pensando en un problema complejo, puede producir código muy rápido que lo soluciona. Y muy posiblemente, código eficiente, reutilizable y hasta seguro. Todo depende de cuanta experiencia se tenga. Como ejemplo personal, estoy claro que al programar en un lenguaje funcional (como Haskell) puedo llegar a hacerlo sumamente rápido. Pero eso no es más que una mezcla de pasión y experiencia. Eso no me hace más inteligente que nadie, ni mucho menos. Estoy totalmente seguro que todos y cada uno son mejores que yo en algo. Pero finalmente, creo honestamente que la experticia en cualquier herramienta o dominio siempre puede lograrse no más que siguiendo estas 5 reglas fundamentales.

Todas estas reglas dependen claro, de una que es incluso más fundamental y básica:

• Regla fundamental No. 0: No puedes escribir un programa para resolver un problema que no entiendes. Es sumamente nocivo intentar resolver un problema, cuando no se tiene claro cuál es siquiera el problema que se necesita resolver. Esto, lamentablemente, es más que común por los tiempos apresurados de producción en la industria de la computación. Sin embargo, debe evitarse a toda costa. Lo primero que debe asegurarse siempre es haber entendido el problema, luego entender cómo resolverlo, luego con que herramientas y sólo entonces se debe echar manos a la obra e implementar. (gracias a Ernesto Hernandez-Novich por el comentario que inspiró esta regla adicional).

Y bueno, esto quería compartir con ustedes hoy. Éste es mi extraño método y debo decir que muchas veces me ha funcionado bastante bien (aunque puede ser terrible cuando hay deadlines cercanos involucrados, pero ese es otro cuento, jajaja). Cualquier comentario, como siempre, es más que bienvenido. ¡Hasta una próxima entrada! :D

De aprender y enseñar

Como muchos que me conocen saben, me encanta mi carrera y me apasiona aprender siempre nuevas cosas y mejorar día a día. Pero hay una cosa que me mueve más que nada en el mundo: enseñar, compartir, ayudar a otros a crecer. Creo que en cada persona existe un potencial enorme de grandeza. Poder ser aunque sea una pequeña parte de lo que impulse a una persona a encontrar esa grandeza es un orgullo y un privilegio sin duda. Es la fuerza que me mueve y mi propósito de vida. :)

No podía dejar pasar este chiste malo, jajaja.

Desde que comencé a estudiar mi carrera, siempre me he preocupado por contribuir (de la mejor manera que mi limitada experiencia me permitiera) en ayudar a los demás y mejorar mi carrera. Fui preparador la mayor parte de mi pregrado y luego de eso, ayudante académico y finalmente profesor. Hasta donde la voz y el voto me permitieron en cada etapa, siempre intenté proponer nuevas herramientas que motivaran a aprender. Intentar mostrar un poco eso que siento al aprender algo nuevo, de la inspiración y el descubrimiento, para que otros puedan contagiarse quizá un poco y seguir aprendiendo y descubriendo por su cuenta.

Es por todo esto que muchas veces actúo como actúo. Soy el "profesor niño", aquel al que se confunde con un estudiante más si no fuera por la cara de viejo, jajaja. Muchos profesores creen que el camino al aprendizaje es a través del respeto y la distancia. ¡No estoy de acuerdo! Honestamente, creo que el mejor camino al aprendizaje es a través de la confianza, el humor y la automotivación constante. No sólo se crea el ambiente para que los demás aprendan más fácilmente, sino que a cambio terminas aprendiendo muchísimo más de tus estudiantes, tanto académica como personalmente.

Las responsabilidades de un profesor en una universidad, lamentablemente, no están centradas en la docencia y en la formación de los futuros gigantes. En cambio, está centrada en el descubrimiento y diseminación de nuevas ideas a través de la investigación. A pesar de que es algo que también me gusta y por lo que tengo un respeto enorme, no es realmente lo que me apasiona y es respecto a este único atributo que se mide la valía de un profesor e incluso de una universidad. He visto estudiantes de diferentes universidades que se enorgullecen al ver los rankings de universidades y ver sus propias casas en la delantera. Pero ese ranking lamentablemente no tiene nada que ver con la calidad de sus egresados, sino con la cantidad de publicaciones realizadas por profesores adscritos a ellas.

Creo que debería existir la figura del profesor docente, que pueda dedicarse a enseñar y no tanto a investigar. Así mismo la del profesor investigador, que sea justamente lo contrario. Conozco profesores a los que no les gusta enseñar, pero que son excelentes investigadores y eso es lo que les motiva. Eso está muy bien y tienen la suerte de vivir en un mundo donde ese talento es dado mayor importancia, pero deberían existir alternativas a ese filosofía. A su vez debería existir alguna medida, aunque sea difusa, de la calidad docente de una universidad (existen clasificaciones culturalmente aceptadas, pero ninguna formal o basada en argumentos sólidos). Y no lo digo por el reconocimiento involucrado, sino para que aquellos a los que nos apasiona enseñar tengamos la libertad de centrar nuestro trabajo y energía en justamente eso.

Y bueno, cuando comencé a escribir sobre esta entrada, en realidad se trataba de otra cosa pero me desvié, jajaja. Tengo en planes (aunque sin fecha de inicio estipulada) volver a estudiar mi carrera completa por cuenta propia y afinar los detalles que no comprendí por completo. De hecho, he estado haciendo eso ya por algún tiempo. Durante mis estudios, siempre que una materia me gustaba pero no la comprendía completamente hacía lo posible por dar la preparaduría en algún momento. Eso me pasó con una de mis materias favoritas: Traductores e Interpretadores. ¡Esa materia me encantó! Pero a duras penas la pasé (51/100 like a boss, jajaja). Y me fijé comprenderla, enseñándola. Y así fue. :)

¿Cómo planeo repasar mi carrera ahora? Leyendo más que todo, pero con un objetivo concreto en mente: Realizar un repositorio de guías y ejemplos de cada cosa que repase. De esa manera, no sólo aprenderé con mayor profundidad, sino que dejaré algo para que los demás puedan apoyarse en su aprendizaje también. Es un proyecto personal de gran escala y para el cual lamentablemente no cuento con tiempo ahora, pero me encantaría comenzarlo lo más pronto posible.

Y bueno, esto era lo que quería compartir por ahora con ustedes. Solamente un desahogo personal. Cuento con la suerte y el honor de pertenecer a grupos de investigación conformado por algunas de las mejores personas y docentes que conozco, lo cual ha hecho todo muy divertido e interesante. Pero siempre me hace falta ese algo extra especial. El brillo en la mirada de una persona que no sólo acaba de comprender algo, sino que disfrutó aprenderlo y está listo para utilizarlo en su vida. El agradecimiento sincero, aunque sea tácito, de quien halló su vocación y camino en parte con tu ayuda. Ese rincón en el corazón de todas las personas que compartieron contigo y con quienes lograste crecer mutuamente. Son cosas como esa a las que no se les puede poner precio y llenan la vida de color (seh, momento cursi del día patrocinado por Ricardo, jajaja). Hasta una próxima entrada y gracias por seguir leyendo estas locuras ocasionales. n_n

Semana CoNCISa

Finalmente llegó el momento de colgar el distintivo y disfrutar de un merecido día de descanso. ¡Ha concluido la 2da Escuela Venezolana de Informática y Conferencia Nacional de Computación, Informática y Sistemas!

¡COnferencia Nacional de Computación, Informática y SistemAs!

Fue una semana de trabajo duro, pero que valió muchísimo la pena. Ambos eventos (EVI y CoNCISa) salieron super bien y creo que los asistentes salieron bastante satisfechos. Tuve el gusto y el privilegio de ser parte del equipo organizador del evento (aunque la invitación fue tardía, y no pude ayudar en el previo tanto como hubiera querido, pero igual pude dar mi todo para que el evento saliera bien, jeje). Tuve la oportunidad de compartir con queridos colegas ya conocidos y la dicha de conocer a otros más. Además, tuvimos la invaluable ayuda de un equipo de logística formado por estudiantes voluntarios de varias universidades. A la mayoría ya los conocía y son personas geniales. Los que no, pronto descubrí que también eran excelentes personas y pasamos una genial semana entre todos haciendo posible estos eventos (y haciendo Origami, jajaja).

Ambos eventos fueron con sede en la UCAB (Universidad Católica Andrés Bello). Como otras veces que esta universidad ha sido casa para eventos académicos, el lugar fue excelente y todas las cosas funcionaron muy bien. Además, para mi, la UCAB tiene un "no se qué" que me hace sentir muy a gusto. Siempre me ha parecido que tiene un ambiente muy relajante y unos jardines sumamente estéticos y bien cuidados. Después de mi adorada USB, creo que es uno de los sitios en donde me siento más a gusto. Además, estaba lleno de gente genial de muchas diferentes universidades, lo cual lo hizo aún mejor. :)

No pude entrar a muchas de las charlas, ya que estuve ocupado en la organización. Sin embargo, tuve el gusto de poder asistir a tres muy buenos subeventos:

• En primer lugar, fui el moderador del tutorial "Herramientas para la Gestión de Eventos Académicos en Línea", dictado virtualmente por el prof. Raymond Marquina de la ULA (excelente persona y profesional, al menos en lo poco que tuve el gusto de compartir con él). A pesar de un inconveniente con la luz, que se fue en casa del presentador y tuvimos que sobrevivir con puro audio vía plan de datos (ese si es un plan de datos vale, jajaja), la charla estuvo buenísima y aprendí bastante.
• En segundo lugar, pude asistir y ser chair de la 4ta (y última) tanda de ponencias del segundo día de CoNCISa. Hubo muchas buenas charlas de diferentes temas, en realidad muy interesantes. Además, aquí presenté yo mismo una charla llamada "Hacia la Verificación de Programas que Manipulan Estructuras Recursivas Generales Mediante Apuntadores", correspondiente al trabajo enviado en conjunto con Jesús Ravelo. Volví a leer el artículo preparando la presentación y sigo enormemente orgulloso del resultado y agradecido por toda la ayuda, guía y amistad de Jesús. ¡Es en verdad invaluable! Y la presentación creo que salió bastante bien, aunque quedaría de la audiencia constatarlo, jajaja.
• En tercer lugar, pude asistir a la presentación del premio a la destacada trayectoria para mi amigo y profesor, Jorge Baralt. Además de emotivo, todo el acto fue en realidad super gracioso, por diversas razones. Nada más la exposición del curriculum fueron casi 10 minutos, jajaja. Y el discurso de aceptación fue lo máximo: "Me dijeron que tengo solo dos minutos... El primero y el último me imagino." y "Seré breve entonces: Gracias... ¿Ahh? ¿Un poco menos breve? Muy bien... Muchas gracias", jajaja. Después de ahí si se enserió un poco el discurso y dijo algunas excelentes e inspiradoras palabras. ¡Qué gusto y qué privilegio conocer a una persona tan valiosa en verdad! :)

Fue una semana interesante y entretenida, aunque fuerte. Una cosa divertida es que los últimos dos días y medio estuve encargado de las ventas de souvenirs del evento. He descubierto mi don y gusto de venta, jajaja. La apodaron "La tiendita de Ricardo" y se pudo vender unas cuantas franelas, chemisses y hasta libros con las memorias de CoNCISa del año pasado. Además, vendimos tantas membresías a la Sociedad Venezolana de Computación que nos quedamos sin facturas. Fue divertido eso, jajaja. Cuando no estuve en la tiendita, estuve más que todo en la mesa de registro. ¡Ese trabajo me encanta! Tengo la oportunidad de tratar y conocer a mucha gente nueva, y ayudarlos a tener la mejor experiencia posible. Recibí a cada uno con una sonrisa, no sólo por que es lo indicado, sino por que estaba genuinamente feliz de estar ahí ayudando y conociendo nueva gente.

El acto de clausura también estuvo buenísimo, con una agrupación tributo de Les Luthiers llamada "Los Experimentados" (o algo así). ¡EXCELENTE! Hicieron dos obras originales que estuvieron realmente buenas. Es una lástima que sean prácticamente invisibles en la web. No he podido encontrar nada sobre ellos posterior al evento, pero fue realmente genial. ¡Ojala logren surgir y triunfar como grupo!

En fin, excelente semana. Tuve el gusto de conocer a mucha gente nueva y compartir con viejos y nuevos amigos. Me encantó la hermandad que vi entre las diferentes universidades. Sin las competencias, ni los delirios de superioridad, ni discriminaciones. Tan sólo un grupo de gente unida por su pasión por la computación y las ganas de ayudar a realizar un gran evento. ¡Qué orgullo haber formado parte de este gran equipo! Espero poder colaborar nuevamente el año que viene y en cualquier otro evento de este estilo. Fue una gran experiencia en verdad. ¡Gracias a todos! :D

Y esto era lo que quería compartir por ahora. Tenía bastante tiempo sin escribir, jeje. He estado realmente ocupado, con mil cosas que hacer. Estas semanas venideras ya deberían ser un poco más ligeras, pero ya veremos, jajaja. ¡Hasta una próxima entrada!

Retomando un viejo proyecto: Guerra de Clases

Como muchos saben (y los que no pueden inferir de que a cada rato comparto cosas de este blog, jajaja), me gusta escribir. Además de este blog y del blog para mis cómics ( Bulda-E-Bien - A Web Comic ), también llevo un blog para cosas que escribo ( Ideas Nada Mas ), tanto ideas locas como mini-relatos. Aunque confieso que no escribo tanto como antes o como quisiera en ese blog, jeje.

O quizá P = NP. ¿Quién sabe? :D

En el 2010 escribí un cuento llamado "Guerra de Clases" ( Guerra De Clases ), que trataba de una guerra entre los clanes P y NP (seh, las clases de complejidad computacional, jajaja). Al final me había gustado bastante el resultado, pero lo dejé hasta ahí.

En el 2012 pensé que ese cuento podría expandirse y volverse quizá un mini-libro completo con bastantes referencias gallas a teoría de lenguajes. Realicé una planificación para la expansión del cuento y escribí el capítulo 0: "Igualdad" ( Guerra de Clases: Capítulo 0 - Igualdad ). Peeeero, también quedó hasta ahí. Realmente no continué con el proyecto.

En estos días decidí revisar las cosas que tenía en un disco duro viejo y encuentro una carpeta con cuentos e ideas para cuentos. ¿Con que me consigo? ¡La guerra de clases! Y pensé que quizá sea hora de retomar ese proyecto. Así que saqué papel y lapiz (o más bien teclado y LaTeX, jajaja) y comencé a actualizar lo que ya tenía. ¿El resultado? Una nueva versión para el primer capítulo, más pulida y organizada (creo yo).

Pueden leerla en el siguiente enlace:

( Guerra de Clases: Capítulo 1 - Igualdad )

¿Qué opinan? :D

El plan es que tenga unos 10 capítulos, lo que en promedio lo haría como de 40 páginas (no muy largo). Aunque quizá llegue una inspiración brutal y se extienda un poco más, jajaja. ¿Quién sabe? XD

Y bueno, eso es lo que quería compartir por ahora, quizá pronto vuelva a escribir sobre el siguiente capítulo. ¡Hasta una próxima entrada! :D

Capítulos posteriores:

( Capítulo 2 - Un nuevo y grandioso poder )

Discreto, Funcional, Implacable...

Como algunos ya saben, desde hace un tiempo he estado interesado en aprovechar las facilidades que trae un lenguaje funcional puro en la enseñanza de las matemáticas discretas. La primera entrada al respecto en este blog está aquí: ( Discretamente hablando: Haskell ). En esta ocasión quiero continuar con esa discusión, planteando una implementación directa del primer tema que se toca en el curso de Estructuras Discretas III de la USB: Los números enteros.

Like a sir, indeed!

Para este curso se usan las muy completas guías que realizó el profesor Yriarte (disponibles en: http://ldc.usb.ve/~yriarte/d2index.html). Que plantean muchos de los conceptos y propiedades importantes en un lenguaje fácil de entender (además que esté en Español, lo cual ayuda mucho a quien no maneja del todo el Inglés). Sin embargo, creo que se puede ir mucho más allá de una guía estática y convertirlo en una ayuda interactiva y flexible mediante el uso de un lenguaje como Haskell.

¿Por qué Haskell? Porque es un lenguaje funcional puro, de muy alto nivel, en el que las definiciones matemáticas abstractas son casi directamente plasmables de forma clara y compacta. Además, el sistema de tipos estático ayuda en gran medida a la correcta definición de las funciones y los tipos de interés. ¿Por que no algo más especializado como Coq o Idris? (Excelente sugerencia de Manuel Gómez en la entrada anterior) Las únicas razones válidas hasta el momento: tiempo y falta de experiencia. Estos lenguajes/herramientas tienen sistemas de tipo mucho más elaborados y rigurosos que permitirían mucha más confianza en las definiciones hechas. Incluso, permitirían la elaboración de pruebas simbólicas en el contexto del mismo lenguaje (ver: Idris: verifying a monoid). Sin embargo, explorar las capacidades de estos lenguajes y de como acotarlas a un nivel que sea a la vez correcto, pedagógico y práctico, es algo que tomaría tiempo y por tanto estaría sujeto a una próxima iteración de cambios.

Antes de comenzar con los temas correspondientes a Estructuras Discretas III, hacen falta algunos preliminares (idealmente, ya se hubiera usado un lenguaje como Haskell al menos en Estructuras Discretas II, pero no es el caso en esta ocasión). En particular: lo que quiere decir poder hacer aritmética sobre un tipo determinado y el tipo de los números naturales. Nótese que hablo de tipos en vez de conjuntos. ¡Esa es una de las principales ventajas del enfoque funcional! Se desliga de la fundamentación en conjuntos (heterogénea y complicada) a una fundamentación en tipos (homogénea y constructiva). Para una discusión mucho más elaborada de esto basta ver cualquier libro de teoría de tipos básica y empezar a notar todas las ventajas. Teorías de tipos más complejas dan aún más comodidades, a expensas de claridad en la presentación y por tanto se intentará mantener la presentación lo más sencilla posible (por ejemplo, la igualdad será considerada una proposición, no un tipo como es costumbre en teoría de tipos).

A continuación un archivo Haskell con la implementación de los preliminares necesarios hasta el momento:

preliminares.hs

A continuación un archivo Haskell con la implementación de los números naturales como números de Church:

naturales.hs

Una vez se han establecido los preliminares, se puede comenzar a tocar temas de Estructuras Discretas III. La primera guía de Yriarte (ver: Capítulo Uno) se trata de los números enteros. En particular, la sección 1.2 los define y plantea algunas propiedades sobre los mismos. A continuación un archivo Haskell con la implementación de los números enteros, según la guía antes mencionada:

enteros.hs

Es notable como poco a poco aumenta el nivel de abstracción hasta el punto que, en la definición de la función valor absoluto (abs), la implementación interna y complicada de números enteros se vuelve completamente transparente. ¡Esta es la belleza de una teoría constructiva!

Desventajas: Hay una inconsistencia entre la definición formal de los números enteros y la que plantea el tipo en Haskell. Los enteros son clases de equivalencia (conjunto cociente del producto N x N con respecto a la relación planteada en la ecuación 1.1). En Haskell, son tratados simplemente como miembros del producto N x N. Esto por varias razones: La guía tiene la misma inconsistencia con respecto a la definición, pues plantea las propiedades y definiciones posteriores en términos de N x N y no del conjunto cociente. Pero la más importante de las razones sería que realmente no encuentro una manera fácil e intuitiva de construir un tipo que corresponda a clases de equivalencia, sin entrar en temas muy oscuros como para una materia introductoria. (Se aceptan sugerencias en este punto).

A través de las definiciones en Haskell se puede notar una falta de estandarización en los nombres. Por ejemplo, a veces las variables son x, y, z... otras son m, n, p... y otras son a, b, c... sin motivo aparente.  Estas son importadas directamente de la guía, para no chocar con los nombres ahí utilizados. Además, algunas proposiciones son "propiedades" y otras son "teoremas". Ambas son demostrables a partir de las definiciones dadas. ¿Por qué la distinción? Ese tipo de detalles y muchas otras cosas más que me parece que faltan me hacen pensar que quizá sea más interesante, en vez de implementar un apoyo a las guían que ya existen, hacer un reboot y reescribir las guías desde un punto de vista funcional. ¡Quizá hasta un libro! Independiente del curso y general para cualquiera interesado en hacer matemáticas discretas desde un punto de vista funcional. Hasta les tengo el nombre ya (hint: el título de esta entrada es un spoiler). Se llamaría "Discreto, Funcional, Implacable..." y me imagino que la portada sería algo como un James Bond sosteniendo un arma que en realidad es un lambda. Pero esos ya son detalles no tan importantes (aunque divertidos. XD).

¿Qué opinan? ¿Va por buen camino? Gracias a muchos comentarios de diversas personas la cosa ha ido tomando forma. Me gustaría seguir recibiendo opiniones con respecto a esto para enriquecerlo y terminar con una propuesta sólida, implementable y divertida. ¡Muchas gracias a todos los que han ayudado (y a los que ayudarán. XD)!

Hasta una próxima entrada. :)

La falacia del testing y algo más

Hoy quiero hablarles de una de las más aceptadas metodologías de desarrollo en el ámbito industrial (e incluso en el académico), aquella conocida como "test driven development". En este enfoque, lo primero en diseñarse son los casos de prueba que se desea que pase exitosamente un cierto programa y luego se implementa dicho programa de forma que satisfaga estas expectativas. El proceso puede ser iterativo, incorporando nuevos casos y posiblemente alterando la implementación realizada acorde a estos. Esta estrategia tiene una grandiosa ventaja: Permite al programador estar más claro desde el principio en lo que quiere implementar y las propiedades que cumple. Además le otorga un mecanismo para descubrir fallas en su implementación o en su intuición (siempre puede haber errores en la definición de casos de prueba también). Incluso hay muy buenas herramientas que permiten realizar pruebas unitarias con facilidad. Lo que es una lástima... es que está severamente limitado.

Ni tan exagerado. XD

¿Cómo que está limitado? El enfoque del "test driven development" está basado en un conjunto de prueba que sirve como heurística para la totalidad de las posibles entradas al sistema implementado. ¿Pero como asegurar que es una buena heurística? Un programa tan sencillo como un factorial tiene como dominio a la totalidad de los números enteros. Incluso restringiendo el mismo a un lenguaje de programación con enteros de 32 bits, existen 2^32 posibles entradas para el programa. Hacer 100 o hasta 1000 pruebas es totalmente insignificante. Para programas apenas un poco más complejos, las posibilidades se hacen completamente inmanejables. Claro, estas pruebas pueden diseñarse para englobar características de un gran conjunto de posibles entradas que, junto a la "buena intención" del programador, pueden dar una confianza aceptable en la calidad de la solución. ¿Pero cómo asegurar que se considera la totalidad de las opciones? Esto puede mejorarse incluso haciendo que el diseño de pruebas sea realizado por un equipo diferente e independiente del equipo implementador (de lo contrario, las pruebas estarán influenciadas por las propias expectativas de la solución ya planificada). Pero aún con todo esto, no parece ser suficiente.

Me imagino dos reacciones razonables al párrafo anterior: "Si, la estrategia tiene fallas, pero es mejor que nada" y la clásica "Bueno, ¿y tu que propones?" (no pude evitarlo, jajaja). La primera tiene toda la razón. Una estrategia que haga consciente al programador de lo que quiere implementar antes de empezar a echar código es mucho más responsable que la alternativa "dale play y si explota ahí vemos". Pero hay una opción que es mucho mejor y con eso aprovecho y respondo a la pregunta de la segunda reacción: el "contract driven development" o "design by contract" como lo llamó Bertrand Meyer (el pana que creó el lenguaje Eiffel). Sin embargo esto no es nuevo, viene de una larga línea de grandes pensadores de las ciencias de la computación en donde destacan personalidades como Edsger Dijkstra, Tony Hoare y hasta el mismísimo Alan Turing.

Este enfoque de diseño por contratos está basado en la filosofía de que todo programa puede especificarse formalmente. Esto es, las condiciones que se esperan al inicio, al final e invariantemente durante la ejecución del mismo pueden ser descritas por medio de alguna lógica formal. Esto se extiende a instrucciones, expresiones, tipos de datos, subrutinas, etc. Estas especificaciones o contratos se establecen antes de comenzar a implementar las soluciones y cumplen con dos objetivos importantes:

• Los programadores tienen una idea clara de lo que deben implementar, las garantías con las que cuenta su programa (la forma del dominio) y lo que se espera del mismo al finalizar su ejecución. Esto guiará una implementación mucho más sólida y clara.
• Una vez implementada la solución, la misma puede verificarse formalmente vía una demostración rigurosa que asegura, sin cabida a dudas, que la implementación cumple con lo establecido en su contrato.

¿Y que pasó con los lenguajes funcionales, que están en un nivel de abstracción tan alto que el programa mismo es su propio contrato? ¡Mejor aún! Tal nivel de abstracción es ideal para hacer pruebas simbólicas sobre los programas escritos directamente y finalmente tener la misma calidad y confianza (quizá hasta más que en un contexto imperativo). Más aún, pueden especificarse propiedades adicionales apoyadas por el sistema de tipos (la firma de una función es un contrato para la misma).

Sin embargo, esta solución tampoco es perfecta y tiene una buena cantidad de fallas significativas:

• El contrato aún es tan bueno como la intuición de quien lo diseñó. Lo que se quiere puede estar mal especificado o, incluso, puede que no se esté claro siquiera cuál problema quiere resolverse realmente.
• El tiempo dedicado para diseñar contratos y la posterior verificación de los mismos es mucho más grande que en otras estrategias de desarrollo. Los resultados tangibles pueden verse sustancialmente atrasados.
• El contrato, similar a los casos de prueba, debe ser elaborado por un equipo independiente al implementador. La diferencia reside en que un contrato requiere de mucha más experiencia y formación que un caso de prueba, lo cual eleva las exigencias académicas y de personal necesarias para llevar a cabo un proyecto.

La primera falla es inevitable. Programar es una actividad humana y como tal está susceptible a tener fallas siempre. Lo que uno puede intentar es reducir estas fallas lo más posible y contenerlas de forma tal que los resultados sean suficientemente confiables. La segunda falla no es tanto una falla como más bien una inversión. Sí, un proyecto que pudiera haber tomado 3 meses, tomó quizá 6 a 8. ¡Pero se ahorraron los potenciales años reparando bugs, con una solución de calidad! La tercera falla es real y difícil; mucho más cuando una gran cantidad de programadores y profesionales de la computación están completamente desligados y desinformados en lo que concierne a métodos formales. Los que si los conocen están usualmente confinados a la academia o pueden llegar a ser muy costosos. Es mi opinión, y la de algunos otros que conozco, que todo profesional de la computación debería tener una formación sólida en métodos formales y hacerlos parte de sus herramientas de trabajo en su día a día. Eventualmente, especificar un contrato será natural para muchos, tanto como lo es diseñar casos de prueba actualmente y tendremos sistemas mucho más confiables, seguros y mantenibles.

¿Pero entonces todo hay que demostrarlo? No necesariamente. Idealmente, si, eso daría el 100% de confianza. Pero el tiempo es un factor innegable y a veces de verdad no alcanza para todo el rigor involucrado en una prueba completa. Existen herramientas de verificación que permiten hacer algunas demostraciones de forma automática. Estas herramientas no son generales, ya que el problema de hacer una correspondencia de una implementación con un contrato se sabe indecidible. Sin embargo, pueden ahorrar bastante tiempo y esfuerzo en un principio y dar ciertas garantías sobre el comportamiento de un programa.

Hay que tomar en cuenta que tampoco es la intención que se elimine el testing por completo. Las máquinas no se comportan exactamente igual a la teoría; hay fallas inherentes a la implementación física de sus componentes. Además, pruebas concernientes al desempeño, a la resistencia ante muchas consultas simultáneas e incluso a la aceptación de la solución son aún necesarias, pero se delegarían a un siguiente paso del desarrollo.

Esto era lo que quería compartir por ahora (otro post más gallo aún, jajaja). Esto de los métodos formales no sólo es una rama fascinante de la computación, sino una que creo necesaria conocer para ofrecer soluciones confiables y de calidad. Como siempre, cualquier opinión es más que bienvenida. ¡Hasta la próxima! :)

Magíster en Ciencias de la Computación

¡Hoy fue el gran día! Finalmente, hoy a partir de las 10:00am. se celebró el acto de graduación en donde obtuve el tan anhelado título de Magíster en Ciencias de la Computación. ¡Que emoción! Me sentí igual de nervioso que en el acto cuando me dieron el título de Ingeniero (quizá hasta un poco más, jajaja). Mas ahora no cabe en mi la felicidad, el orgullo y la motivación para seguir aprendiendo y creciendo.

¡El título mesmoooh! :D

Fue un día repleto de emociones. Todo comenzó alrededor de las 4:30am., hora a la que nos tuvimos que levantar para llegar a tiempo al acto (a eso de las 7.30am.), y resulta que los de protocolo llegaron casi a las 9:00am., jajaja. En el acto me conseguí a muchísima gente que se graduaba también y que ahora puedo llamar colegas con orgullo y alegría. ¡Un privilegio compartir acto con tantos amigos y gente tan genial!

El acto estuvo muy bueno. El discurso de la graduando (Diosángeles) estuvo bastante bien, aunque quizá un poco lento y centrado en la experiencia IQ más que todo. Sin embargo, el mensaje se transmitió y realmente mereció dar ese discurso después todo lo que hizo por hacer posible esta graduación extraordinaria. El discurso del vicerrector lamentablemente dejó mucho que desear, ya que no tuvo casi nada que ver con el acto y además pintaba una escena muy negativa, incongruente con el ambiente de júbilo y celebración que debería ser propia de una acto de grado. Pero bueno, no todo puede ser perfecto, jajaja.

¡Que emoción cuando llamaron mi nombre! Y que orgullo escuchar tantas expresiones de apoyo de mi familia, amigos y colegas. ¡Un momento incomparable sin duda, fugaz pero eterno! Con orgullo aplaudí a todos los que vinieron después de mi (aunque debo confesar, que mucho más a los computistas, jajaja). Las canciones del orfeón estuvieron excelentes. El corte hacia el final de Barlovento y el arreglo armónico de la segunda canción quedaron buenísimos. Algo que me sorprendió era la poca cantidad de gente que cantaba el himno de la USB con el orfeón, aunque bueno, no siempre se oye ese himno, jeje. ¡Yo lo canté con orgullo! :D

Saliendo del acto, estuve un rato con mi familia y algunos amigos geniales hablando un rato y tomando fotos. Ahí fue que me dijeron que el porta-título tenía otra cosa (yo no la había visto). ¡Resulta que había una constancia de Mención Sobresaliente por el Trabajo de Grado! Que genial ver eso ahí, jajaja.

De ahí, a comer en Mokambo Caffe (en las Mercedes). Lo gracioso, es que habían otros graduandos ahí también. Pedimos ceviche y carpaccio de lomito como entrada, seguido de un risotto de cebollas gratinadas para mi (el resto de mi familia pidieron risottos de otros sabores, jajaja). ¡Que excelente estuvo! Y de poste una torta de queso, que estuvo simplemente mundial. Luego, fue tiempo de ir a visitar a la familia extendida (abuelos y tíos). Hicimos un brindis por el nuevo logro y pasamos un rato chévere (por supuesto, no podía faltar el "regaño disfrazado de felicitación" de todos los días con la familia indirecta de uno, pero la intención es buena que es lo que cuenta, jajaja).

Y bueno, después de un día fuerte pero genial (seguido de varios días de diligencias heavy metal), heme aquí escribiendo este post. ¡Estoy sumamente orgulloso y feliz! Y necesitaba compartirlo nuevamente por esta vía. ¡Gracias a todos los que me han acompañado, apoyado y alentado! Es un privilegio y un honor contar con su amistad y cariño. ¡Un abrazo gigante a todos! Será hasta una próxima entrada. :D

Electiva Hipotética: Programación Cuántica

Siguiendo con la serie de electivas hipotéticas, continúo con un área que falta en nuestro departamento: la computación cuántica. Claro, los modelos físicos que intentan hacer realidad una computadora cuántica competen es a los físicos. Sin embargo, los algoritmos que han de ejecutarse sobre dichas máquinas hipotéticas y el razonamiento formal sobre los mismos compete a las ciencias de la computación.

¡Este tema me encanta!

El curso que propongo a continuación está inspirado en el curso "Quantum Mechanics and Quantum Computation" que fue ofrecido por Coursera en 2012. Seguramente le faltarán muchas cosas interesantes de las que podrían hablarse, por lo que cualquier comentario es siempre bienvenido. :)

Asignatura: Programación Cuántica 

Créditos: 4 

Objetivo Principal: Introducir al estudiante a conceptos básicos de la mecánica cuántica, circuitos cuánticos y su uso en la implantación de algoritmos eficientes sobre máquinas cuánticas hipotéticas. Así mismo el razonamiento formal sobre estos algoritmos y de las clases de complejidad a las que pertenecen. 

Contenido:

• Semana 1: Introducción al pensamiento cuántico. Axiomas de la mecánica cuántica.

• Semana 2: Bases matemáticas: Números Complejos. Notación BraKet. Eigenvectores. Matrices Hermitianas. Productos de tensores.

• Semana 3: Qubits. Entrelazamiento cuántico. Paradoja EPR. Experimento de Bell.

• Semana 4: Compuertas cuánticas. Transformaciones unitarias.

• Semana 5: Sistemas de N-qubits. Compuertas universales. Computación reversible.

• Semana 6: Repaso y 1er parcial.

• Semana 7: Algoritmo para muestreo de Fourier y Algoritmo de Simon.

• Semana 8: Algoritmo de Shor y Algoritmo de Grover.

• Semana 9: Clases de complejidad. BQP. Tesis de Church-Turing extendida.

• Semana 10: Exposiciones

• Semana 11: Exposiciones

• Semana 12: Repaso y 2do parcial

(Nota: Las exposiciones serán sobre investigación actual en programación cuántica. Por ejemplo, en nuevos algoritmos que resuelven eficientemente otros problemas o lenguajes de programación cuánticos de alto nivel, etc.) 

Evaluación:

• 4 Tareas - 5% cada una, para un total de 20%.

• 1er parcial - 30%.

• 2do parcial - 30%.

• Exposición - 20%.

Y esto concluye la segunda de la tanda de electivas hipotéticas. Me encantaría poder investigar en esta área, ya que es algo diferente y sumamente interesante. Ya he leído algunos artículos y tesis doctorales en mi tiempo libre (que no es mucho, jajaja), pero me encantaría seguir trabajándolo. :)

Electiva Hipotética: Introducción a la Programación Competitiva

Actualmente mucho departamentos de la USB han sufrido una fuga importante de personal docente, lo que ha supuesto una reducción significativa en la cantidad de cursos electivos que se ofrecen. ¿Por que? Las cargas docentes de los profesores restantes se cubren en materias obligatoria y básicas. Aún así, es cada vez más difícil cubrir todas las necesidades docentes en estas materias. Esto supone un buen grado de frustración a los profesores, ya que no les es posible dictar cursos en sus diferentes áreas de especialización y tener acceso a estudiantes interesados en dichas áreas para futura investigación y proyectos de grado.

En mi caso, tengo la fortuna de que mi principal área de especialización (lenguajes de programación) tiene tres materias obligatorias en el pensum de Ingeniería de la Computación en la USB:

• Lenguajes de Programación I.
• Laboratorio de Lenguajes de Programación.
• Traductores e Interpretadores.

Por lo tanto, suelo estar asignado al menos a una de ellas por trimestre. ¡Son asignaturas que me encantan! Pero como todo, puede volverse monótono. En el caso de traductores, la he dado ya 2 veces como preparador, 3 veces como ayudante docente y 3 veces como profesor (con miras a una más, el trimestre que viene). Sería interesante poder trabajar algunas de las otras áreas que me interesan e incluso comenzar a investigar nuevas áreas. Con esto en mente, comenzaré una serie de artículos en este blog con "electivas hipotéticas". Esto es, con materias electivas que podrían comenzar a abrirse algún día cuando la USB vuelva a su antigua grandeza y haya mayor libertad para ser creativo.

Mundial ACM-ICPC 2010 en Harbin, China.

(Aquí participó un equipo de la USB)

De estas electivas hipotéticas plantearé un contenido y un plan de evaluación tentativos, de los cuales me encantaría tener feedback. ¿Quién sabe? Quizá se pueda abrir alguna de estas en un futuro no tan lejano (soñar no cuesta nada, jajaja). A continuación entonces, la primera de la serie de electivas hipotéticas.

Asignatura: Introducción a la Programación Competitiva
Créditos: 4 

Objetivo principal: Familiarizar al estudiante con las destrezas técnicas necesarias para participar en competencias de programación al estilo ACM-ICPC. 

Contenido:

• Semana 1: Introducción a las competencias de programación, sus herramientas y reglas. Medición general del nivel de los estudiantes previo al curso. Dinámica individual y grupal.

• Semana 2: Problemas ad-hoc: Saber interpretar bien un enunciado, la especificación de entradas y salidas, restricciones de las mismas y tiempos límite.

• Semana 3: Algoritmos voraces (greedy): ¿Como reconocerlos? Los peligros de confiar en una solución voraz. Criba de Eratóstenes. Búsqueda binaria. Potenciación logarítmica y Fibonacci.

• Semana 4: Programación dinámica (básica): Los peligros de la fuerza bruta. Principio de optimalidad de Bellman. Top-Down vs. Bottom-Up.

• Semana 5: Programación dinámica (avanzada): Inicialización virtual. Máscaras de bits.

• Semana 6: 1ra competencia y discusión.

• Semana 7: Grafos (básico): Búsqueda en grafos. Flood fill. Árboles cobertores. Componentes conexas.

• Semana 8: Grafos (avanzado): Máximo flujo, mínimo corte y apareamiento bipartito.

• Semana 9: Cadenas de caracteres: Suffix trees. Tries. KMP. Expresiones regulares.

• Semana 10: Consultas en árboles. Segment trees. BIT. RMQ. LCA.

• Semana 11: Algoritmos aproximados y heurísticas. Primalidad. Coloración de Grafos. Geometría y probabilidades.

• Semana 12: 2da competencia y discusión.  

Evaluación:

• 10 Tareas - 5% cada una, para un total de 50%.

• 1ra Competencia - 20%.

• 2da Competencia - 30%.

(Nota: Las competencias no se evaluarán por posición alcanzada, sino por la aplicación de los conocimientos adquiridos a los problemas presentados y dinámica de equipo. Sin embargo, habrán puntos adicionales para los ganadores de cada una.)

Y esto concluye la descripción de la primera electiva hipotética. Estoy seguro que me faltaron cosas por incluir, así que cualquier comentario es bienvenido. Hasta una próxima entrada. :D

¡Se acabó el trimestre/semestre!

Finalmente, ha llegado el final de la semana 13 (o 21, si se cuenta desde el principio en Febrero). Ha sido un trimestre difícil en la USB, envuelto en una situación nada fácil para Venezuela, desde muchos puntos de vista. Sin embargo, poco a poco y con el mayor esfuerzo logramos dar buen final a este período académico.

Bueno, ni tanto... Pero más o menos. XD

Este trimestre estuve en dos cursos. En primer lugar, tuve a mi cargo un total de 61 estudiantes en la teoría de Lenguajes de Programación I. ¡Muy buen grupo! Dispuestos a aprender y trabajar. El primer parcial vio muy buenos resultados y el segundo fue un éxito sin precedentes (aún me siento orgulloso por el excelente desempeño de todos). El tercer parcial tuvo resultados no tan alentadores, lo cual debo admitir que supuso una gran frustración para mi. Después de todo, si todo un grupo sale mal es culpa del profesor, no del grupo. Pero varias personas me han convencido de que la situación de cansancio, de que estamos en pleno mundial de fútbol y de la falta de práctica de los temas que correspondían al laboratorio (que algunos tienen incluso años sin ver) fueron los principales motivos del empeoramiento de los resultados. Finalmente, casi un 80% del salón aprobó la materia y sin una pizca de regalo. ¡Todos se lo merecen y me siento sumamente orgulloso por eso!

Notas definitivas: Notas.pdf

El segundo curso en el que estuve fue en un Miniproyecto de Desarrollo de Software, en el que junto a Leonid Tineo, Rosseline Rodriguez, Soraya Carrasquel y David Coronado, servimos de guías y evaluadores a un grupo de tres estudiantes que desarrollaron una extensión de PostgreSQL para tratar con datos difusos de tipo 3 (así como consultas con ORDER BY y GROUP BY sobre los mismos). ¡Excelente trabajo y merecido 5 para todos!

En fin, fue un trimestre laaaargo y difícil, pero con excelentes resultados. Esto únicamente desde el punto de vista docente, que se agrega a otros eventos académicos importantes. Como... no sé... que me gradúo... por ejemplo. XD Eso y muchas otras cosas más.

Al finalizar el curso de lenguajes, decidí hacer una encuesta para ver como mejorar la experiencia del curso para futuras ocasiones. A continuación lo que mandé en el correo:

Hola a todos, 

   Ya se encuentran disponibles en la página las notas definitivas, con revisión y rezagados incluídos. Las notas que aparecen ahí ya fueron pasadas a DACE y... ¡con esto concluye oficialmente el curso de Lenguajes de Programación I! 

   Ante todo quiero agradecerles a todos por el empeño que pusieron en aprender y asimilar esta materia. No es una materia fácil y eso creo que ya nos consta bastante a todos, jejeje. Además el trimestre/semestre tampoco fue el más cómodo para cursarla, pero finalmente pudimos darle buen final. ¡Todo gracias a ustedes! Incluso para algunos de ustedes que no lograron aprobar, el empeño que pusieron y el conocimiento que adquirieron les servirá muchísimo para una próxima vez (incluso yo mismo reprobé lenguajes la primera vez que la vi. XD). Sigan todos así, con la iniciativa, curiosidad y empeño que mostraron este trimestre y les espera nada menos que la grandeza en sus futuras vidas profesionales. :) 

   También quería disculparme por todas las cosas malas que pudiera haber tenido el curso, asegurándoles que yo también aprendí mucho este trimestre y me gustaría seguir aprendiendo. Por esto, me gustaría pedirles en la medida de lo posible que me respondan a este correo las siguientes preguntas: 

   1) ¿Cuál fue tu impresión general de la materia?

   2) ¿Qué fue lo que se te hizo más dificil?

   3) ¿Qué cosas te ayudaron a aprender/avanzar con el material?

   4) ¿Qué cosas sientes que falten y que podrían haber ayudado a entender mejor la materia?

   5) ¿Qué recomendaciones tienes para una próxima vez que se abra la materia? 

   Es algo como una encuesta de opinión (pero más útil, jajaja). La idea es tomar sus recomendaciones y adaptar el curso como sea necesario para asegurar que los futuros estudiantes aprovechen la materia y puedan aprender más e incluso salir mejor. :) 

   Por ùltimo, me toca hacer publicidad. Muchos de los que están viendo la materia ya vieron Traductores. Para los que no, en traductores se muestra un lado más técnico de los lenguajes, concentrándose más que todo en la implementación de los mismos. La teoría de la materia presenta los conceptos y algoritmos abstractos que fundamentan todo esto, finalizando con el estudio formal de la computación misma. En este curso, el laboratorio trata de implementar un lenguaje de programación relativamente sencillo (usualmente un interprete). Seguido de Traductores y Lenguajes, lo que continúa es la Cadena de Lenguajes de Programación. En esta cadena unimos las interpretaciones de Lenguajes de Programación I y Traductores. ¡Les toca diseñar su propio lenguaje! Para implementarlo hace falta traductores, pero para diseñarlo bien hace falta lenguajes. Es una cadena sumamente interesante y donde se aprenden muchas técnicas que son útiles incluso más allá de la implementación de lenguajes. Si les gustó este curso y más aún, si les gustó/gustará traductores, les recomiendo muchísimo esa cadena. Mitos urbanos: ¿Es muy dificil? Realmente no tanto, hay cadenas más dificiles. ¿Lleva mucho trabajo? OHHHHH SI!!! XD Es el proyecto más grande y complejo que harán en la uni y posiblemente afuera de ella también, pero vale muchísimo la pena. :) 

   Con esto me despido, totalmente agradecido por compartir con ustedes esta experiencia y quedando totalmente a la orden (ya sea que quieran sólamente pasar a discutir algun tema interesante o incluso si buscan talleres de desarrollo o tesis en lenguajes de programación). *come to the dark side, we have cookies* :D 

Saludos a todos y felices vacaciones,

Ricardo

Recibí algunas respuestas sobre la encuesta (algunas hasta graciosas) que confluían en que lo que más ayudó fue las guías que se hicieron y las consultas. Las recomendaciones se centraron en hacer más guías para algunos de los otros temas que son difíciles de entender (como tipos de pasaje de parámetros, mezclado con orientación a objetos) e intentar de alguna forma compensar la falta de práctica de quienes vieron el lab hace tiempo (si bien sea insistiendo en que vuelvan a entrar o al menos practiquen con tiempo). ¡Gracias a todos los que me ayudaron son sus comentarios! Tomaré en cuenta sus consejos e intentaré hacerlo aún mejor una próxima ocasión que pueda dar la materia.

Y esto era lo que quería compartir por ahora. ¡Será hasta una próxima entrada! :D