Components Programming

C++26 está listo: notas desde la reunión de WG21 en Croydon

2026-04-05T12:00:00.000Z

Crédito de la foto: Herb Sutter

El comité ISO C++ cerró C++26 el 28 de marzo en Croydon, UK. Participaron alrededor de 210 personas (130 presenciales, 80 remotas) representando a 24 naciones, resolviendo los últimos 411 comentarios de los organismos nacionales. De acá en adelante el documento va a su votación de aprobación final. No más features, no más adiciones. C++26 está listo.

Esta fue mi primera reunión presencial de WG21. Soy miembro del comité desde 2022 y antes participé de forma remota, pero vengo siguiendo la evolución del lenguaje desde la era C++0x, cuando “0x” se estaba convirtiendo en un chiste y nadie estaba seguro de que llegaría a publicarse. Estar ahí para el cierre de C++26 se sintió como el momento justo para finalmente aparecer en persona.

Contracts: aprobados, debatidos, divisivos

Contracts entró en C++26. La votación final fue 114 a favor, 12 en contra, 3 abstenciones. Ese nivel de oposición es inusual para una feature en esta etapa, y el debate en la sala fue palpable.

Mi perspectiva sobre contracts viene de Eiffel y su filosofía de Design by Contract. En ese modelo, los contratos son parte de la semántica del programa. Una violación de precondición significa que el llamador tiene un bug. Una violación de postcondición significa que el implementador tiene un bug. La responsabilidad es inequívoca, y las violaciones son siempre bugs, nunca situaciones de runtime que deban manejarse con flexibilidad.

C++ tomó un camino más configurable. Eso no es necesariamente malo; C++ siempre fue un lenguaje de opciones. Pero la flexibilidad adicional tiene un costo visible en simplicidad conceptual. La distancia entre lo que C++ llama “contracts” y la filosofía original de Design by Contract es mayor de lo que esperaba.

Reflection: lo grande de verdad

Si contracts fue la feature más debatida, reflection fue la más transformadora.

Reflection en C++26 permite introspección en tiempo de compilación de tipos, miembros y estructura del programa, cosas que antes requerían herramientas externas o metaprogramación pesada con templates. GCC ya tiene una implementación mergeada en trunk.

Esto cambia lo que es posible dentro del lenguaje. No incrementalmente, sino categóricamente. La forma en que escribimos bibliotecas, generamos código y expresamos abstracciones va a ser diferente. Creo que vamos a estar descubriendo nuevos patrones alrededor de reflection por mucho tiempo.

La sesión vespertina que cambió mi rumbo

Una sesión vespertina trató sobre un problema estructural que viene creciendo hace años: hay muchas más propuestas (papers) que capacidad de implementación. Los equipos de compiladores en Clang, GCC y MSVC están al límite. El cuello de botella ya no es el diseño. Es la implementación. Las features se aprueban en papel y después tardan años en ser usables.

Surgieron varias ideas: que los autores de papers traigan al menos implementaciones parciales, que las propuestas se prueben contra la realidad antes de avanzar, e incluso que herramientas asistidas por IA podrían ayudar a bajar la barrera. Esto último generó una reacción visible en la sala: murmullos, gente hablando fuera de turno, frustración. Fue un momento breve, pero revelador.

Lo que me quedó fue el mensaje central de los implementadores. Al día siguiente, empecé a contribuir tanto a Clang como a GCC, a nivel de biblioteca y de compilador. No por un gran plan, sino porque el mensaje caló: si te importa que el lenguaje avance, ayudá a construirlo.

Estar ahí

Hay algo en estar en la sala que la participación remota no puede replicar. Las conversaciones de pasillo, el lenguaje corporal durante los debates, la energía cuando cae una votación reñida.

C++ sigue volviéndose más poderoso, y el costo de mantenerse al día es real. Pero la comunidad detrás del lenguaje está profundamente comprometida con hacerlo bien, y eso fue evidente en Croydon.

Me alegra haber estado ahí para esta.

¡Gracias nuevamente, Alex!

2020-02-20T12:00:00.000Z

Una vez más, me gustaría agradecerle a mis amigos Alex Stepanov y Paul McJones por este hermoso regalo.

He estado buscando este libro por años. Es un libro muy difícil de conseguir.

No tengo palabras para agradecerles.

Simplemente, ¡gracias!

Algoritmos y especificaciones

2020-02-19T12:00:00.000Z

En este artículo quiero hablar sobre 2 temas en los que creo que la mayoría de los programadores solemos fallar: Algoritmos y Especificaciones.

Me voy a ayudar de una experiencia real, ocurrida ya hace un tiempo:

Desde hace ya 4 años mantengo un nodo multimoneda (Bitcoin, Bitcoin Cash y Litecoin) llamado Knuth (a.k.a. Bitprim). En noviembre de 2017 Bitcoin Cash hizo su primer cambio de protocolo luego de su nacimiento en agosto del mismo año. Mi trabajo en ese momento era actualizar el código de nuestro nodo para que soporte los cambios de protocolo. Desde aquel momento que quiero escribir este artículo, pero… por alguna o varias razones no lo hice en ese momento, lo estoy haciendo ahora.

El cambio más importante de fue en el Algoritmo de Ajuste de Dificultad, en adelante DAA (del inglés Difficulty Adjustment Algorithm).

Aquí la descripción del algoritmo.

No quiero entrar en detalles acerca del concepto de dificultad ni del DAA. Para ello puede referirse a: Difficulty.

Lo que me interesa son los puntos 2 y 3 de la descripción del DAA:


2. Let B_last be chosen[2] from [B_n-2, B_n-1, B_n].
3. Let B_first be chosen[2] from [B_n-146, B_n-145, B_n-144].

Ambos apuntan a la nota al pie [2]:


2. A block is chosen via the following mechanism:

Given a list: S = [B_n-2, B_n-1, B_n]
a. If timestamp(S[0]) greater than timestamp(S[2]) then swap S[0] and S[2].
b. If timestamp(S[0]) greater than timestamp(S[1]) then swap S[0] and S[1].
c. If timestamp(S[1]) greater than timestamp(S[2]) then swap S[1] and S[2].
d. Return S[1].

See GetSuitableBlock

La especificación del algoritmo apunta a su implementación, en una función llamada GetSuitableBlock. Aquí su código:


/**
 * To reduce the impact of timestamp manipulation, we select the block we are
 * basing our computation on via a median of 3.
 */
static const CBlockIndex *GetSuitableBlock(const CBlockIndex *pindex) {
    assert(pindex->nHeight >= 3);

    /**
    * In order to avoid a block is a very skewed timestamp to have too much
    * influence, we select the median of the 3 top most blocks as a starting
    * point.
    */
    const CBlockIndex *blocks[3];
    blocks[2] = pindex;
    blocks[1] = pindex->pprev;
    blocks[0] = blocks[1]->pprev;

    // Sorting network.
    if (blocks[0]->nTime > blocks[2]->nTime) {
        std::swap(blocks[0], blocks[2]);
    }

    if (blocks[0]->nTime > blocks[1]->nTime) {
        std::swap(blocks[0], blocks[1]);
    }

    if (blocks[1]->nTime > blocks[2]->nTime) {
        std::swap(blocks[1], blocks[2]);
    }

     // We should have our candidate in the middle now.
    return blocks[1];
}

Lo que hace el algoritmo es básicamente crear una secuencia de 3 elementos (array), la ordena de menor a mayor y retorna el segundo elemento.

La complejidad en tiempo de este algoritmo es:

Caso mejor: 0 swaps, 3 comparaciones
Caso peor: 2 swaps, 3 comparaciones
Caso promedio: 7/6 swaps, 3 comparaciones; asumiendo una distribución uniforme de los datos de entrada.

Ahora, vuelva a observar con detenimiento el algoritmo. Se está creando un array (usando los datos de entrada), para luego ordenarlo ascendentemente y retornar el elemento del medio. Este es un algoritmo conocido y se llama mediana, en particular, mediana de 3 elementos.

La mediana es un algoritmo de selección. A diferencia de los algoritmos de ordenamiento (inplace), los algoritmos de selección no deberían mutar los datos de entrada, sino, retornar uno de ellos.

Aquí les dejo un boceto del algoritmo mediana de 3, en C++:


template <TotallyOrdered T>
auto max(T const& a, U const& b) {
    return b < a ? a : b;
}

