Hazlo todo. Hazlo bien. Hazlo puro. Hazlo mucho.

Leí hace poco un consejo para programar bien. Decía: haz que funcione, haz que sea correcto y haz que sea rápido. Como no todo lo que hago es programar, he pensado que se podía generalizar el consejo a otras áreas; generalizando las instrucciones. El resultado ha sido el siguiente:

1. Hazlo todo. Si es un programa de ordenador, haz que funcione todo. Si es una canción, componla entera. Si es una historia, escríbela por completo (tercera regla de Gaiman). Si es un dibujo, acábalo.
2. Hazlo bien. Busca los errores en el programa de ordenador y arréglalos. Busca los puntos de poca fuerza en la composición y enfatízalos. Busca los fallos de estructura en la historia y ajústalos. Busca las desproporciones en el dibujo y corrígelas.
3. Hazlo puro. Simplifica y optimiza el programa. Haz nítida la composición. Quita escenas y diálogos inútiles en tu historia (por ejemplo, la navaja de Chekhov). Deja sólo las líneas necesarias en tu dibujo.

El proceso es el mismo. Siempre. Puede ser iterativo y que tengamos que volver del punto 3 al 1, pero al final entramos por el 1 y salimos por el 3. (Empezar por el 3 es desastroso como ya advertía Knuth.)

Finalmente, debo añadir un metaconsejo que es superior a todos los anteriores.

• Hazlo mucho. Si eres programador, programa mucho. Si eres compositor, compón mucho. Si eres escritor, escribe mucho. Si eres dibujante, dibuja mucho.

El resultado de tu capacidad es resultado de la práctica que tengas. No hay otra opción que practicar una vez conocida la teoría. No vale saberse la teoría únicamente. Incluso la teoría matemática más pura no se comprende completamente sólo leyéndola. Hay que hacer ejercicios una y otra vez. Debes fracasar muchas veces antes de conseguir algún resultado.

¿Especificación de requisitos o especificación de requerimientos?

Otro caso en el que usar Google no nos ayuda a discernir cuál está bien o cual está mal. Si usamos "requerimientos" obtenemos más o menos las mismas páginas que si usamos "requisitos".

Por otra parte, el diccionario lo dice claramente: "requisito" es la circunstancia que se debe dar mientras que "requerimiento" es la acción de requerir algo (es sinónimo de "petición", "demanda", etc.)

Resumiendo:

• "Especificación de requisitos" es la especificación de las circunstancias que se deben dar (para que el programa sea correcto).
• "Especificación de requerimientos" sería la especificación de las peticiones o demandas. Obviamente, esta es la que se usa mal.

¿Intersectar o intersecar?

Hoy vuelvo a la carga con una sorpresa léxica que he descubierto. Está claro qué es una intersección, sin embargo ¿cuál es el verbo para hacer una intersección? Lo que se suele oír es intersectar. Sin embargo, esta palabra no existe.

La palabra correcta es intersecar. Que sí aparece en el diccionario.

Rebuscando en la etimología, la diferencia se remonta al latín donde aún hay "t" en una versión (intersectĭo) y falta en la otra (ntersecāre). Sea como fuere, debido a mi ignorancia del tema, he de quedarme con la duda.

Curiosamente, buscando en Google, intersectar tiene unas 32000 apariciones mientras que la correcta intersecar sólo 19000.

El alto modo mimético

Traduzco el primer párrafo de aquí para iniciar un nuevo tag en el blog: narrativa, que se unirá al de lenguaje natural.

Roger Zelazny, hablando de por qué le gustaba escribir ciencia ficción, alludía a la teoría de modos de Northrop Frye. Zelazny interpretaba que Frye describía los personajes de ficción de cuatro modos:

• El modo mítico de historias sobre dioses.
• El alto modo mimético de historias sobre héroes (personas mejores que meros humanos)
• El bajo modo mimético de histrorias sobre personas normales.
• El modo irónico de historias sobre personas peores que las normales (criminales, bufones)

[...] Zelazny decía que le gustaba la ciencia ficción porque le permitía escribir en modo mítico o alto mimético.

