Las estructuras de datos son esos componentes que los programadores utilizamos en nuestro día a día, y muchas veces las damos por sentado como herramientas que existen, sin realmente darnos el tiempo de conocerlas a detalle.

De los primeros conceptos que uno investiga al momento de aprender un nuevo lenguaje de programación son:

  • ¿Cómo puedo almacenar múltiples datos en una variable?
  • ¿Existen las listas?
  • ¿Tenemos arreglos?
  • ¿Cómo puedo asociar llaves a valores? ¿Diccionarios, arreglos asociativos, mapas, …?

Todo lo anterior es solo muestra de la importancia de las estructuras de datos en nuestra cotidianeidad. Pero, ¿qué es realmente una estructura de datos?

Alrededor de los 70’s, Niklaus Wirth publica su libro Algorithms + Data Structures = Programs. A pesar de que algunas estructuras de datos ya eran utilizadas, por primera vez tenemos una guía estándar para poder implementarlas en nuestro código.

Para ejemplificar lo anterior, tomemos un arreglo:

Arreglo sin ordenar Disculpen mi falta de talento artístico.

Brevemente, un arreglo es una sucesión de valores. Esta es una explicación demasiado simplificada, y un tanto inútil para poder entender realmente cómo y cuándo usarlos, pero para nuestro ejemplo es suficiente.

Muchas veces, cuando tenemos un arreglo de números, queremos ordenar esos números de menor a mayor. Para eso utilizamos un algoritmo.

Podríamos dedicar mucho tiempo a explicar la idea detrás de un algoritmo, pero en términos simples, y siguiendo la corriente propuesta por el álgebra moderna en donde definimos algo según su comportamiento, un algoritmo es:

  • Serie de pasos (instrucciones) finitos.
  • Reciben una entrada.
  • Producen una salida.

Entonces, regresando a nuestro ejemplo anterior. Tenemos un arreglo, y tenemos un algoritmo para ordenar los elementos del arreglo. Nuestro arreglo es una estructura de datos, y tenemos un algoritmo asociado a esa estructura (para ordenar elementos).

Arreglo sin ordenar

Ya entendimos cómo funciona la idea general, pero probablemente aún no queda claro qué es una estructura de datos. Nuevamente, regresemos al contexto histórico.

En 1974, Barbara Liskov propuso un modelo teórico en donde se presenta el uso de tipos de datos abstractos. Los tipos de datos abstractos, también se definen según su comportamiento (como vimos anteriormente con los algoritmos). Y eso es lo importante del asunto, los tipos de datos abstractos: ¡son abstractos!.

¿Qué implica tener un tipo de dato abstracto? Por un lado, hace más sencillo su estudio matemático (no olvidemos que la computación comienza como una rama de las matemáticas, y sigue siendo el caso para las Ciencias de la Computación) pues se alinea con las nociones de matemáticas discretas y álgebra moderna. Pero eso no nos importa de momento, lo importante para los programadores es que un tipo de dato abstracto nos permite tener una construcción (nuestro tipo de dato abstracto) que podemos implementar en cualquier lenguaje de programación.

Y esa implementación de un tipo de dato abstracto, es a lo que nos referimos por estructura de datos.

Nota: Que un tipo de dato abstracto pueda implementarse en cualquier lenguaje, no implica que sea buena idea. Pero eso está fuera del alcance de este post.


De acuerdo, ya tenemos el contexto histórico, y creo que para este momento ya es más que evidente en qué consiste una estructura de datos; pero si quedan dudas, aquí está una idea un poco más intuitiva y aplicable a la programación cotidiana:

Una estructura de datos es una forma de organizar información aprovechando las capacidades de la computadora.

Y en pocas palabras, eso es lo verdaderamente aplicable. Pero en realidad, su importancia va un poco más allá.


¿Para qué hay distintas estructuras de datos? La respuesta no es sencilla. Algunos dirán que las estructuras de datos no tienen importancia, que solo uses lo que te parezca natural como programador, y me atrevo a decir que están completamente equivocados, y además, no deberían dedicarse a programar. También están los que dicen que las estructuras de datos no son algo por lo que preocuparse hoy en día, las bibliotecas estándar de los lenguajes de programación nos tienen cubiertos; y no están completamente mal, simplemente no se han encontrado con un problema medianamente interesante.

La respuesta que, si bien no es la verdad absoluta, pero a mi parecer es suficientemente convincente es: las estructuras de datos nos permiten aprovechar al máximo la capacidad de cómputo con la que contamos. No pretendo detallar mucho al respecto, pero existe el concepto de complejidad computacional que lidia con preguntas del tipo:

  • ¿Qué tan rápido puede darnos una computadora una respuesta a una pregunta?
  • ¿Qué tanta memoria va a utilizar la computadora dada esta información?
  • ¿Podemos encontrar una estructura de datos o un algoritmo para hacerlo más eficientemente?

Y esa es la importancia de las estructuras de datos: son facilitadores para realizar cómputo eficiente. Y dije facilitadores, no metas en sí mismas, pues hay otros factores a tomar en cuenta.


Ahora, tal vez no es prioridad para ti como programador en tu día a día realizar cómputo eficiente. Probablemente eso es algo restringido al cómputo científico, al estudio metereológico o de partículas, probablemente solo le importa a los que trabajan con criptografía, inteligencia artificial o incluso análisis de datos, o tal vez algo con lo que solo las grandes compañías lidian.

Y hoy en día, tal vez no está mal pensar así, pues es cierto que cada día las computadoras se vuelven mejores al punto en que no importa cuánta memoria utiliza nuestro programa o qué tanto tiempo toma, porque tenemos 16GB de RAM y un procesador de 4GHz. Pero no está mal conocer de estructuras de datos para cuándo te encuentres un problema en donde sí importa escribir código eficiente.

Incluso si nunca te encuentras ese problema, no está de más saber el comportamiento interno de las estructuras de datos que usamos como lo son los arreglos, las listas, diccionarios o hash tables, árboles, gráficas, y muchos más que son los componentes básicos de todo el cómputo. En fin, somos programadores, este tipo de cuestiones es lo que nos interesa, ¿o no?