template <TotallyOrdered T>
auto median_3_ab(T const& a, T const& b, T const& c) {
    // precondition: a <= b

    return ! (c < b) ? b :        // a, b, c are sorted
                       max(a, c); // b is not the median
}

template <TotallyOrdered T>
auto median_3(T const& a, T const& b, T const& c) {
    return b < a ? median_3_ab(b, a, c)
                 : median_3_ab(a, b, c);
}

O si prefiere la versión inline del algoritmo:


template <TotallyOrdered T>
auto median_3(T const& a, T const& b, T const& c) {
    if (b < a) {
        if (c >= a) return a;  // b, a, c are sorted
        return max(b, c);      // a is not the median
    } else {    // a <= b
        if (c >= b) return b;  // a, b, c are sorted
        return max(a, c);      // b is not the median
    }
}

Dejo el análisis del código para el lector, para el vago: lo que hace el algoritmo es simplemente seleccionar el elemento del medio entre a, b y c, haciendo de cuenta que los 3 estuviesen ordenados ascendentemente. Esto lo hace sin mutar ni reordenar los datos de entrada.

La complejidad en tiempo de median_3 es:

Caso mejor: 0 swaps, 2 comparaciones
Caso peor: 0 swaps, 3 comparaciones
Caso promedio: 0 swaps, 8/3 comparaciones; asumiendo una distribución uniforme de los datos de entrada.

Ahora, podríamos usar nuestro nuevo algoritmo en la función GetSuitableBlock original:


static
CBlockIndex const* GetSuitableBlockNewVersion(CBlockIndex const* pindex) {
    assert(pindex->nHeight >= 3);
    return &median_3(*pindex->pprev->pprev, *pindex->pprev, *pindex);
}

Mucho más breve y entendible, ¿no?.

Antes de seguir, tenemos que corregir un problema: no sabemos si el Ordenamiento Natural especificado en la clase CBlockIndex está dado por el timestamp del bloque (atributo nTime). Necesitamos una versión de median_3 que acepte una forma de comparar especificado por el usuario: necesitamos que acepte una relación de preorden total estricta (strict weak ordering relation, para más información consulte aquí).


template <Regular T, StrictWeakOrdering R>
auto max(T const& a, U const& b, R r) {
    return r(b, a) ? a : b;
}

template <Regular T, StrictWeakOrdering R>
auto median_3_ab(T const& a, T const& b, T const& c, R r) {
    // precondition: a <= b

    return ! r(c, b) ? b :           // a, b, c are sorted
                       max(a, c, r); // b is not the median
}

template <Regular T, StrictWeakOrdering R>
auto median_3(T const& a, T const& b, T const& c, R r) {
    return r(b, a) ? median_3_ab(b, a, c, r)
                   : median_3_ab(a, b, c, r);
}

Ahora sí, podemos implementar correctamente GetSuitableBlockNewVersion, comparando por nTime:


static
CBlockIndex const* GetSuitableBlockNewVersion(CBlockIndex const* pindex) {
    assert(pindex->nHeight >= 3);
    return &median_3(*pindex->pprev->pprev, *pindex->pprev, *pindex, [](auto const& a, auto const& b){
        return a.nTime < b.nTime;
    });
}

Nos queda un último problema por resolver. Hagamos una pequeña prueba del algoritmo original y del nuevo:


struct CBlockIndex {
    size_t nHeight;
    size_t nTime;
    CBlockIndex* pprev;
};

int main() {
    CBlockIndex ba {1, 1558731500, nullptr};
    CBlockIndex bb {2, 1558731500, &ba};        //same nTime as previous
    CBlockIndex bc {3, 1558730000, &bb};

    auto r = GetSuitableBlockNewVersion(&bc);
    cout << "GetSuitableBlockNewVersion: " << r->nHeight << endl;

    r = GetSuitableBlock(&bc);
    cout << "GetSuitableBlock:           " << r->nHeight << endl;
}

El código anterior imprime:


GetSuitableBlockNewVersion: 1
GetSuitableBlock:           2

Lo que estamos intentando probar con el código anterior es la estabilidad de ambos algoritmos. Nuestro algoritmo median_3 es estable lo que quiere decir que el orden de los elementos equivalentes se preserva (para más información consulte aquí).

Para demostrarlo con datos, vamos a utilizar el ejemplo anterior, en el cual tenemos los siguientes datos de entrada para nuestros algoritmos:


s = [{1, 1558731500}, {2, 1558731500}, {3, 1558730000}]

Donde el primer elemento de cada par es el identificador del bloque nHeight y el segundo elemento es el timestamp nTime. Note que el nTime de los primeros 2 elementos es igual.

Si ordenamos la secuencia anterior por nTime usando un algoritmo de ordenamiento estable, como por ejemplo Merge sort nos quedaría algo así:


s = [{3, 1558730000}, {1, 1558731500}, {2, 1558731500}]

Note que el elemento del medio es el que tiene nHeight = 1. Lo cual indica que nuestro algoritmo se comportó de manera estable pero no así el algoritmo original usado en el DAA de Bitcoin Cash.

En mi primera implementación de DAA en el nodo Bitprim usé un código similar a median_3 el cual también era estable, dado que no había verificado el código de la especificación, yo había asumido erróneamente que también era estable. Luego esto provocó errores en tiempo de ejecución de nuestro nodo ante un ajuste de dificultad. No se daba siempre, pero hubo un caso en particular en el que lo pudimos detectar. Luego de varias horas de debugging pude detectar que el problema era que el algoritmo usado por mí no era compatible con el “especificado” en DAA.

Por lo tanto, tuve que “corregir” mi algoritmo para hacerlo no-estable de la misma forma que el de la especificación.

En realidad, si mal no recuerdo, en la primera versión de la especificación de DAA no se mencionaba al código de GetSuitableBlock, sino que decía que se calculaba la mediana de 3 elementos. Como la implementación de la mediana fue “incorrecta” tuvieron que adaptar la especificación para que se condiga con el código. Tenga en cuenta, que una vez que el código de un nodo Bitcoin o de cualquier criptomoneda está en funcionamiento, una modificación en su comportamiento introduce incompatibilidades con versiones anteriores y produce los denominados forks. Por lo que una vez que el código está corriendo, se trata de no cambiarlo. Por esta razón es por la que se tuvo que adaptar la especificación en vez de corregir el código.

Antes de terminar, hagamos una comparación de ambos algoritmos, GetSuitableBlock vs. median_3:

median_3 no efectúa ningún swap, GetSuitableBlock puede efectuar entre 0, 7/6 o 2 swaps, innecesariamente. (Eficiencia)
GetSuitableBlock crea un array innecesariamente. (Eficiencia)
median_3 realiza 2, 8/3 o 3 comparaciones, GetSuitableBlock realiza siempre 3 comparaciones. (Eficiencia)
median_3 es estable, GetSuitableBlock no lo es. median_3 es lo que cualquiera espera de un algoritmo que calcule la mediana de 3 elementos. (Correctitud)

Y ahora sí, para finalizar, algunas conclusiones:

El autor de la especificación de DAA podría haber optado por usar un algoritmo conocido y “estándar”, pero no lo hizo. Es más, quizás lo peor de todo esto es que la especificación hace referencia al código. El código no debe ser nunca especificación. El código debe ser creado a partir de una especificación. Por lo que si una especificación hace referencia a código, no existe dicha especificación.

¡Saludos!

Edición de Autores de Elements of Programming (free ebook)

2019-06-28T12:00:00.000Z

¡Último momento! ;P

Este año Elements of Programming cumple 10 años desde su publicación, pero esta vez el regalo es para nosotros:

Alex Stepanov y Paul McJones acaban de publicar la Edición de Autores de Elements of Programming y viene en dos versiones:

PDF gratuito, hacé click acá para descargarlo.
Libro de bolsillo de la editorial Semigroup Press, por sólo USD 9,94; hacé clic acá para comprarlo.

Próximamente disponible en Amazon.

¡Gracias de nuevo!, Alex y Paul.

Mi charla: 'El regalo de los árabes'

2018-11-26T12:00:00.000Z

¡Hola!

Les comparto los enlaces al video y filminas de mi charla titulada El regalo de los árabes, la cual que fue presentada en el meetup Algorithms Study Group en mayo de 2017 en la ciudad de Buenos Aires.