Estas reflexiones me han llevado a rememorar los distintos tipos de historias en función a su trama que leí hace tiempo aquí:

• Arquitrama: El protagonista se enfrenta a dificultades y obtiene una recompensa al vencerlas. Nota bene: Todo lo que quieras saber de la arquitrama está en El camino del escritor y en El camino del héroe.
• Antitrama: O no hay protagonista, o no hay dificultades, o no hay trama. Más información aquí.
• Minitrama: Muchas pequeñas historias encadenadas.

Y a modo de mecanismo de serialización, dejo aquí una entrada de blog para su persistencia.

El "yo" tópico

Hasta que no estudias algunos idiomas orientales no te das cuenta de que existen otras maneras de hablar. Muchos de estos idiomas no están orientados a sujeto, están orientados a tópico. ¿Y qué es eso del tópico?

Cuando nosotros decimos "el niño corre" dejamos claro quién está haciendo algo (el niño) y qué es lo que está haciendo (corre). El castellano es un idioma orientado a sujeto. En un idioma orientado a tópico diríamos de qué vamos a hablar: del niño; y añadiríamos una acción: correr. La frase sería algo como...

"Hablando del niño, corre"

Obviamente estos idiomas tienen una forma abreviada de decir "hablando de..." por lo que la frase final suele ser más corta que en los idiomas con sujeto.

Lo más sorprendente es que en castellano se usa algunas veces el tópico. No está marcado gramaticalmente, ni es habla culta, pero se usa. Ocurre cuando nos preguntan nuestra opinión y empezamos diciendo "Yo..." Luego, cambiamos y decimos la opinión.

"¿Y tú que opinas de la gatita?"

"Yo... La gatita es buena"

Podríamos decir que ese uso del "Yo" es como tópico ya que vamos a hablar de nosotros (nuestra opinión) aunque el resto de la frase no esté relacionada gramaticalmente con ese "yo".

Argumentos y parámetros

Generalmente se usan las palabras "argumento" y "parámetro" de forma intercambiable cuando definimos o llamamos a una función. Para distinguir si es en definición o en llamada usamos los adjetivos "formal" o "actual" (mal traducido del inglés "actual"). Entonces:

int f(int a, int b) //Parámetros o argumentos formales

f(3, 4) //Parámetros o argumentos actuales

Bien. En C++ tienen una notación distinta. Para ellos los "parámetros" son los de la definición y los "argumentos" son los de la llamada. La verdad es que es una tontería usar dos palabras cuando se puede usar una, pero ya es un poco enfermizo llegar a tal grado de eficiencia para un programador.

Des contra de

Está extendido el uso de la palabra "decodificar" proveniente del inglés "decode". En español debería ser "descodificar" y la diferencia entre estas palabras proviene del prefijo que usan los idiomas para indicar "el verbo que hace lo contrario".

En inglés este prefijo es "de" y se usa en palabras como "deactivate" (desactivar), "decaffeinated" (descafeinado) o "demagnetize" (desmagnetizar). Obviamente, en español las palabras equivalentes empiezan por "des".

Sin embargo, la palabra "decodificar" ha tomado más arraigo de la cuenta. Probablemente, por malos traductores y la confusión con el prefijo "de" que aparece en algunas palabras españolas como "delimitar" (poner límites) o "defenestrar" (tirar por la ventana).

Existe también otra palabra de este tipo que se lee de vez en cuando en los libros de informática que es "dereferenciar" en vez de "desreferenciar". En inglés es "dereference". Esta palabra se usa cuando se obtiene el valor al que apunta una referencia. El clásico  *p  de C/C++.

La sorpresa es que "decodificar" está aceptado por el diccionario de la RAE con un tímido "1. tr. descodificar." Me pregunto: ¿Dónde quedó aquello de "limpia, pule y da esplendor"?

EL interfaz vs LA interfaz

Tengo la costumbre de decir EL interfaz. Sin embargo, la palabra "faz" está claro que es femenina. Así que debería decirse LA interfaz. Por alguna extraña razón, sigo notando que no encaja "la" con "interfaz".