El contenido de mi charla está basado en Three Algorithmic Journeys y From Mathematics to Generic Programming de Alex Stepanov.

Es mi interpretación de lo que hubiera sido su cuarto episodio, que nunca fue presentado, y hubiera tenido el mismo nombre.

¡Espero que les guste!

Enlace a Video

Enlace a Filmina

¡Saludos!

Mención de Honor 'Senador Domingo Faustino Sarmiento'

2016-11-30T12:00:00.000Z

El día 29 de noviembre de 2016 tuve el honor y agrado de recibir, como miembro del equipo científico de la Comisión Nacional del Límite Exterior de la Plataforma Continental (COPLA), la Mención de Honor “Senador Domingo Faustino Sarmiento”, por nuestra labor, que posibilitó la determinación del nuevo Límite Exterior de la Plataforma Continental de la República Argentina. [1]

La distinción fue entregada por la vice presidente de la Nación, la Lic. Gabriela Michetti, junto al senador Omar Perotti.

La Mención de Honor “Senador Domingo Faustino Sarmiento” constituye el máximo galardón que entrega el Honorable Senado de la Nación a personas físicas o jurídicas del quehacer cultural, deportivo, profesional y académico, por su obra emprendedora destinada a mejorar la calidad de vida de sus semejantes, de las instituciones y de sus comunidades. El acto de entrega de la distinción fue realizado en el Salón Azul del Honorable Senado de la Nación.

Del evento también partiparon el vice canciller y presidente de COPLA, Carlos Foradori, el ex canciller Jorge Taiana, el ex vice canciller Fernando Petrella, los senadores Mario Pais, Dalmacio Mera, Norma Durango, Beatriz Mirkin, y la diputada Daniela Castro. Además participaron destacadas figuras del ámbito académico y científico.

La canciller Susana Malcorra no pudo estar presente ya que ha viajado a Cuba para los funerales de Fidel Castro en representación de la Argentina.

Referencias

[1] El Límite fue aprobado el 11 marzo de 2016 por las Naciones Unidas, por consenso, es decir sin un solo voto en contra. Ver: Límite Exterior de la Plataforma Continental.

Enlaces a Noticias

Mi charla: '¿Fastware?'

2016-11-16T12:00:00.000Z

¡Buenas!

Les comparto el enlace a las filminas de mi charla denominada “¿Fastware?” que fue expuesta en el “Segundo Encuentro de programadores C++ de Buenos Aires” el día 14 de Julio de 2016.

En ese encuentro también tuvimos el agrado de presenciar la excelentes charlas brindadas por nuestros colegas: Agustín (K-Ballo) Bergé, Francisco Tufró y Hernan Saez. Los links de las demás presentacines aquí..

Espero que les gusten nuestras presentaciones y les de ganas de sumarse a nuestra comunidad.

¡Saludos!

Palíndromos y algo más

2016-06-06T12:00:00.000Z

Decidí escribir este artículo a partir de una pregunta que vi en Stackoverflow.

Aquí el enlace a la pregunta.

El autor de la pregunta intenta escribir un algoritmo que identifique si una “palabra” es un palíndromo o no lo es. El algoritmo está escrito usando el lenguaje de programación Java.

No me interesa analizar el algoritmo propuesto por el autor, sino que me interesa analizar el algoritmo propuesto en la respuesta más votada. Este último tiene 73 votos contra 65 votos que tiene la respuesta aceptada (a día de la fecha, 6 de Junio de 2016).

Aquí el enlace a la respuesta que me interesa.

Acá el código:


public static boolean isPalindrome(String str) {
    return str.equals(
       new StringBuilder(str)
       .reverse()
       .toString()
    );
}

El algoritmo funciona correctamente y la lógica es muy intuitiva. Básicamente compara por igualdad la palabra original contra el reverso de la palabra.

El problema con este algoritmo es que es muy ineficiente comparado con el algoritmo óptimo.

Hice un comentario al autor de esta respuesta en Stackoverflow: “Compare the complexity of your algorithm with respect to others.”
El usuario @aioobe me respondió: “I think it’s the same complexity as the other solutions, no?”

En parte tiene razón. No fui muy específico en mi comentario. Seguramente @aioobe asumió que yo me refería a la complejidad computacional asintótica y está bien que lo haya asumido de esa forma, ya que usualmente cuando decimos “complejidad” sin especificar nada más, se asume que nos estamos refiriendo a la complejidad computacional asintótica.

Complejidad Computacional Asintótica

Con complejidad computacional asintótica nos referimos a cómo responden los algoritmos en tiempo/espacio a medida que el input crece.
Usualmente está asociada a la O-notation introducida por Paul Bachmann en su libro Die Analytische Zahlentheorie en 1894. [1]

De esta forma podemos medir la escalabilidad de los algoritmos sin depender de la arquitectura de la máquina, de la velocidad del procesador, del lenguaje en el que está implementado el algoritmo, etc…

Si bien es muy útil en muchas circunstancias, el problema de esta forma de medición es que no es exacta, sino que es aproximada.\

No quiero aquí extenderme en más detalles sobre O-notation ni complejidad asintótica, para información referirse a [2].

Complejidad Computacional Concreta

Otra forma de medir algoritmos es no usar aproximaciones sino cantidades concretas de operaciones, dependiendo de la entrada al algoritmo.

Por ejemplo, supongamos el algoritmo para encontrar el mínimo (o máximo) de $ n $ elementos. Podemos decir que dicho algoritmo tiene una complejidad (en tiempo) de $ O(n) $ o lineal. Pero específicamente se necesitan $ n - 1 $ comparaciones.

Volviendo a los Palíndromos

Repito el código que queremos analizar:


public static boolean isPalindrome(String str) {
    return str.equals(
       new StringBuilder(str)
       .reverse()
       .toString()
    );
}

Al código anterior lo vamos a denominar Algoritmo I (“I” de ineficiente).

Podríamos decir que Algoritmo I es $ O(n) $, pero, ¿Cómo podemos asegurarlo sin conocer la complejidad de los componentes en los que el algoritmo está basado?

Para ello, debemos revisar la documentación provista por Java. Por ejemplo, veamos la función String.equals(). [3]

Como habrán notado en la página anterior, la documentación de Java no incluye la complejidad en tiempo ni espacio de sus algoritmos y estructuras de datos.
Considero esto una gran falta ya que nos dificulta la especificación de la complejidad de nuestros algoritmos, al menos de los algoritmos que están basados en clases provistas por Java.

Para continuar tratando de especificar la complejidad del Algoritmo I, no nos queda otra que revisar directamente el código fuente de las clases Java.
Veamos el código fuente de String.equals() (presione sobre el link y busque la función equals).

Como ustedes pueden verificar, el código de String.equals() tiene complejidad lineal en tiempo, $ O(n) $.
Específicamente se realizan $ n $ comparaciones por desigualdad. (Más allá de todo el ruido impuesto por Java, como los casts, instanceof, etc…).

La complejidad en espacio de String.equals() es constante, o sea, $ O(1) $.
Esto quiere decir que se utiliza una cantidad de memoria constante más allá del input del algoritmo.

Determinando la complejidad

Vamos a determinar la complejidad del Algoritmo I, analizando uno a uno sus componentes.

String.equals(). Tiempo lineal, $ n $ comparaciones por desigualdad. Espacio constante.

StringBuilder.reverse(). Tiempo lineal, $ 2 \left\lfloor\dfrac{n}{2}\right\rfloor $ asignaciones. Espacio constante.

StringBuilder.toString(). Tiempo lineal, $ n $ asignaciones. Espacio lineal, $ n $ elementos.

StringBuilder constructor. Tiempo lineal, $ n + 16 $ asignaciones. Espacio lineal, $ n + 16 $ elementos.

Entonces, la complejidad total del Algoritmo I es:

Tiempo: En el peor caso, cuando la palabra es un palíndromo, este algoritmo realiza $ n $ comparaciones por desigualdad y $ 2n + 2 \left\lfloor\dfrac{n}{2}\right\rfloor + 16 $ asignaciones.
Espacio: $ 2n + 16 $ elementos.

Como pueden observar, este algoritmo es muy ineficiente, hace uso de memoria innecesariamente y como veremos más adelante, realiza más de $ 8x $ operaciones que el algoritmo óptimo.

Mejorando el algoritmo (versión naïve)

Llamemos al siguiente código Algoritmo N (de naïve). El Algoritmo N presenta una mejora sustancial con respecto al Algoritmo I.


public static boolean isPalindrome(String str) {
    int n = str.length();
    for (int i = 0; i < n; ++i) {
        if (str.charAt(i) != str.charAt(n-i-1)) return false;
    }
    return true;
}

Tiempo: En el peor caso, cuando la palabra es un palíndromo, este algoritmo realiza $ n $ comparaciones por desigualdad.
Espacio: constante

No se hace uso de memoria adicional y ejecuta aproximadamente $ \dfrac{1}{4} $ de las operaciones que el Algoritmo I. Si bien el código se hace un poco más complejo, es un código fácilmente entendible y el incremento en la complejidad es insignificante comparado a la mejora en eficiencia.

Algoritmo óptimo

Como podemos ver en la siguiente imagen, no hace falta hacer $ n $ comparaciones para determinar si una palabra es un palíndromo.

Con sólo hacer (aproximadamente) la mitad de las comparaciones nos basta:

Si n es par, se deben hacer $ \dfrac{n}{2} $ comparaciones
Si n es impar, se deben hacer $ \dfrac{n - 1}{2} $ comparaciones.

El siguiente código será denominado Algoritmo O (de óptimo).


public static boolean isPalindrome(String str) {
    int n = str.length();
    for (int i = 0; i < n/2; ++i) {
        if (str.charAt(i) != str.charAt(n-i-1)) return false;
    }
    return true;    
}

Tiempo: En el peor caso, cuando la palabra es un palíndromo, este algoritmo realiza $ \left\lfloor\dfrac{n}{2}\right\rfloor $ comparaciones por desigualdad.
Espacio: constante

Análisis detallado del Algoritmo I

Como vimos anteriormente, el Algoritmo I es mucho más ineficiente que los algoritmos N y O.
Pero además del análisis de complejidad que vimos antes, tenemos que tener en cuenta otras cuestiones que afectan la eficiencia del Algoritmo I.

Cada componente usado en el Algoritmo I viene con ciertas penalidades en performance que pasan desapercibidas.
Analicémoslo en detalle.

Construcción de StringBuilder

Asignación de memoria (memory allocation) dinámicamente para el objeto de tipo StringBuilder (heap, free store, o como quieran llamarlo).
Inicialización en cero (Zero-Initialization) de los miembros de StringBuilder. [4]
Asignación de memoria dinámica para el array interno dentro de StringBuilder. De acuerdo con la documentación, el tamaño del array interno es de 16 caracteres sumado al tamaño del String original. [5]
Inicialización en cero (Zero-Initialization) de los miembros del array interno de StringBuilder. Length y del Array en sí. [4]
Copia de los bytes del string original al array interno del StringBuilder.

reverse() (StringBuilder)

Sólo lo mencionado anteriormente. Esta función no utiliza memoria adicional y es eficiente en tiempo de ejecución.

toString() (StringBuilder)

Asignación de memoria (memory allocation) dinámicamente para el objeto de tipo String (heap, free store, o como quieran llamarlo).
Inicialización en cero (Zero-Initialization) de los miembros de String. [4]
Asignación de memoria dinámica para el array interno dentro de String.
Inicialización en cero (Zero-Initialization) de los miembros del array interno de String. Length y del Array en sí. [4]
Copia de los bytes del array interno de StringBuilder al array interno del nuevo String.

equals() (String)

Sólo lo mencionado anteriormente. Esta función no utiliza memoria adicional y es eficiente en tiempo de ejecución.

Garbage Collection

El GC debe liberar toda la memoria adicional (innecesaria) que fue utilizada y obviamente esta operación no es “gratuita”.

Data Cache Misses

Otro inconveniente asociado al consumo innecesario de memoria es la probabilidad de que nuestros objetos sean muy grandes para entrar en el cache, provocando cache misses impactando en el tiempo de ejecución.
Otro factor que aumenta la probabilidad de cache misses son las indirecciones (referencias, punteros) a porciones distantes en memoria.

Consumo de memoria (memory footprint)

Para analizar el consumo de memoria del Algoritmo I, vamos a hacerlo con un ejemplo concreto. Vamos usar una palabra (de habla inglesa) de 9 caracteres, a palabra en este caso es “evitative” y es un palíndromo.


isPalindrome("evitative");

Si bien consumo de memoria del Algoritmo I depende de la Virtual Machine y del Runtime Environment que estemos usando, en este caso vamos a usar una plataforma específica que está detallada aquí.

Básicamente en nuestro ejemplo se crean dos objetos, uno de tipo StringBuilder y otro de tipo String.

StringBuilder:

Los objetos de tipo StringBuilder tienen la siguiente representación en memoria.

Un objeto del tipo StringBuilder consiste de dos partes (no necesariamente contiguas en memoria):

Primera parte: tamaño de utilización del array (length() del StringBuilder) y una referencia al array donde están los datos.
Segunda parte: tamaño del array (capacity() del StringBuilder) y el array con los datos.
El tamaño del array es de 16 caracteres sumado a la cantidad de caracteres del String original (“evitative”) [5]. En la imagen se muestran esos 16 caracteres como recuadros de color rojo, debido a que es espacio desperdiciado. Los caracteres en Java tienen un tamaño de 2 bytes. [6]
O sea que en nuestro ejemplo el array va a tener un tamaño de $ 2 \cdot (9 + 16) = 50 $ bytes.

En Java todos los objetos tienen un header (si conoce alguna implementación que no los tenga, me avisa), en nuestra plataforma el header es de 12 bytes. En otras plataformas populares puede ser de 8 o 16 bytes, cualquier cosa ver aquí [7].

Otra cosa a tener en cuenta es el padding, que básicamente es cierto espacio de memoria que se adiciona para satisfacer el alineamiento de los objetos. En nuestro caso, los objetos deben estar alineados en direcciones de memoria múltiplos de 8.

En resumen, nuestro objeto StringBuilder tiene el siguiente tamaño en memoria (en bytes):

Primera parte: $ 24 $
Segunda parte: $ 16 + 2n + 32 + padding $ [8]

Total: $ 8(\left\lceil\dfrac{n}{4}\right\rceil + 9) $ bytes

String:

Los objetos de tipo String tienen la siguiente representación en memoria.

Un objeto del tipo String consiste de dos partes (no necesariamente contiguas en memoria):

Primera parte: referencia al array donde están los datos y hash.
Segunda parte: tamaño del array (length() del String) y el array con los datos.\

El objeto String aquí descripto pertenece a la especificación de Java 8. En versiones anteriores de Java, la clase String contaba con más campos, por consiguiente su tamaño en memoria era mayor. [7]

En resumen, nuestro objeto String tiene el siguiente tamaño en memoria (en bytes):

Primera parte: $ 24 $
Segunda parte: $ 16 + 2n + padding $ [8]

Total: $ 8(\left\lceil\dfrac{n}{4}\right\rceil + 5) $ bytes

Total de memoria consumida:

El total de memoria consumida por nuestros objetos StringBuilder y String es de $ 16(\left\lceil\dfrac{n}{4}\right\rceil + 7) $ bytes.

En nuestro ejemplo $ n = 9 $, así que la memoria consumida es $ 16(\left\lceil\dfrac{9}{4}\right\rceil + 7) $ bytes, que son 160 bytes adicionales de memoria, solo para determinar si “evitative” es un palíndromo o no.
Recuerden que estos 160 bytes es un consumo totalmente innecesario de memoria.

Benchmarks

Estuve haciendo algunas mediciones de performance de los algoritmos y en las mismas se percibe una penalidad en tiempo de ejecución promedio de 8.5x del Algoritmo I por sobre los Algoritmos O y N. O sea, el Algoritmo I es más de 8 veces más lento que los otros dos, en promedio.

En ese promedio no estoy considerando un benchmark que arroja 586x de penalidad, ya que el algoritmo usado en este benchmark no fue presentado en este artículo. Lo veremos en un futuro artículo.

Puede ver el código fuente de los benchmarks en GitHub.

La explicación del los benchmarks y el código quedará para un próximo artículo.

Algoritmo N vs Algoritmo O

Si bien anteriormente vimos que el Algoritmo O realiza la mitad de operaciones que el Algoritmo N, en el peor caso; el tiempo de ejecución de ambos algoritmos se ve afectado por diversos factores, como por ejemplo: el largo de la palabra, si la palabra es palíndromo o no y otros factores correspondientes a la plataforma.

En muchos casos el Algoritmo N es más rápido en tiempo de ejecución que el Algoritmo O.

Analizaremos esto en un futuro artículo.

¿Solución definitiva?

Considero que ninguno de los tres algoritmos presentados en este artículo representan una solución definitiva, ninguno es un Componente.

Un componente debe ser algo que se pueda reutilizar y en muchos casos los algoritmos aquí descriptos no son aptos para ser reutilizados.\

Además, los tres algoritmos sólo aceptan un String como input. Un palíndromo no sólo es una secuencia de caracteres que se lee igual al derecho y al revés. Un palíndromo puede encontrarse en forma de notas musicales, números y también en la naturaleza.

No soy experto en genética, pero se que los palíndromos también pueden encontrarse en cadenas de ADN.
Los palíndromos en el ADN son tan importantes que algunos los consideran como responsables de evitar la extinción de la especie humana (y también otras especies) ya que de no existir los palíndromos en el ADN, se producirían mutaciones genéticas irreversibles e incorregibles, que con el paso del tiempo provocarían la extinción de la especie.
En algún futuro artículo charlaremos este tema.

Pendientes

Replicar el Algoritmo I en C# y analizar su eficiencia en tiempo de ejecución y consumo de memoria.

Conclusiones

El Algoritmo I es un excelente ejemplo de concisión y legibilidad, hace buen uso de abstracciones disponibles para lograr este objetivo. El problema con el Algoritmo I es que es un pésimo ejemplo de eficiencia.

Las abstracciones facilitan nuestra labor, nos permiten concentrarnos en el problema a resolver sin tener que pensar en el contexto, en nuestro caso la computadora.

Si bien las abstracciones son buenas, tienen una gran desventaja y es que nos hacen olvidar cómo funciona la máquina en la cual nuestro programa se ejecutará.
Los programadores modernos suelen abusar de las abstracciones y carecen de conocimiento o no le dan importancia a cuestiones importantes que afectan el comportamiento de nuestros programas, como: cache, load/store buffers, branch prediction, pipelines, modelos de memoria, instrucciones vectoriales (SIMD), etc…

Como programadores, debemos conocer en profundidad la computadora, el lenguaje de programación y la complejidad de los componentes que usamos. Pero, lamentablemente los programadores modernos se han olvidado de esto y están concentrados en otras cuestiones, como testing, agile, metaprogramming y frameworks/bibliotecas cuyo tiempo de vida no es mayor a dos años.

Volviendo a las abstracciones, la mejor de todas ellas fue descubierta por Leibniz en 1679. Esa abstracción es la que nos permite modelar el mundo real en una computadora. Esa abstracción es el Bit.

Por último, cabe destacar que el Algoritmo I podría ser útil como postcondición:


public static boolean isPalindrome(String str) {
    //postcondition: Result := reverse(str) = str
    int n = str.length();
    for (int i = 0; i < n/2; ++i) {
        if (str.charAt(i) != str.charAt(n-i-1)) return false;
    }
    return true;    
}

Agradecimientos

Quiero agradecer a Mario dal Lago y Javier Velilla por revisar el artículo y sugerir correcciones.
Y por último, ya que se puede decir que le debemos la vida a los palíndromos, un agradecimiento especial para ellos. :)

Notas

Byte = 8-bits.
Hay arquitecturas donde 1 byte no necesariamente equivale a 8 bits. Estas arquitecturas son inusuales hoy en día. No existe un estándar que especifique el tamaño de un byte, pero se puede decir que el estándar de facto es que 1 byte = 8 bits, es lo más común en arquitecturas de computadoras modernas.

Plataforma utilizada para el análisis en este artículo:

CPU
- Intel Core i7-4700MQ CPU @ 2.40GHz, Haswell
- 4 Cores, 8 Threads
- L1 Data Cache Size 4 x 32 KBytes
- L1 Instructions Cache Size 4 x 32 KBytes
- L2 Unified Cache Size 4 x 256 KBytes
- L3 Unified Cache Size 6144 KBytes
RAM: 8192 MBytes, DDR3
Operating System: Windows 10 Home 64-bit
Java
- Version 1.8.0_60\
- Java(TM) SE Runtime Environment (build 1.8.0_60-b27)\
- 64-bit HotSpot VM.\
- Compressed Oops activado\
- Objects alignment: 8 bytes.

Para el análisis en otras plataformas, por favor referirse a [7].

Referencias

[1] Zahlen significa “Números”, en Alemán. De ahí que el conjunto de los números enteros se lo identifica con la letra $ \mathbb{Z} $.

[2] The Art of Computer Programming Volume 1, by Donald E. Knuth [3rd Edition, page 107].

[3] ¿Por qué llamo a String.equals() “función” y no “método”?. He aquí la respuesta.

[4] En Java los tipos integrales y los arrays de tipo integrales se inicializan en 0, garantizado por la especificación del lenguaje. 4.12.5 Initial Values of Variables

[5] Java String class

[6] Java Primitive Data Types

[7] Análisis de consumo de memoria en otras plataformas (borrador sin publicar).

[8] La fórmula para calcular el padding de los arrays internos de StringBuilder y String son las siguientes (todo medido en bytes):
StringBuilder internal array padding = $ 8\left\lceil\dfrac{2n + 48}{8}\right\rceil - (2n + 48) $
String internal array padding = $ 8\left\lceil\dfrac{2n + 16}{8}\right\rceil - (2n + 16) $\

(Estas fórmulas son específicas para la plataforma descripta en el artículo)

La fórmula general para calcular el padding de objetos es la siguiente:

$$ alignment\left\lceil\dfrac{size}{alignment}\right\rceil - size $$

Mi charla: 'Introducción a Generic Programming'

2016-06-02T12:00:00.000Z

¡Buenas!

Les comparto el enlace a las filminas de mi charla denominada “Introducción a Generic Programming” que fue expuesta en el “Primer Encuentro de programadores C++ de Buenos Aires” el día 31 de Marzo de 2016.

En ese encuentro también tuvimos el agrado de presenciar la excelente charla brindada por nuestro colega Agustín (K-Ballo) Bergé, titulada “The C++ Way”, donde nos cuenta acerca de las nuevas características incorporadas en C++11 y C++14.

Espero que les gusten nuestras presentaciones y les de ganas de sumarse a nuestra comunidad.

¡Saludos!

Invitación a Vino de Honor

2016-05-04T12:00:00.000Z

El día 4 de mayo de 2016, he sido invitado por la señora Ministra de Relaciones Exteriores y Culto (Canciller), Da. Susana Malcorra, al Vino de Honor que tuvo lugar en el Salón Dorado del Palacio San Martín, en ocasión del Saludo a los miembros de la Comisión Nacional del Límite Exterior de la Plataforma Continental (COPLA).

¡Muchas gracias a la Sra. Canciller y felicitaciones a todo el equipo!

El límite más extenso de la Argentina – Nuestra frontera con la humanidad

Referencias

Twitter oficial de Susana Malcorra

Límite Exterior de la Plataforma Continental

2016-03-11T12:00:00.000Z

El día 11 de marzo de 2016, el plenario de la 40º Sesión de la Comisión de Límites de la Plataforma Continental (CLPC) de las Naciones Unidas, aprobó por consenso, es decir sin un solo voto en contra, las Recomendaciones sobre la presentación argentina del Límite Exterior de la Plataforma Continental. La República Argentina había presentado el límite exterior de la plataforma continental de todo el territorio argentino —continental, insular y Antártida Argentina— ante la CLPC el 21 de abril de 2009.

Ha sido un honor y orgullo el haber sido miembro de este equipo y de este proyecto, que espero que sirva para mejorar la calidad de vida de todos los argentinos.

¡Felicitaciones a todo el equipo!

El límite más extenso de la Argentina – Nuestra frontera con la humanidad

Referencias

FOLLETO-COPLA-2016_1

Alex se jubiló

2016-01-14T12:00:00.000Z

Alex se ha jubilado.

Les comparto una estampilla conmemorativa, diseñada por Joyce Croft y Alexander Zeyliger de A9.

Tengo que confesar que siento tristeza, ya que me hubiera gustado que Alex siga aportando ideas por mucho tiempo más tiempo.
Pero se ha retirado y estoy feliz por él.

Le deseo tenga un excelente y merecido descanso con su familia y amigos.


auto who = successor(alex);

¡Gracias!

¡Gracias Alex!

2015-11-25T12:00:00.000Z

Estoy muy contento de haber recibido estos dos regalos.

Son dos excelentes libros.

Es un honor para mí que estén autografiados por uno de los más grandes de nuestra disciplina.

No te prives del placer de leerlos.

Elements of Programming en Amazon.

From Mathematics to Generic Programming en Amazon.

¡Gracias nuevamente Alex!

¿Cuál es tu sabor de Objeto preferido?

2015-09-26T12:00:00.000Z

En este artículo quiero continuar la discusión sobre la terminología que usamos los programadores diariamente, siguiendo con la línea de “Usando la terminología adecuada: ¿Método?”.

Introducción

Los programadores, sobre todo desde la popularización de la Programación Orientada a Objetos, usamos la palabra Objeto sin realmente pensar en su significado.\

Desde siempre me llamó la atención toda la terminología relacionada al Paradigma de Orientación a Objetos ya que considero que muchas de las definiciones de dicho paradigma son ambiguas o muy dispares entre los distintos autores.

¿Qué significa “Objeto”?

En ciencias de la computación, y especialmente en programación, no existe una definición formal ni única de “Objeto”.
Diferentes autores de lenguajes de programación y autores de textos le han atribuido diferentes significados a la misma.

Intentaré en este artículo exponer y analizar las diferentes definiciones y llegar a una conclusión sobre cuál es la definición más acorde al estilo de programación adoptado en este blog.

Simula

La definición aportada por los autores del lenguaje de programación Simula es la siguiente:

An object is a self-contained program (block instance) having its own local data and actions defined by a “class declaration”. The class declaration defines a program (data and action) pattern, and objects conforming to that pattern are said to “belong to the same class”. [1]

La definición anterior es importante, ya que Simula es considerado el primer lenguaje de programación Orientado a Objetos.

Tres cosas se destacan en la definición:

Un objeto tiene datos propios.
Un objeto incluye acciones.
Pertenencia de un objeto a una clase.

Smalltalk

Si bien Simula es el primer lenguaje de programación orientado a objetos, el marketing fuerte del paradigma de objetos surgió con el lenguaje Smalltalk. Se puede decir que Smalltalk es el lenguaje más influyente en lo que respecta a Objetos.

Según el Manual de instrucciones de Smalltalk-72: [2]:

Every entity in Smalltalk’s world is called an object. Objects can remember things and communicate with each other by sending and receiving messages. Every object belongs to a class…

Se destacan las mismas tres cosas que en la definición de Simula, pero con variaciones:

Un objeto tiene datos propios: “remember things”.
Un objeto incluye acciones: La comunicación mediante mensajes es una forma particular de acción.
Pertenencia de un objeto a una clase.

Y, según el estándar de Smalltalk [3]:

An object is a computational entity that is capable of responding to a well defined set of messages. An object may also encapsulate some (possibly mutable) state.

Se destaca:

Un objeto tiene datos propios: “state”.
Un objeto incluye acciones: La comunicación mediante mensajes es una forma particular de acción.
Se agrega el concepto de mutabilidad.

Eiffel - Object-Oriented Software Construction

Object-Oriented Software Construction es una de las más importantes referencias disponibles en cuanto a orientación a objetos. Fue escrito por Bertrand Meyer, el diseñador del lenguaje de programación Eiffel.\

Eiffel es uno de los denominados lenguajes puramente orientados a objetos, ya que incluso sus tipos básicos (built-in types), como integer o real, están creados mediante clases.

Aquí la definición de objeto dada por Meyer en OOSC [4]:

Object: A run-time data structure made of zero or more values, called fields, and serving as the computer representation of an abstract object. Every object is an instance of some class.

En la definición anterior se establece que:

Un objeto tiene datos propios: “made of zero or more values”.
Pertenencia de un objeto a una clase.

C++

C++ es un lenguaje que soporta la tecnología de objetos.
C++ tiene una definición de objeto muy distinta a la que la mayoría de los programadores está acostumbrado.

Según el estándar de C++ [5]:

… An object is a region of storage. [Note: A function is not an object, regardless of whether or not it occupies storage in the way that objects do. —end note] …

C (lenguaje de programación)

Ustedes se preguntarán por qué estoy incluyendo al lenguaje de programación C en esta lista si este no incluye características de lenguajes orientados a objetos.

Si bien el lenguaje C no es un lenguaje orientado a objetos, este incluye en su estándar [6] la definición de objeto:\

object: region of data storage in the execution environment, the contents of which can represent values…

Elements of Programming

Elements of Programming es la magnum opus de Alexander Stepanov y Paul McJones.
Según mi consideración, va camino a convertirse en un texto clásico de la programación, así que recomiendo a todo aquel amante de esta hermosa disciplina que no se prive de leerlo.

An object is a representation of a concrete entity as a value in memory. An object has a state that is a value of some value type. The state of an object is changeable. Given an object corresponding to a concrete entity, its state corresponds to a snapshot of that entity…
…
An object type is a pattern for storing and modifying values in memory. Corresponding to every object type is a value type describing states of objects of that type. Every object belongs to an object type. An example of an object type is integers represented in 32-bit two’s complement little-endian format aligned to a 4-byte address boundary. [7]

En la definición anterior, Stepanov y McJones, intentan tomar distancia de cualquier tipo de paradigma de programación y establecer una definición más general de lo que un objeto significa. Si bien se notan claras diferencias con las definiciones anteriores, se pueden ver algunas semejanzas:

Un objeto tiene datos propios: “value in memory”, “state”.
Un objeto incluye acciones: “storing and modifying values in memory” son básicamente acciones o comportamiento.
Pertenencia de un objeto a una object type.
Un objeto es mutable.

Conclusiones

Como ustedes habrán notado, existe una gran variedad de definiciones de objeto. Algunas de ellas coinciden en ciertas características y otras difieren en otras.

El autor del blog prefiere la definición dada por Stepanov y McJones en Elements of Programming. Considero que es la definición más completa, práctica, amplia y con mayor base matemática.

Es la definición más completa, porque comienza desarrollando una taxonomía de ideas como Entity, Species, Genus, que sirve como base para la definición de objeto y otras definiciones. Estas definiciones no están incluídas en este artículo, para conocer más al respecto por favor referirse al libro.

Es la definición más práctica, ya que se es consciente que todo programa se ejecuta en computadoras que poseen memoria y estas constituyen la única realización disponible de un dispositivo computacional universal. No depende de dispositivos computacionales teóricos o imaginarios.

Es la definición más amplia, ya que en ella no se excluye a lenguajes no pertenecientes al paradigma de objetos.

Nuevamente, yo hice mi elección, pero no hace falta decir que usted puede elegir la definición que más le guste, sólo asegúrese de que su pensamiento esté libre de influencias difundidas por la maquinaria propagandística de Objetos :).

Serie “Terminología”:

Usando la terminología adecuada: ¿Método?
¿Cuál es tu sabor de Objeto preferido?

Notas / Referencias

Aclaración: El énfasis/negrita en cada una de las definiciones presentadas va por cuenta del autor del artículo.

[1] SIMULA 67: COMMON BASE LANGUAGE, by Ole-Johan Dahl, Bjørn Myhrhaug and Kristen Nygaard. Publication No. S-22. Classes 1. 3. 3 [page 6]

[2] Smalltalk-72 Instruction Manual by Adele Goldberg and Alan Kay [page 44]

[3] ANSI Smalltalk Standard v1.9 199712 NCITS X3J20 draft, Section 3.1 [page 9]

[4] Object-Oriented Software Construction (2nd Ed) by Bertrand Meyer [1997, page 1198]\

[5] ISO International Standard ISO/IEC 14882:2014(E) – Programming Language C++, current working draft (at Aug, 2015), section: 1.8 [intro.object] paragraph 1.

[6] ISO/IEC 9899:201x Committee Draft – Programming languages — C (last draft available at Aug, 2015), section: 13.15.

[7] Elements of Programming by Stepanov and McJones [2009, page 4]\

EoP’s concrete entity definition: An abstract entity is an individual thing that is eternal and unchangeable, while a concrete entity is an individual thing that comes into and out of existence in space and time… Blue and 13 are examples of abstract entities. Socrates and the United States of America are examples of concrete entities…

Usando la terminología adecuada: ¿Método?

2015-08-12T12:00:00.000Z

En esta serie de artículos mi intención es revisar por qué los programadores usamos cierta terminología, ciertas palabras, algunas de las cuales considero inadecuadas.
En este caso quiero hablar sobre la palabra método (method en inglés).

Antes que nada…

¿Qué es un método?

Cualquier programador sabe que un objeto [1] tiene estado y comportamiento. El estado se almacena en campos (fields en inglés) y el comportamiento se logra a través de métodos.
Un método (en el contexto de la programación) es una secuencia de instrucciones, es parte de un objeto o clase. [2]

Pero…

¿Por qué “método”?

¿Qué diferencia hay entre un método y un procedimiento?
Un procedimiento es una secuencia de instrucciones. [2]

¿La única diferencia consiste en que un método debe pertenecer a una clase mientras en que un procedimiento no se aclara nada con respecto a clases? (De hecho el término “procedimiento” es usado desde mucho antes de la existencia del término “clase”).

Resumiendo, un método es un procedimiento que es miembro de una clase.
Entonces, tenemos procedimientos que son miembros y procedimientos libres (fuera de una clase).

Me sigo preguntando, …

¿Por qué usamos el término “método” y no “procedimiento”?

Mi hipótesis es que con el establecimiento de Java como uno de los lenguajes de programación más populares, también se produjo la popularización de su terminología. A partir de ese momento, otros lenguajes y programadores adoptan la terminología popularizada por Java y se vuelve más frecuente su uso que la terminología tradicional.

Quiero ahora hacer una búsqueda a través de la historia de los lenguajes de programación para entender por qué comenzamos a llamar “método” a los “procedimientos”. Voy a ir desde tiempos más modernos a tiempos más remotos…

Java

En Java, no existen los procedimientos libres, todos los procedimientos deben ser miembro de una clase, estos procedimientos miembro efectivamente se llaman métodos.

Según la especificación de Java 8 [3]:

The body of a class declares members (fields and methods and nested classes and interfaces), instance and static initializers, and constructors.
Method declarations describe code that may be invoked by method invocation expressions.

La especificación de Java describe la relación entre un método y una clase, aunque no establece cuál es la definición de la palabra “método”.

Más allá de la definición, en la especificación no vamos a encontrar por qué los diseñadores del lenguaje decidieron llamar “método” a los procedimientos, así que debemos ir más atrás.

Java hereda la mayor parte de su sintaxis (no así su semántica) y terminología de C++.

C++

C++ nace, a finales de la década de 1970, como un súper-conjunto del lenguaje de programación C con el agregado tecnología de objetos.

Por lo tanto, en C++ tenemos procedimientos miembros y libres, denominados member y non-member functions.

Según el estándar de C++ [4]:

Member functions: Functions declared in the definition of a class, excluding those declared with a friend specifier, are called member functions of that class.

O sea, en C++ no se usa la palabra “método”. Puede que algunos programadores C++ usen la palabra “método” debido a que el término es muy popular hoy día; pero, tanto el estándar C++ como los programadores más cercanos al riñón del lenguaje no lo utilizan.

Entonces… ¿Cuál es el término correcto para designar el código que modela el comportamiento de los objetos? ¿Es “método”? ¿Es “procedimiento”? ¿Qué lenguaje usa la terminología más adecuada?

Para ello debo ir aún más atrás.
C++ hereda su “parte” de objetos del lenguaje de programación Simula.

Simula

Simula es considerado el primer lenguaje de programación orientado a objetos. Es un lenguaje de tipado estático basado en ALGOL 60.

Simula permite que los procedimientos sean declarados dentro de una clase y también fuera de ella. A los primeros los denomina local procedures y a los últimos non-local procedures. [5]

Entonces, si C++ y Simula no hacen mención a algo llamado “método”, ¿De dónde saca Java esa palabra? ¿Es una invención de los diseñadores del lenguaje? ¿La copia de algún otro lenguaje?

La respuesta es…

Smalltalk

Smalltalk es un lenguaje de programación orientado a objetos, inspirado en Simula (en parte), que fue desarrollado durante la década de 1970 y vio la luz a principios de los 80’s. A diferencia de Simula, Smalltalk es un lenguaje de tipado dinámico.

Smalltalk incorpora los conceptos de mensajes y métodos.

Según el estándar de Smalltalk [6]:

A message is a request to perform a designated computation. An object is a computational entity that is capable of responding to a well defined set of messages. An object may also encapsulate some (possibly mutable) state.
An object responds to a message by executing a method. Each method is identified by an associated method selector. A behavior is the set of methods used by an object to respond to messages.
A method consists of a sequence of expressions. Program execution proceeds by sequentially evaluating the expressions in one of more methods. There are three types of expressions: assignments, message sends, and returns.

Como no pude encontrar referencias anteriores a Smalltalk sobre algún otro lenguaje que utilice la palabra “método”, le consulté a Paul McJones, miembro del Software Preservation Group y coautor de Elements of Programming. Considero a Paul una eminencia en lo que respecta a historia de la computación y en particular los lenguajes de programación.

Fernando: … Do you know any programming language, before Smalltalk, that use the word “method”? …

Paul: You ask a very interesting question. I think you are correct that the word “method” was first used in that sense by the Smalltalk community. I looked through some early documents, such as the Smalltalk-72 Instruction Manual, and I don’t see “method” being used yet… Dan Ingalls’s 1978 POPL paper on Smalltalk-76 is the earliest paper I’ve found so far that uses method in the sense you are interested in…

Paul cree, al igual que yo, que la palabra “método” fue usada por primera vez por la comunidad de programadores Smalltalk. Además me indica que estuvo revisando viejos manuales y en el manual de Smalltalk-72 [7] no se hace mención sobre “método”, pero sí es mencionado en un paper de 1978 que habla sobre Smalltalk-76. [8]

O sea, estoy casi seguro que la comunidad Smalltalk acuñó el término, pero no lo hizo desde el principio sino a medida que el lenguaje fue evolucionando.

Otros lenguajes

Quiero aquí analizar otros lenguajes que también soportan tecnología de objetos para verificar como nomenclan a sus procedimientos.

Eiffel

Eiffel es un lenguaje que nace a mediados de 1980 y, al igual que C++, es heredero directo de Simula.

En Eiffel todo miembro de una clase se lo llama feature. Al estado se lo denomina attributes y al comportamiento routines. A su vez, las routines se dividen en functions y procedures dependiendo si retornan o no un resultado. [9]

En Eiffel todas las routines son miembros de una clase, no se permite la existencia de procedimientos libres.

Python

El lenguaje de programación Python admite tanto procedimientos libres como procedimientos miembros. Los denomina functions y methods respectivamente. [10]

Python me llamó la atención porque es creado unos años antes que Java; la primera implementación de Python es de 1989 [11] mientras que la primera de Java es de 1995 [12].
Pareciera que este hecho rompe mi conjetura de que Java fue el impulsor de la palabra “método”.

Si bien la primera implementación de Java sale a la luz en 1995, en tan solo unos años, en 1998, ya era unos de los lenguajes más populares. En cambio Python tuvo un camino bastante más lento hacia su popularización, recién comenzó a ser popular por los años 2003/2004. [13]
Por lo que mi conjetura todavía sigue siendo válida, el impulsor de “método” fue Java y no Python.

Volviendo a Python, la palabra “método” es mencionada en las versiones recientes (3.4.3 y 2.7.10) de la documentación del lenguaje. Entonces dudé sobre si Python utiliza “método” desde sus orígenes o si fue mutando su terminología con el tiempo, sobre todo con la popularización de Java.
Gracias a que los muchachos de python.org hacen un excelente trabajo manteniendo las versiones históricas de la documentación, pude verificar que la palabra “método” es utilizada desde la versión 0.9.1 [14] (salvo que la documentación haya sido alterada con el tiempo, pero confiemos en que no sea así).

O sea, Python es el primer lenguaje, después de Smalltalk, en usar la palabra “método”. Al menos de los lenguajes que he podido verificar.

Al igual que me lo pregunto con Java, ¿Por qué Python usa método y no algún otro término más común para esa época?.

Nadie mejor que el creador del lenguaje, Guido van Rossum para iluminarme. Me tomé el atrevimiento de escribirle un correo electrónico; Guido fue muy amable en responderme y permitir que lo cite en este artículo:

Fernando: Why did you use “method” instead of any other word? Have you taken from Smalltalk? Or,… from any other programming language?

Guido: Good question. I don’t recall, but it’s likely that I was somehow influenced by Smalltalk, or people around me who were influenced by Smalltalk. I definitely opened a big book about Smalltalk to learn about byte code, and I also recall we had a Smalltalk implementation that we sometimes played with (some things that were wrong with that influenced some of my philosophy for Python).

Guido no recuerda bien, pero admite haber sido influenciado por Smalltalk en aquella época.

C#

C# es un lenguaje de programación que nace siendo muy similar a Java (casi idéntico) con algunas reminiscencias de C++. Luego, con los años el lenguaje formó su propia identidad.

C# copia en su gran mayoría la terminología de Java. Una de las palabras que copia es “método”.

Según el estándar C# [15]:

A method is a member that implements a computation or action that can be performed by an object or class.

A diferencia de Java, el estándar C# sí define el significado de la palabra “método”.

Al ser un lenguaje muy usado, especialmente por seguidores de la “filosofía” Microsoft, C# también ha contribuido a la popularización del término.

Objective-C

Objective-C es un lenguaje desarrollado a principios de los 1980’s. Al igual que C++, nace como un súper-conjunto de C al que se le agrega tecnología de objetos.
A diferencia de C++, el modelo de objetos de Objective-C está basado en Smalltalk y no en Simula.

Objective-C cuenta con el concepto de mensajes y también el de método. [16]

Lenguajes anteriores a Smalltalk

He buscado en manuales, estándares y documentación de lenguajes de programación anteriores a Smalltalk, no relacionados con orientación a objetos, pero sí muy reconocidos por su influencia sobre los demás lenguajes de programación.
Específicamente los lenguajes son: Fortran, Algol y C. En la documentación de ninguno de ellos se hace mención a la palabra “método”. En cambio usan términos como routine, subroutine, procedure o function [17].

Otras fuentes

Para mejorar mi investigación he hecho una búsqueda en la bibliografía (sobre programación en general) que tengo a mi disposición, textos que considero clásicos.

Elements of Programming by Alexander A. Stepanov and Paul McJones
The Art of Computer Programming Volumes 1, 2, 3 and 4A by Donald E. Knuth

En ninguna de las 3.456 páginas de estos 5 libros he encontrado la palabra “método” haciendo referencia a un “procedimiento”. Obviamente la palabra “método” aparece en varias oportunidades, pero no en el sentido que estoy buscando.

Pendientes

Leer documentación/manuales originales sobre los siguientes lenguajes de programación:
- Lisp
- Scheme
- Ada
- Modula-2
- Common Lisp
Buscar en algunos textos clásicos:
- A Discipline of Programming by Edsger W. Dijkstra
- Algorithms and Data Structures by Niklaus Wirth
- Structured Programming, First Edition Edition by Edsger W. Dijkstra, C. A. R. Hoare and Ole-Johan Dahl
- Systematic Programming: An Introduction by Niklaus Wirth
Enviar mi consulta a los siguientes diseñadores de lenguajes de programación:
- Alan Kay
- Dan Ingalls
- Dick Gabriel
- James Gosling
- Anders Hejlsberg

He tratado de contactar a alguno de ellos, pero no he recibido respuesta aún.

Conclusiones

La palabra “método” ha sido introducida al mundo de la programación por el lenguaje Smalltalk. Al ser un lenguaje prácticamente no usado en la industria, la palabra no era muy conocida allá por los 80’s y principios de los 90’s.

Quizás fue un error de los diseñadores de Smalltalk el no haber utilizado nomenclatura existente, o quizás no fue un error, ya que Smalltalk introdujo un modelo de objetos distinto al de Simula y ese cambio quizás ameritó un cambio de nombres. Es muy difícil de determinar si fue una decisión equivocada o no.

Java y Python adoptan terminología de Smalltalk en su vocabulario. No encuentro un vínculo muy fuerte entre Smalltalk y Java/Python que justifique el uso del término, esto me hace pensar en que el uso de “método” es un error en estos lenguajes. Aunque, como dije antes, es muy difícil de juzgar si la decisión de usar cierta nomenclatura es errónea.

C++, Objective-C y Eiffel utilizan terminología similar a sus predecesores, puede que con algunas variaciones, que pueden ser mínimas o necesarias para adaptarse a cambios introducidos por los lenguajes.

Algunos lenguajes, como C#, copian características de Java, pero también copian el “error” de incorporar “método” a su terminología.

La palabra “método” se infiltra en el vocabulario de los programadores.
Ya no hay vuelta atrás ;)

Usted use el término que más le guste, yo me voy a seguir usando procedimiento o función (siempre y cuando recuerde que no me gusta la palabra “método”).

Agradecimientos

Un agradecimiento especial para Paul McJones y Guido van Rossum por responder amablemente a mis preguntas y por brindarme información trascendental.
También quiero agradecer a Mario dal Lago y Javier Velilla por revisar el artículo y sugerir correcciones.

Notas / Referencias

[1] Aquí nos referimos a la definición de “objeto” en el contexto de la Programación Orientada a Objetos:
Object-Oriented Software Construction (2nd Ed) by Bertrand Meyer [1997, page 1198]
Que difiere de la definición de “objeto” dada en:
Elements of Programming by Stepanov and McJones [2009, page 4]
Esta última definición es la preferida por el autor del blog, en caso de que no se aclare a cuál de las dos definiciones se hace referencia, el lector debe asumir que se está hablando de la definición dada por Stepanov.

[2] Definición simplificada, para una definición más detallada referirse a:
Object-Oriented Software Construction (2nd Ed) by Bertrand Meyer [1997, page 174]

[3] The Java Language Specification (Java SE 8 Edition), Chapter 8 [pages 191, 192]

[4] ISO International Standard ISO/IEC 14882:2014(E) – Programming Language C++, current working draft (at Aug, 2015), sections: 9.3 [class.mfct] and 8.3.5 [dcl.fct]\

[5] Hay muy poca bibliografía disponible acerca del lenguaje, pero aquí pueden encontrar un excelente trabajo de recopilación de viejos manuales.\

[6] ANSI Smalltalk Standard v1.9 199712 NCITS X3J20 draft, Section 3.1 [page 9]

[7] Smalltalk-72 Instruction Manual by Adele Goldberg and Alan Kay [page 44]

[8] The Smalltalk-76 Programming System. Design and Implementation

[9] Se especifica en:
Object-Oriented Software Construction (2nd Ed) by Bertrand Meyer [1997, pages 174, 175]
y en:
Standard ECMA-367. Eiffel: Analysis, Design and Programming Language. 2nd edition (June 2006), Section 8.5.10 [page 38]\

[10] Python 2.7.10 Documentation

[11] A Brief Timeline of Python

[12] The History of Java Technology

[13] Sobre la popularización de los lenguajes, una de las fuentes en las que me baso es Tiobe Index. Aunque tengo ciertas dudas sobre el método de medición de Tiobe, hoy en día es lo mejor que tenemos.
La otra fuente es mi memoria. No recuerdo a Python como un lenguaje popular en los 90’s.
Yo creo que Python comienza a popularizarse con el boom de los lenguajes dinámicos a comienzo de los 2000’s y tiene un empuje aún mayor con la creación del framework web Django.

[14] Repositorio de viejas versiones de Python

[15] Standard ECMA-334. C# Language Specification. 4th edition (June 2006), Section 8.7.3 [page 34]

[16] Objective-C no cuenta ni con un estándar ni una especificación. Lo más “formal” que encontré fue una página web:
Programming With ObjectiveC
Kimberley Hagan me escribió para compartir un recurso que cree que puede ser valioso para programadores Objective-C, así que aquí dejo el enlace por si quieren pegarle una mirada:
Objective-C: Guide and Resources\

[17] Para documentación sobre FORTRAN, ALGOL y C: ISO/IEC JTC1/SC22/WG14 - The international standardization working group for the programming language C.