DEV Community: Baltasar García Perez-Schofield

Un mal profesor, un práctica y una dura lección.

Baltasar García Perez-Schofield — Tue, 10 Nov 2026 08:29:45 +0000

Corría el año 1997. Estaba terminando la carrera de informática. Después de un accidente de coche, había tenido que ausentarme un cuatrimestre entero del año anterior, así que en quinto de carrera tuve trabajo "extra". Tenía poco tiempo, vamos.

El caso es que tuve un profesor muy curioso. Este profesor faltaba con tanta frecuencia a clases, que al final solo impartió alrededor de un tercio del temario, siendo generosos. De hecho, empezó una de las última clases del cuatrimestre afirmando "No sé qué ha pasado este año." Vaya. Pues yo creo que no era demasiado difícil de deducir. Para acabar de rematarla, resulta que de vez en cuando decía "Que sepáis que lo que os dije la semana pasada es mentira." Al final, tiré aquellos "apuntes" y me compré cierto libro de gran renombre sobre el tema.

Pero era en la práctica de otra asignatura donde se mascaba la tragedia. Mi compañera de prácticas y yo decidimos repartirnos el trabajo de una manera inédita para mi: ella me explicaba los pasos que tenían que dar los algoritmos que nos habían proporcionado los profesores, y yo lo implementaba. Parecía una buena idea, teniendo en cuenta mi falta de tiempo. Se trataba de un motor de inferencia, en el que el típico ejemplo era que lo alimentabas con datos como hijo(paula, pablo) e hijo(pablo, daniel) y con reglas como nieto(x, y) :- hijo(x, z), hijo(z, y), debía deducir nieto(paula, daniel).

Lo cierto es que yo no sabía ni eso del proyecto; solo había comprendido la forma más básica de implementar cada paso aislado de cada algoritmo, sin saber lo que realmente hacían, ni cada uno, ni mucho menos en conjunto. Y, quién lo iba a decir, aquel programa no funcionaba; vamos, que no deducía nada. La cuestión es: ¿cómo arreglas un programa que no sabes lo que tiene que hacer, ni tampoco cómo tiene que hacerlo? ¿Cómo saber dónde hay que mirar? La respuesta es simple: no puedes.

Al final, otro compañero tuvo que ayudarnos para salir del atolladero, y finalmente pudimos entregar aquello. Pero me sentía totalmente frustrado e incluso avergonzado... ¿cómo había podido acabar en aquella situación? Tenía en bastante buena estima mi propia pericia como programador. Sobre todo, porque siempre lo había disfrutado a tope, y de hecho, me había preocupado de estudiar más allá de lo que ofrecía la carrera, mediante libros, por ejemplo (Internet no era lo que es ahora, ni de lejos). Pero es que la cosa era peor: ¿cuál era el error concreto que había cometido?

Volvamos a aquel profesor peculiar. En una de sus clases, ni siquiera recuerdo por qué, va y nos suelta: "Nunca utilicéis algo que no entendáis como funciona."

Ahí fue cuando todo encajó con un sonoro "click" en mi cabeza. Había utilizado algoritmos que no entendía cómo funcionaban, simplemente aprendiendo al nivel más básico posible lo que hacían en cada paso, para crear código que creía que resolvía un problema que, en realidad, tampoco entendía. Y no podía arreglar algo que no entendía.

Y así fue como aquel profesor tan peculiar consiguió enseñarme algo finalmente. Y es algo tan básico que se aplica a toda esta locura de la IA. Si la utilizas para generar código que no entiendes cómo funciona... ¿quién lo va a arreglar cuando ocurra algún error?

Mi ideal de uso de la IA es: genial para condensar y explicar documentación, no tengo problema con que me sugiera código, es decir, soluciones para ciertos problemas (que habrá que "auditar"), pero desde luego nunca será en mis proyectos un agente "suelto" generando código por si mismo.

Conclusiones sobre Go: ¿un C++ ligero?

Baltasar García Perez-Schofield — Wed, 04 Nov 2026 11:55:13 +0000

Después de evaluar Go, durante las últimas semanas, debo admitir que... me gusta. Debe ser entendido como un C extendido, más que como una variante de C++, pero que soporta ciertos características de POO (programación orientada a objetos).

Es decir, uno podría pasarse a Go sin echar de menos, necesariamente, características de objetos. Se aprecia desde el principo que la idea es simplificar, siguiendo las conclusiones más actuales sobre POO, dejando de poner tanto énfasis en clases y herencia (aunque se soporta de alguna forma), y sobre todo, poniendo el énfasis en el polimorfismo.

Así que... definitivamente, un programador de C se sentirá muy cómodo en Go, probablemente notando que está utilizando un C mejorado con algunas extensiones de POO. Un programador de C++, Java o C# puede también sentirse cómodo, sintiendo que tiene que adaptarse, en cierto sentido, a algunas restricciones.

Por supuesto, no todo es mágico en Go. Ya he dicho que me gusta, pero tengo las siguientes espinitas.

El sistema de paquetes. Si pones package x, tienes que tener ese archivo x.go en su propio subdirectorio x. Es decir, si decides reorganizar la estructura de tu aplicación, te encontrarás que tienes que rehacer la estructura de directorios, y también renombrar los package dentro de los archivos Go.
Compilación de paquetes. Afortunadamente, un package se compila solo una vez (al contrario que en C, donde es necesario crear las famosas guards). Pero... no se permiten relaciones circulares. Es decir, la estructura Punto de un paquete A puede hacer uso de la estructura Lector un paquete B. Pero en ningún caso desde el paquete B se puede hacer referencia a Punto del paquete A. Para superar esto, será probablemente necesario crear una interface para la estructura Lector. Quizás pueda ser posible refactorizar ambos paquetes para eliminar el mayor número de dependencias. Esto está lejos del soporte de Java o C#, que automáticamente crean lo que sería equivalente a las interfaces de las clases, con el esqueleto de las firmas de los miembros públicos. Aunque es verdad que esto puede crear módulos excesivamente interdependientes (esto es bueno), también limita ciertas prácticas, como por ejemplo tener todos los métodos que leen una determninada estructura todos juntos en un package, si no se es cuidadoso.
La implementación de la herencia. Si pones una estructura A dentro de una estructura B, en la práctica, estás haciendo que B derive de A. De hecho, B podrá hacer uso de los métodos definidos para A. Por un lado, colocar la estructura A dentro de B parece indicar que tendrás que apañártelas tú mismo con la herencia, cuando es obvio que el compilador va a ofrecer cierto soporte automático del que, al principio, puedes no ser consciente. Personalmente, me gustaría una sintaxis del tipo type B struct: A o algo parecido, lo que ya sugiere que el compilador va a ofrecer un soporte de la herencia explícito.

¿Y tú? ¿Has probado Go?

Go... interface!

Baltasar García Perez-Schofield — Wed, 28 Oct 2026 09:23:22 +0000

Nos quedamos en la última entrega con una estructura que Animal hacía de tipo "base" del tipo Cat. El problema venía cuando queríamos crear un patrón factory method, ya que no podemos apuntar con un puntero a Animal a una estructura Cat.

func New() *Animal {
    return &Cat{}        // Error!
}

Lo cierto es que estamos acostumbrados a C++, de manera que una clase derivada no es más que los atributos de la clase base, y, a continuación, los atributos de la clase derivada. Incluso Glib, pese a utilizar C y no C++, utiliza este "truco" en el que la clase base está primero en la memoria con la clase derivada. Como el puntero a la clase base tiene asociado un tamaño, el de la propia clase base, aunque apunte a un objeto de la clase derivada, solo puede acceder a los atributos de la clase base.

Un ejemplo específico en C: si tenemos una estructura Cat en C, podemos tener como primer miembro una estructura base Animal, y apuntar con un puntero de esta clase base al registro de Cat, con lo que solo podemos acceder a los atributos de la clase Animal. Como decía, así es, muy básicamente, como funciona GObject sobre Glib.

#include <stdbool.h>
#include <string.h>
#include <stdio.h>


#define MaxName 80
#define MaxColor 25

typedef struct _Animal {
    char name[MaxName + 1];
    char color[MaxColor + 1];
} Animal;

typedef struct _Cat {
    Animal base;
    bool purrs;
} Cat;

int main()
{
    Cat c;

    strncpy( c.base.name, "Panchito", MaxName );
    strncpy( c.base.color, "White", MaxColor );
    c.purrs = true;

    Animal * a = (Animal *) &c;

    printf( "\n'%s' is a cat of '%s' color", c.base.name, c.base.color );
    printf( "\n'%s' is an animal of '%s' color", a->name, a->color );

    return 0;
}

La salida es una simulación de herencia, pero en C.

$ make cinh
cc     cinh.c   -o cinh
$ ./cinh

'Panchito' is a cat of 'White' color
'Panchito' is an animal of 'White' color

Así que, si tenemos el mismo caso en Go:

type Animal struct {
    name string
    color string
}

type Cat struct {
    Animal
    purrs bool
}

¿Es lo mismo? Bueno... hay algunas diferencias. En primer lugar, Animal en Cat no tiene por qué ser el primer miembro. No somos nosotros los que tenemos que "preparar" el mapa en memoria, sino que es el propio compilador quien lo hace. Además, no tenemos que hacer referencia a los miembros de Animal en Cat, sino que podemos hacerlo directamente.

Vale, pero ¿cómo podemos crear un method factory? Pues la respuesta son las interfaces. No es necesario indicar en una estructura que implementa cierta interfaz, sino que es el propio compilador el que comprueba si la estructura implementa la interfaz cuando es necesario.

En el siguiente ejemplo, tenemos otra vez al Animal y a Cat, y la función New() devuelve una u otra dependiendo de si ronronea (purrs) o no (es un ejemplo como otro cualquiera). La razón por la que ahora funciona es que en lugar de devolver una u otra estructura, ahora devolvemos una interfaz. La interfaz está definida justo al principio, y como todas las interfaces, se basa en los métodos que declara cada estructura. En el momento en el que se retorna Animal o Cat, el compilador comprueba si ambas estructuras cumplen la interfaz o no.

package main

import "fmt"

type AnimalLike interface {
    Name() string
    Color() string
    String() string
}

type Animal struct {
    name string
    color string
}

func (a *Animal) Name() string {
    return a.name
}

func (a *Animal) Color() string {
    return a.color
}

func (a* Animal) String() string {
    return fmt.Sprintf("'%s' is an animal of color '%s'", a.Name(), a.Color())
}

type Cat struct {
    Animal
    purrs bool
}

func (c *Cat) Purrs() bool {
    return c.purrs
}

func (c* Cat) String() string {
    purrs := ""

    if c.Purrs() {
    purrs = ", and purrs."
    }

    return fmt.Sprintf("'%s' is a cat of color '%s'%s", c.Name(), c.Color(), purrs)
}

func New(name, color string, purrs bool) AnimalLike {
    var toret AnimalLike

    if purrs {
    toret = &Cat{Animal: Animal{name: name, color: color}, purrs: true}
    } else {
    toret = &Animal{name: name, color: color}
    }

    return toret
}

func main() {
    fmt.Printf("\n%s", New("Panchito", "white", true))
    fmt.Printf("\n%s", New("Panchito", "white", false))
}

La salida es la esperada:

'Panchito' is a cat of color 'white', and purrs.
'Panchito' is an animal of color 'white'

Más o menos esta es una introducción muy somera a Go. En la siguiente entrega, veremos los errores que, a mi juicio, presenta.

Go! ...objects: structs.

Baltasar García Perez-Schofield — Fri, 23 Oct 2026 09:16:25 +0000

El lenguaje de programación Go, como vimos en la anterior entrega, se parece bastante a C, aunque con bastantes mejoras, en el sentido de evitar comportamientos indefinidos, por ejemplo. Más claro y más definido, podríamos decir.

De acuerdo, pero... al margen de programación procedural, ¿hay algún otro tipo de programación soportada por Go? ¿Concretamente, Go soporta programación orientada a objetos? Sí. Bueno, no. Más o menos. Es "algo" parecido.

Go no soporta las típicas construcciones a las que estamos acostumbrados: no existe la palabra clave class, no hay herencia como tal... De hecho, "solo" soporta estructuras, struct. Ah, pero las estructuras pueden tener métodos. Y mezclándolo con los módulos, podremos tener incluso algo más o menos parecido a constructores.

Bueno, suficientes rodeos, metámonos en el meollo.

package main
import "fmt"

type Animal struct {
    name string
    color string
    age int
}

func NewAnimal(n, c string, a int) *Animal {
    return &Animal{name: n, color: c, age: a}
}

func (a *Animal) Name() string {
    return a.name
}

func (a *Animal) Color() string {
    return a.color
}

func (a *Animal) Age() int {
    return a.age
}

func main() {
    cat := NewAnimal("Panchito", "white", 18)
    fmt.Printf("%s is %d years old.", cat.Name(), cat.Age())
}

La salida es la esperada: Panchito is 18 years old.

La estructura Animal tiene todos sus miembros en minúsculas; esto quiere decir que todos sus miembros son privados. Al crear métodos para devolver sus valores, pero no para cambiarlos, estamos creando en esencia atributos de solo lectura.

Podemos devolver sin temor un puntero a una estructura, como hacemos en NewAnimal(). Lo que estamos diciendo es que ese objeto se va a pasar por referencia, al fin y al cabo. Es importante insistir en que no estamos devolviendo un puntero al stack de la función.

En Go, no se distingue si estamos utilizando un puntero al objeto o un objeto mismo. Para acceder al mismo utilizaremos igualmente el punto ('.') como selector de acceso a los miembros, como por ejemplo, cat.Name().

La forma de crear métodos no es meterlos dentro de la estructura, sino crearlos a continuación de esta, con el receptor de la llamada colocado antes del nombre de la función. Nunca se utiliza this o self, sino alguna abreviatura del nombre de la estructura.

No existe como tal un equivalente al método toString(), pero sí que existe la interfaz Stringer, que espera que la estructura presente un método llamado String(). Como aparece a continuación:

func (a *Animal) String() string {
    return fmt.Sprintf("%s is %s and %d years old.", a.Name(), a.Color(), a.Age())
}

Ahora podemos cambiar la función main(), ya que print() ya espera que el objeto que se le pase tenga el método String().

func main() {
    cat := NewAnimal("Panchito", "white", 18)
    fmt.Print(cat)
}

La salida es la que esperábamos: Panchito is white and 18 years old.

La OOP tiene como características principales encapsulación, herencia y polimorfismo. La encapsulación, ya hemos visto que la presenta, al poder unir métodos y atributos en una estructura, y además con posibilidades de visibilidad público o privado (no existe nada parecido a protected).

Así que lo siguiente es comprobar si presenta herencia. No existe ninguna sintaxis específica para esto (como extends en Java), pero sí que podemos embeber una estructura A dentro de otra B... lo que hace que los métodos de A se promocionen como métodos también de B.

type Cat struct {
    Animal
    noise string
}

func NewCat(n, c string, a int, ns string) *Cat {
    return &Cat{Animal: *NewAnimal(n, c, a), noise: ns}
}

func (c *Cat) Noise() string {
    return c.noise
}

func main() {
    cat := NewCat("Panchito", "white", 18, "Purrr...")
    fmt.Print(cat)
    fmt.Printf("\n%s", cat.Noise())
}

Con la adición a nuestro programa de arriba, tenemos ahora un tipo más específico de animales, los gatos. Los gatos presentan todas las caracerísticas de los animales, más un ruido (el ronroneo). Como los métodos de Animal promocionan a Cat, la salida de Print() en el programa sigue siendo la misma: Panchito is white and 18 years old. Purrr..., solo que ahora añadimos una línea de texto más para la que llamamos a Cat.Noise().

Así que... sí que tenemos herencia. Pero... ¿tenemos polimorfismo? ¿Podemos llamar a un método foo() con la confianza de que se llamará a foo() del propio objeto? Resulta que sí. Si tenemos un método de mismo nombre en Animal que en Cat, el segundo oculta al primero.

func (c* Cat) String() string {
    return fmt.Sprintf("%s is %s and %d years old. Says: %s.", c.Name(), c.Color(), c.Age(), c.Noise())
}

func main() {
    cat := NewCat("Panchito", "white", 18, "Purrr...")
    fmt.Print(cat)
}

La salida es la esperada: Panchito is white and 18 years old. Says: Purrr....

Hay salvedades, por supuesto, con respecto a lo que estamos acostumbrados a lenguajes de programación como Java, o C#. No podemos tener un puntero a Animal apuntando a un objeto Cat.

func main() {
    var cat *Animal = NewCat("Panchito", "white", 18, "Purrr...")
    fmt.Print(cat)
}

Este programa no compila. La salida del compilador de Go es:

./prog.go:48:9: cannot use NewCat("Panchito", "white", 18, "Purrr...") (type *Cat) as type *Animal in assignment

Veremos cómo podemos solucionar esto en una futura entrega.

¿Y qué pasa contigo? ¿Te gusta Go? ¿Es para ti el lenguaje del futuro?

¿Utilizar IA? El vuelo del "Lady Be Good"

Baltasar García Perez-Schofield — Thu, 15 Oct 2026 09:13:54 +0000

El otro día, se me ocurrió que utilizar inteligencia artificial para programar, especialmente cuando estás empezando, tiene consecuencias muy similares al (único) vuelo del Lady Be Good. Al fin y al cabo, todo se reduce a lo que sucede cuando no entiendes lo que estás haciendo.

El Lady Be Good fue un bombardero B-24 Liberator que participó en la Segunda Guerra Mundial. Su tripulación estaba compuesta por un grupo bisoño, comandado por el teniente William Hatton. Sí, habían recibido el entrenamiento estándar, sabían pilotar el avión, y conocían, al menos, los rudimentos de la navegación.

El día 4 de abril de 1943, partieron de la base de Benina, entre Libia y Egipto, con la misión de bombardear Nápoles. No eran el único aparato, por lo que se sentían seguros ante la perspectiva de seguir a los otros 24 bombarderos tripulados por aviadores experimentados. Se crearon dos grupos, el primero despegó normalmente, pero del segundo, al desencadenarse una tormenta de arena, solo pudieron despegar cuatro, entre ellos, nuestro protagonista, aunque con algunos instrumentos dañados.

Al llegar a Nápoles soltaron sus bombas y regresaron. El Lady Be Good fue el último en dar la vuelta, y se quedó atrás del disperso grupo, sin contacto visual. Habían pasado más de cinco horas desde el despegue, y se hizo de noche.

El problema de pilotar de noche es que el desierto puede parecer mar, y el mar puede parecer desierto. Y eso si puedes apreciar algo, puesto que no sería la primera vez que el piloto pierde la conciencia situacional y acaba precipitándose al suelo pensando que está subiendo.

A las 23:10, todos los aparatos habían aterrizado. Uno de ellos en Malta, por falta de combustible. Todos habían regresado... menos el Lady Be Good.

A las 00:10, se recibió en una estación de control de tierra una transmisión del Lady Be Good. Pedía ayuda para orientarse, debido a la inexperiencia de su navegador. La estación de tierra podía decirles en qué rumbo volaban, pero no su posición, ni siquiera si se estaban alejando o acercando. La estación les indicó el rumbo, que era el que estaba siguiendo la nave, por lo que supusieron que fuertes vientos en contra habían ralentizado al aparato.

No era así. Habían pasado hacía tiempo la base de la que habían despegado, pero la noche les impedía apreciar visualmente que estaban sobre el desierto libio. Y siguieron adentrándose en él.

Una hora más tarde, habían perdido el contacto por radio, y se dieron cuenta de que estaban al sur de la base, aunque no a cuánta distancia.

La expedición de rescate, que solo cubrió el extremo sur del mediterráneo y la costa, no encontró nada. Se dió al avión y sus tripulantes como desaparecidos. Cuando los aliados tomaron Nápoles, revisaron los registros de prisioneros, y, al no encontrar sus nombres, asumieron que habían caído al mar y fallecido.

El problema, sin duda, fue delegar la comprensión y seguimiento de la misión en otros, lo que impidió que ellos mismos fueran conscientes de lo que necesitaban hacer.

Vale, pero... ¿qué pasó con el Lady Be Good?

Los restos del aparato se encontraron por casualidad, cuando en 1958 una avioneta buscaba a vista de pájaro lugares adecuados para prospección petrolífera. El suceso fue comunicado, y en 1960 el ejército del aire de los Estados Unidos lanzó una expedición de rescate. Lo que descubrieron fue aterrador e increíblemente emocionante, a partes iguales.

El avión en sí había aterrizado por sí mismo al quedarse sin combustible. Al tomar tierra, se había partido en dos, pero exceptuando ese desperfecto mayor, se encontraron intactos los aparatos del avión, como las ametralladores, y su carga, que incluía varios barriles de agua potable y raciones de comida. Los tripulantes no estaban allí.

Nos habíamos quedado con los tripulantes dándose cuenta de que sobrevolaban el desierto, en alguna posición al sur de su base, y con el combustible a punto de acabarse.

Los aviadores saltaron en paracaídas sobre el desierto, consiguiendo reunirse todos ellos... menos uno, que falleció al no desplegarse correctamente su paracaídas. Se encontraban a unos 27 km. al norte de donde finalmente fue a reposar el aparato. Contaban con una cantimplora de agua por persona y unas pequeñas raciones de comida de supervivencia. Su situación era crítica, y eran conscientes de que no les encontrarían.

Resolvieron comenzar a caminar hacia el norte, sin saber que estaban a más de 500 km. de distancia de la base. Era obvio que no iban a conseguir llegar. Y claro, aquí podríamos empezar a plantearnos preguntas del tipo: ¿y sí...?

¿Y si se hubieran quedado en el avión, con su suministro de agua potable? ¿Y si hubieran encontrado a su compañero muerto, a aproximadamente un kilómetro al norte, con su botella de agua y raciones intactas? ¿Y si hubieran caminado hacia el sur, hacia el oasis de Wadi Zighen, situado a unos 100 km.? ¿Y si...?

En realidad, el curso de acción más lógico es el que tomaron. Quedarse en el avión no garantiza sobrevivir, y caminar hacia el sur no tiene sentido si no sabes exactamente dónde estás. Y la tripulación del Lady Be Good solo tenía una idea de su situación a muy grandes rasgos.

Aquí es donde empieza la parte épica. Se supone que un humano puede aguantar tres días sin beber. Nuestros protagonistas caminaron casi veinte kilómetros diarios durante más de cinco días con unas botellas de agua y raciones de comida claramente insuficientes. Iban dejando marcadores hechos con los restos de sus paracaídas, pensando que quizás una expedición de rescate pudiese encontrar su avión.

Al segundo día, encontraron rodadas de camiones que se dirigían hacia el noroeste, lo que supuso una importante inyección de moral. Resolvieron seguirlas. No sabían, claro, que habían sido dejadas más de un año antes.

Al quinto día de marcha, con todos los recursos agotados, sedientos, hambrientos, y casi ciegos por el resplandor del reflejo del sol en la arena, "solo" pudieron caminar 16 km. La mayoría se queda atrás a esperar una posible ayuda. Tres de ellos (los sargentos Moore, Ripslinger y Shelley), resolvieron continuar caminando. En este punto se habían alejado unos 116 km. del avión, una hazaña épica, aunque desgraciadamente, inútil.

El grupo "acampado" (cubriéndose con los restos de los paracaídas), con tan solo unas gotas de agua para mojar la lengua, aún sobrevivió tres días más. Al mismo tiempo, el sargento Ripslinger moría a unos 44 km., dejando escrito en su diario que seguían intentando salir del mar de dunas de arena. Al sargento Shelley se le encontró a otros 16 km al noroeste del de Ripslinger, lo que representa unos increíbles 176 km. de caminata en total.

El cuerpo de Moore nunca fue encontrado oficialmente. Cuando aún se creía que el Lady Be Good se había caído al mar, se encontró un esqueleto por la zona, pero fue enterrado en la arena, y no se investigó más.

¡Go, Go, Go! ¡Es golang!

Baltasar García Perez-Schofield — Fri, 09 Oct 2026 08:37:51 +0000

El lenguaje de programación Go se ha alzado como el dominante entre los lenguajes de programación actuales para servidores. ¿Por qué? Porque genera un ejecutable. Un solo ejecutable. Solo un archivo. La instalación es trivial: solo copia el archivo en el servidor, y se acabó.

Desde el principio, los creadores de Go se decidieron a solucionar los típicos problemas presentes en C y C++. El primero de todos, era la velocidad de compilación. El segundo ya lo hemos visto: la necesidad de mantener una infraestructura de DLL con las versiones correctas, frente a la decisión tomada de generar un ejecutable estático, es decir, que lo incluye todo, sin dependencias. El tercero, solucionar las ambigüedades presentes en C, además de las posibilidades de dispararte en el pie gracias a C++.

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." Bjarne Stroustrup

"Con C es fácil dispararte en tu propio pie; C++ lo hace más difícil, pero cuando lo haces, te has volado la pierna entera." Bjarne Stroustrup

Con Go, no existe un preprocesador. La instrucción import acepta el nombre de un módulo entre comillas. Por ejemplo, Printf() está en el módulo fmt. ¿Printf con mayúscula? Pues sí, porque los símbolos públicos de un módulo llevan la inicial en mayúscula. Y siempre se antepone el nombre del módulo, separado por un punto del identificador. Las funciones se marcan con la palabra clave func. No hay void, simplemente no se pone nada.

package main

import "fmt"

func main() {
    fmt.Printf("Hello, world!")
}

Las variables locales se marcan con var (a no ser que su tipo se deduzca de la inicialización, en ese caso se omite var y se utiliza ':='). Los tipos siempre se colocan a la derecha del identificador... es práctico imaginarse que hay un ':' tras el nombre del identificador.

func distanciaPuntos(x1, y1, x2, y2 float64) float64 {
    distX := x1 - x2
    distY := y1 - y2

    distX *= distX
    distY *= distY

    return math.Sqrt(distX + distY)
}

Los tipos de números reales son dos: float32 y float64. La función Sqrt() se encuentra en el módulo math.

Y no, no se ponen puntos y coma (';'), a no ser que quieras introducir dos instrucciones en la misma línea. Las llaves de apertura ('{'), siempre se abren en la última posición de la instrucción que genera el bloque de código. El cierre de llave ('}'), siempre va en una línea aparte.

La palabra package le da su nombre al módulo; aquel que tiene la función main() siempre es el módulo main.

$ go run hello.go
Hello, world!

Y hay que reconocer que impresiona la velocidad de compilación de Go. La apariencia es que el programa se ejecuta inmediatamante. Pero.. ¿qué ha generado?

$ go build hello.go
$ ls
hello hello.go
$ ls -l
2424611 oct  9 09:29 hello
     65 oct  9 09:27 hello.go

Efectivamente, se trata de un ejecutable estático, o también conocido como fat binary. Y es que el programa tiene un tamaño de casi 2.5 Mb.

El programa equivalente en C++ es el ya conocido.

#include <iostream>

using namespace std;

int main()
{
    cout << "Hello, world!" << endl;
}

Generar el ejecutable es una cuestión ya conocida.

$ g++ hello.cpp
$ ./a.out
Hello, world!
$ ls
a.out  hello  hello.cpp  hello.go
$ ls -l
   16288 oct  9 09:32 a.out
 2424611 oct  9 09:29 hello
      94 oct  9 09:32 hello.cpp
      65 oct  9 09:27 hello.go

Parece que no hay color, ¿verdad? El ejecutable de C++ solo ocupa 16 Kb. Pero espera. C++ no genera ejecutables estáticos por defecto, sino que utiliza la DLL de la librería estándar de C++.

$ ls -l /usr/lib/libstdc++*
     319 ago 10 22:04 /usr/lib/libstdc++.modules.json
      19 ago 10 22:04 /usr/lib/libstdc++.so -> libstdc++.so.6.0.36
      19 ago 10 22:04 /usr/lib/libstdc++.so.6 -> libstdc++.so.6.0.36
 2939928 ago 10 22:04 /usr/lib/libstdc++.so.6.0.36

¡Pues casi 3 Mb! Vamos a generar el ejecutable estático, en cualquier caso.

$ g++ --static hello.cpp
$ ls -l
total 4836
 2517752 oct  9 09:40 a.out
 2424611 oct  9 09:29 hello
      94 oct  9 09:32 hello.cpp
      65 oct  9 09:27 hello.go

Ya vemos que no hay mucha diferencia en realidad.

Pongamos un ejemplo práctico. Un ejercicio estrella es... la sucesión de Fibonacci. Pero vamos a crearlo como lo haríamos con Python, generando un array (lo más parecido a una lista en Go). Efectivamente, Go permite el manejo de arrays dinámicos de forma sencilla. Si queremos crear un literal de array, solo tenemos que utilizar las llaves tras el tipo... ¡los corchetes van a la izquierda! A continuación, vemos un array con el inicio de la sucesión de Fibonacci. Además, append() permite añadir un elemento nuevo al array de forma sencilla.

[]uint64{1, 1, 2, 3, 5, 8}

Hay varios tipos predefinidos, varios de ellos son los enteros de diferentes tamaños. int8 es un entero de 8 bits, aceptando valores de -128 a 127. uint8 es un entero sin signo de 8 bits (o 1 byte), y por eso tiene un alias, byte, ya que acepta valores de 0 a 255. Tenemos enteros, y enteros sin signo, de 16 bits (2 bytes, -32768 a 32767), 32 bits (4 bytes, de -2 mil millones a 2 mil millones aprox.), y 64 bits (8 bytes, una locura). El tipo int equivale al entero con signo del mismo tamaño que el tamaño de palabra del sistema, típicamente int32, o int64.

El tipo escogido es uint64, pues la sucesión de Fibonacci no tiene negativos, y crece muy rápidamente.

El bucle for puede sorprendernos; de hecho es el único bucle disponible, for <condición> es el bucle while. El típico bucle for de C es prácticamente el mismo. Eso sí, al igual que con if, la condición no va entre paréntesis.

package main

import "fmt"

func fibo(n uint64) []uint64 {
    var fibo []uint64 = []uint64{1, 1, 2, 3, 5, 8}
    var lenFibo uint64 = uint64(len(fibo))

    if n <= lenFibo {
        return fibo[:n]
    }

    var i uint64 = lenFibo
    toret := fibo
    for ; i < n; i++ {
        toret = append(toret, toret[i - 1] + toret[i - 2])
    }

    return toret
}

func main() {
    fmt.Printf("Fibo\n\n")

    var i uint64 = 0
    for ; i < 20; i++ {
        fmt.Printf("Fibo %03d: %v\n", i, fibo(i))
    }
}

La salida del programa es:

❯ go run fibo.go
Fibo

Fibo 000: []
Fibo 001: [1]
Fibo 002: [1 1]
Fibo 003: [1 1 2]
Fibo 004: [1 1 2 3]
Fibo 005: [1 1 2 3 5]
Fibo 006: [1 1 2 3 5 8]
Fibo 007: [1 1 2 3 5 8 13]
Fibo 008: [1 1 2 3 5 8 13 21]
Fibo 009: [1 1 2 3 5 8 13 21 34]
Fibo 010: [1 1 2 3 5 8 13 21 34 55]
Fibo 011: [1 1 2 3 5 8 13 21 34 55 89]
Fibo 012: [1 1 2 3 5 8 13 21 34 55 89 144]
Fibo 013: [1 1 2 3 5 8 13 21 34 55 89 144 233]
Fibo 014: [1 1 2 3 5 8 13 21 34 55 89 144 233 377]
Fibo 015: [1 1 2 3 5 8 13 21 34 55 89 144 233 377 610]
Fibo 016: [1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987]
Fibo 017: [1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597]
Fibo 018: [1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584]
Fibo 019: [1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181]
Fibo 020: [1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765]

La idea con la que me quedo de Go es que es... muy práctico. Esto es normal, debido al interés de sus diseñadores en resolver problemas con los que se enfrentaban todos los días. Concretamente, estaban hartos de tener que esperar y esperar incluso más de 15 minutos para que sus programas compilasen. Y de hecho, fue en esas esperas cuando empezaron a diseñar Go.

El uso de módulos por un lado, y estructuras con interfaces por el otro, permite un cierto tipo de programación orientada a objetos, aunque se construya de una manera mucho más primitiva. Pero eso ya lo veremos en la siguiente entrega.

Cosas que no sabías que no sabías: los decimales y tú.

Baltasar García Perez-Schofield — Wed, 07 Oct 2026 15:05:19 +0000

Ya escribí sobre esto anteriormente, en concreto, decía en ¿Dónde está mi dinero?

La razón tiene que ver con el estándar IEEE 754. Este estándar se publicó en 1985 (aunque se ha desarrollado y revisado a partir de esa fecha). Los números reales son un problema al fin y al cabo. Los números posibles entre 0.1 y 0.2 y entre 0.01 y 0.02 son los mismos: infinitos. En una representación digital, el infinito es una imposibilidad.

Efectivamente, un soporte digital tiene problemas para representar todo aquello que esté relacionado con el infinito. Igual que un círculo, que tiene infinitos lados. ¿Te has dado cuenta de cómo en los videojuegos, nada llega a ser verdaderamente redondo?

Es fascinante. ¿Podemos llegar a solventar, de verdad, este problema?

Es una pregunta interesante. Ya sabemos que la respuesta es no, aunque hay varias formas de paliarlo. Al fin y al cabo, si un sistema, aunque utilice un soporte digital, tiene la suficiente precisión, es posible que sea indistinguible para el ser humano.

Efectivamente, C# tiene soporte para números con decimales que mantienen un buen soporte de precisión. Se trata del tipo decimal. Utilizando este tipo, se emplean muchos más bits para representar la mantisa, y solo unos pocos para representar el exponente.

Evidentemente esto ayuda, pero no es una solución definitiva. Por ejemplo, en el siguiente programa en Python:

x = 0.0

for i in range(100):   
    if (i != 0
    and i % 10 == 0
    and x % 10 != 0):
        print(f"ERROR {i} != {x}")
        break

    x += 0.1

...avanzamos hasta que i es divisible por 10 (es decir, cada 10 elementos), y comprobamos si el resto de la división de x con 10 es 0. Si esto no se cumple, hemos encontrado una imprecisión. ¿Será un número muy elevado? ¡Solo estamos empleando incrementos de 0.1!

Pues el resultado es sorprendente:

$ python precision.py
ERROR 10 != 0.9999999999999999

Ya arrastramos un error significativo después de... ¡tan solo 10 incrementos de 0.1 en 0.1!

Esto me hizo pensar... ¿era todo distinto en los tiempos del Speccy? Pues resulta que... no.

10 let x = 0
20 for i = 0 to 100
30     print x: pause 0
40     let x = x + 0.1
50 next i

La salida es... ¿la esperada?

0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
1.1
1.2
1.3
1.4
...

Al encontrarme con esto, me puse a buscar las razones que pudieran explicar este comportamiento. Resulta que Sinclair Basic almacena las variables numéricas en 5 bytes, sin importar demasiado si son enteras o decimales. Si son enteras, los bits dedicados al exponente estarán vacíos, aspecto del que se aprovechan varias rutinas matemáticas en ROM. En cualquier caso, los números en Sinclair Basic no se "desbordan", sino que pasan a representarse como números en coma flotante.

10 let x = 1
20 for i = 0 to 100
30     print x: pause 0
40     let x = x * 100
50 next i

Por ejemplo, ante un programa como el anterior, la salida pasa a coma flotante a partir de un cierto valor, hasta que admite que no puede representar valores tan grandes.

Esto es sencillo de conseguir en el Speccy, porque los números decimales y los números enteros comparten representación: 5 bytes con 0 como byte para el exponente, y un valor en el exponente en caso contrario. Nótese que 10 e+38 no deja de ser un número muy grande... ¡un 1 seguido de 38 ceros!

Pero volvamos al PC moderno... ¿podemos conseguir representar estos valores monetarios de forma exacta? Claro que podemos. Ya vimos que la trampa siempre proviene de varias operaciones matemáticas acumuladas. En el artículo enlazado, se guardaba el valor monetario como número entero multiplicado por cien y solo cuando se pedía se dividía entre cien.

También podemos guardar valor entero y céntimos en una estructura, como se puede ver a continuación.



public struct Money {
    public required int Value { get; init; }
    public required byte Cents { get; init; }

    public override string ToString()
    {
        return $"{this.Value},{this.Cents:00}";
    }

    public static explicit operator double(Money m)
    {
        return (double) ( (decimal) m );
    }

    public static explicit operator decimal(Money m)
    {
        return ( (decimal) m.Value ) + ( (decimal) m.Cents / 100 );
    }

    public static explicit operator int(Money m)
    {
        int toret = m.Value;

        if ( m.Cents >= 50 ) {
            toret += 1;
        }

        return toret;
    }

    public static Money From(int x)
    {
        return new Money{Value=x, Cents=0};
    }

    public static Money From(decimal x)
    {
        return new Money{
                    Value=(int) x,
                    Cents=(byte) ( ((int) ( x * 100) ) % 100 )};
    }

    public static Money From(double x)
    {
        return new Money{
                    Value=(int) x,
                    Cents=(byte) ( ((int) ( x * 100) ) % 100 )};
    }    
}

Los lenguajes de programación intentan hacer el manejo de los datos numéricos tan intuitivo, que a veces nos olvidamos cómo se está representando realmente "por debajo".

C# ¿Qué me he perdido?

Baltasar García Perez-Schofield — Fri, 25 Sep 2026 18:25:23 +0000

C# es un lenguaje en constante evolución. Empiezan a escucharse voces que demandan un periodo de estabilidad ante tanto cambio, pero está claro que la última palabra la tiene Microsoft.

Con la versión 11 de .NET a punto de caramelo, podemos relacionar los últimos cambios más reseñables a C#. Los mejores cambios son los que no se ven: los ingenieros de Microsoft están optimizando agresivamente el código generado por el compilador, de manera que sea tan rápido como sea posible.

Para la mayor parte del código aquí, necesitamos instalar la .NET 11.0-rc1, configurar el proyecto para usarla, y activar preview. Un ejemplo de proyecto aparece a continuación.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net11.0</TargetFramework>
    <RootNamespace>Matrix</RootNamespace>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <Preview>enable</Preview>
  </PropertyGroup>

</Project>

Vale, pero... ¿cuál es la versión de C# que se corresponde con estas versiones de .NET? Es una buena pregunta, porque no hay una respuesta sencilla. Es imposible, de hecho, obtenerla, mediante la herramienta dotnet.

.NET	.NET 9	.NET 10	.NET 11
C#	C# 13	C# 14	C# 15

Así que, como decía Jacobo, vamos por partes.

Novedades en C

C# 13: índices negativos

Ahora es posible acceder a elementos desde un índice negativo. Este índice negativo se cuenta desde el último elemento, de manera que -1 se corresponde con el último, -2 el antepenúltimo, etc. Solo es necesario tener en cuenta que, en lugar de utilizar, por ejemplo, -1, la sintaxis exige utilizar ^1.

var buffer = new int[10];

buffer[^1]  = 11;
buffer[^2]  = 12;
buffer[^3]  = 13;
buffer[^4]  = 14;
buffer[^5]  = 15;
buffer[^6]  = 16;
buffer[^7]  = 17;
buffer[^8]  = 18;
buffer[^9]  = 19;
buffer[^10] = 20;

foreach (var x in buffer) {
    Console.WriteLine(x);
}

La salida es la que esperamos:

C# 14: La palabra clave field

Ya escribí sobre fielden C# recientemente. De la misma forma en la que disponemos de value, para representar el valor asignado en la propiedad set, tenemos ahora field para representar al atributo sintético.

public class Punto {
    public int X { get; set {
        if ( value < 0 ) {
            throw new ArgumentException( "value < 0" );
        }
        ?X? = value;
    }}
    // ...
}

En el código de arriba, comprobamos si el valor que va a ser asignado en el set (llamado value), de la propiedad X es o no negativo. En caso de ser negativo, se lanza una excepción. El código es erróneo porque se nombra ?x?para representar el campo a asignar. En este punto, tendríamos que crear un atributo real a la clase.

public class Punto {
    public int X { get; set {
        if ( value < 0 ) {
            throw new ArgumentException( "value < 0" );
        }
        this.x = value;
    }}

    // ...
    private int x;
}

¡Pero ahora ya no es necesario! Volviendo al código de más arriba, podemos escribir lo siguiente.

public class Punto {
    public int X { get; set {
        if ( value < 0 ) {
            throw new ArgumentException( "value < 0" );
        }
        field = value;
    }}

    // ...
}

C# 14: Asignación condicional

Hasta ahora, era posible utilizar el operador ? como parte de una expresión. En caso de que la referencia a la izquierda de ? sea null, entonces se devuelve directamente null. En otro caso, se devuelve el resultado de la expresión como tal.

Por ejemplo, person?.Name devuelve el nombre del objeto de la clase Person referenciada por person. Si en cambio, person es null, entonces se devuelve null.

Pero es que ahora, además, es posible utilizarla para asignar (o no), un valor, si la referencia a la izquierda de ? no es null.

var people = new List<Person>();

// ...

var person = people.FirstOrDefault( p => p.age < 18 );

Console.WriteLine( person?.Name );           // Already supported
person?.Name = "The One";                    // New!

C# 15: Jerarquías cerradas

Es posible crear una jerarquía que se sabe que, en el momento de la compilación, va a tener un número determinado de clases derivadas.

public closed class Person {
    public required string Name { get; init; }
}

public class Employee: Person {
    public required double Salary { get; init; }
}

public class Retired: Person {
    public required double Pension { get; init; }
}

En la clase Person añadimos el modificador closed para indicar que esta clase solo va a tener las clases derivadas que indiquemos; ninguna más.

Esto permite hacer un tipo de switch que se base en los tipos derivados de los objetos Person.

public closed class Person {
    public required string Name { get; init; }
    public static string IncomeLabel(Person p) => p switch
    {
        Employee => "Salary",
        Retired => "Pension"
    }
}

La ventaja es que en este switch el compilador puede comprobar que hemos tratado todos los posibles casos como clases derivadas tiene Persona.

A mi se me ocurre que es una versión super-vitaminada de enumerados, pero claro, con un cierto coste, pues involucra la creación de objetos.

C# 15: Uniones

Ya escribí sobre cómo C# soporta uniones en C#, aunque no nos quede demasiado claro para qué exactamente.

C# 15: break y continue etiquetados

Esta característica está soportada en Java desde el primer día, pero por algún motivo no ha conseguido llegar hasta C# hasta ahora.

La idea es la posibilidad de romper un bucle (o saltar una vuelta de bucle), desde un bucle anidado en el primero.

var m = new Matrix<int>( 10, 10 );
var rnd = new Random();

// Fill
for (int i = 0; i < m.Rows; ++i) {
    for(int j = 0; j < m.Cols; ++j) {
        m.Set( i, j, rnd.Next( 100 ) );
    }
}

Find: for (int i = 0; i < m.Rows; ++i) {
    for(int j = 0; j < m.Cols; ++j) {
        if ( m.Get( i, j ) == 50 ) {
            Console.WriteLine( $"Encontrado en ({i}, {j})" );
            break Find;
        }
    }
}


public class Matrix<T> {
    public Matrix(int rows, int cols)
    {
        this.Rows = rows;
        this.Cols = cols;
        this.m = new T[cols, rows];
    }

    public int Rows { get; set; }
    public int Cols { get; set; }
    public T[,] Data => (T[,]) this.m.Clone();
    public T Get(int r, int c) => this.m[r, c];
    public void Set(int r, int c, T x) => this.m[r, c] = x;

    private T[,] m;
}

En el código anterior vemos una clase Matrix, que primero se rellena mediante un doble bucle con valores aleatorios, y después se recorre, de nuevo con un doble-bucle, para buscar el valor 50. En caso de encontrarse, no es suficiente con break, puesto que solo romperíamos el bucle anidado. Pero con la versión de break etiquetada, podemos indicar cuál de los dos bucles queremos romper.

¿Y tú, cómo llevas tanto cambio y tanto avance en C#?

Cosas que no sabías que no sabías: tamaño de un struct

Baltasar García Perez-Schofield — Thu, 17 Sep 2026 11:56:42 +0000

Esta es la primera entrega de una serie en la que exploraremos cuestiones que se "escapan" del alto nivel de los lenguajes de programación hacia el hardware por debajo de nosotros.

¿Cuánto ocupa una struct, un registro? Pues... depende. Veamos a continuación un ejemplo en C.

    typedef struct _Deportista {
        unsigned int num;
        unsigned int total_seconds;
        bool finished;
    } Deportista;

Vale, un registro que identifica a un deportista con un número, un tiempo (en segundos), y un booleano que determina si terminó la carrera o no.

¿Cuál es el tamaño de este registro? De nuevo... depende. Podemos especificar un poco más:

Ancho de palabra del ordenador.
Compilador utilizado.

El ancho de palabra del ordenador nos permite saber dos cosas: primero, cuántos bytes ocupará un unsigned int, un entero sin signo. En lenguajes de programación cercanos al hardware, es muy común que el tipo int coincida con el ancho de palabra de la máquina. Si nuestro ordenador es de 32 bits, es decir, 4 bytes, el tamaño en memoria de un int será también de 4 bytes. Si nuestra máquina es de 64 bits, es decir, 8 bytes, el tamaño de un int será... bueno, pues depende del compilador. Puede optar por soportar enteros de 64 o 32 bits, aunque el puntero siempre sea de 64 bits. Por ejemplo, gcc y la mayoría de compiladores para x64 optan por seguir utilizando 4 bytes para los enteros.

Si asumimos una máquina de 32 bits, entonces tenemos 4 + 4 + 1, es decir, 9 bytes ocupados por el registro. Si asumimos una máquina de 64 bits, que utilice 32 bits para los enteros, tendremos el mismo resultado. Si asumimos una máquina x64 que utilice 8 bytes para los enteros, tendremos 8 + 8 + 1, es decir, 17 bytes. ¿No?

Pues lo más probable (y razonable), es que no sea así. El compilador tratará de optimizar el tamaño del registro para soportar el acceso a memoria en palabras, y con una alineación correcta.

Las siguientes asunciones y descripciones de funcionamiento se hacen todas eligiendo simplificar.

El bus de datos del ordenador lee o escribe de la memoria siempre con el mismo tamaño mínimo: el ancho de palabra de la arquitectura. Una máquina de 32 bits siempre lee o escribe de 32 en 32 bits, es decir, 4 bytes. Si por poner un ejemplo, lo que queremos son los 2 bytes intermedios, le aplicará posteriormente la máscara 0x00FFFF00 para obtener el resultado que le hemos pedido. Este es el acceso a memoria de palabra en palabra.

En nuestra estructura, los dos primeros miembros están alineados. Son dos accesos, uno por palabra. Supongamos por un momento la misma máquina de 32 bits, que el compilador reserva el tamaño de la estructura exacta, es decir, 9 bytes, y que tenemos un vector de dos deportistas, el número 1, que tardó 10 segundos, y el número 2, que tardó 9. Leemos el primer miembro del primer registro, y obtenemos 0x01000000, para leer el segundo miembro del primer registro, obteniendo 0x0A000000. Ahora leemos el tercer miembro, que es un booleano que ocupa 1 bytes, con el valor 1. Esto sería 0x01. Pero el ordenador no lee de byte en byte, sino de palabra en palabra. Así que lee 0x01020000. Esto es el byte de haber terminado la carrera del primer deportista, más los tres primeros bytes del número del segundo deportista. El ordenador aplica la máscara 0xFF000000, y nos devuelve 0x01. Ahora leemos al segundo miembro. Es la misma palabra de antes, 0x01020000, pero ahora aplicando la máscara 0x00FFFFFF. Pero esto no llega, nos falta un byte por leer, así que leemos la siguiente palabra y le aplicams la máscara 0xFF000000. Tendremos que desplazar los bits del primer valor hacia la izquierda, desplazar los bits del segundo valor hacia la derecha, y hacer un OR. ¡Cada miembro del segundo deportista implica lectura de dos palabras, desplazamientos de bits en los registros y sumas! Esto es así porque el registro no está alineado en memoria.

Ahora supongamos que el registro no ocupa 9 bytes (4 + 4 + 1), sino 12 bytes (4 + 4 + 4). Es decir, "malgastamos" 4 bytes en el booleano, solo para que el registro esté alineado en memoria. Así, la lectura de cada deportista se puede hacer mediante tres accesos simples a memoria, aunque los tres últimos bytes en realidad no se empleen, y estén siempre a cero. Lo que permite este "desperdicio" es que la velocidad se incremente enormemente. A este desperdicio se le denomina padding. Y el padding exacto depende de cada compilador, no está estandarizado.

El primer deportista se lee mediante dos accesos simples a memoria. El booleano se obtiene mediante un acceso simple y un enmascaramiento de 0xFF000000. El segundo deportista se lee mediante dos accesos simples a memoria, pues ya no hay desalineación, más un acceso simple con un enmascaramiento y así sucesivamente.

¡Ya sé! Puedo hacer esto:

    typedef struct _Deportista {
        unsigned int num;
        unsigned int total_seconds;
        bool finished: 1;
    } Deportista;

Le estamos diciendo que utilice un solo bit para almacenar el booleano. Genial, pero nada ha cambiado en realidad. Solo la operación de máscara. Si cambiara algo, volveríamos al problema de la desalineación en memoria.

Lo que sí podemos hacer es codificar con el acceso a memoria, y la alineación, en la cabeza. Por ejemplo:

    typedef struct _Deportista {
        unsigned int num;
        bool finished;
        unsigned int total_seconds;
        unsigned short int num_penalties;
    } Deportista;

Esta estructura ocupa 4 + 4 + 4 + 4 = 16 bytes, a pesar de que en principio el campo finished solo ocupa 1 byte, y también que con el número de penalizaciones num_penalties, escogido como un entero corto sin signo, en nuestra arquitectura imaginaria es de solo 16 bits. Pero que por cuestiones de alineación en realidad, no conseguimos ahorrar nada; el compilador creará padding tras finished y tras num_penalties.

La cosa cambia si reordenamos los miembros de la estructura:

    typedef struct _Deportista {
        unsigned int num;
        bool finished;
        unsigned short int num_penalties;
        unsigned int total_seconds;
    } Deportista;

Ahora, siguiendo los cálculos realizados anteriormente, nuestra estructura ocupa 4 + 4 + 4, es decir, 12 bytes. El compilador solo introducirá un byte de padding tras num_penalites. Tras el segundo acceso a memoria, finished se servirá aplicando la máscara 0xFF000000 al valor obtenido, mientras que num_penalites se obtendrá del mismo valor aplicando la máscara 0x00FFFF00.

Caso de éxito de ingeniería del software: los toolkits gráficos

Baltasar García Perez-Schofield — Thu, 10 Sep 2026 08:51:33 +0000

Decíamos en la anterior entrega de esta serie, que un caso que se suele dar a conocer como de éxito es el de los toolkits gráficos. En parte es cierto, hay muchas aplicaciones que utilizan este tipo de módulos. Pero claro, en realidad encierra lo que yo entiendo es un fracaso: solo se puede considerar que aquellas aplicaciones que utilicen ese toolkit específico están construidas sobre esos módulos.

Es decir, hay muchas aplicaciones que están construidas sobre, por ejemplo, Win32, Gtk, Qt, o wxWidgets, comparten todas el mismo módulo base para el dibujo de la interfaz gráfica, algo de lo que se abstraen completamente.

Pero una vez que una app se construye sobre uno de estos toolkits, a no ser que esté muy bien diseñada, va a estar atada a él. Y aún así, un port a otro toolkit tomará un considerable esfuerzo.

La pregunta entonces es: ¿realmente son tan diferentes los estos módulos de interfaz gráfica como para requerir código totalmente distinto?

Vamos a ver cómo podemos crear una pequeña interfaz gráfica para una app en C#, con la desaparecida (excepto para Windows) Windows.Forms.

var panel = new Panel{ Dock = DockStyle.Fill };
var btTop = new Button{ Text = "Top", Dock = DockStyle.Top };
var btBottom = new Button{ Text = "Bottom", Dock = DockStyle.Bottom };
var btLeft = new Button{ Text = "Left", Dock = DockStyle.Left };
var btRight = new Button{ Text = "Right", Dock = DockStyle.Right };
var btCenter = new Button{ Text = "Center", Dock = DockStyle.Center };

panel.Controls.Add( btTop );
panel.Controls.Add( btBottom );
panel.Controls.Add( btLeft );
panel.Controls.Add( btRight );
panel.Controls.Add( btCenter );

Y ahora, otra en Java, utilizando Swing:

var panel = new JPanel();
panel.setLayout( new BorderLayout() );

var btTop = new JButton( "Top" );
var btBottom = new JButton( "Bottom" );
var btRight = new JButton( "Left" );
var btLeft = new JButton( "Right" );
var btCenter = new JButton( "Center" );

panel.add( btTop, BorderLayout.NORTH );
panel.add( btBottom, BorderLayout.SOUTH );
panel.add( btRight, BorderLayout.EAST );
panel.add( btLeft, BorderLayout.WEST );
panel.add( btCenter, BorderLayout.CENTER );

¿Cómo? ¿Que esos son toolkits muy antiguos? Vale, veamos Avalonia para C#:

var btCenter = new Button{ Content = "Center" };
var panel = new DockPanel{ LastChildFill = true };
var btTop = new Button{ Content = "Top" };
var btBottom = new Button{ Content = "Bottom" };
var btLeft = new Button{ Content = "Left" };
var btRight = new Button{ Content = "Right" };

DockPanel.SetDock( btTop, Dock.Top );
DockPanel.SetDock( btBottom, Dock.Bottom );
DockPanel.SetDock( btLeft, Dock.Left );
DockPanel.SetDock( btRight, Dock.Right );

panel.Children.Add( btTop );
panel.Children.Add( btBottom );
panel.Children.Add( btLeft );
panel.Children.Add( btRight );
panel.Children.Add( btCenter );

Esta no es la única forma de disponer controles gráficos en una app. También se pueden crear paneles unos dentro de otros, en vertical u horizontal, o utilizar una disposición de cuadrícula (grid). Todas esas posibilidades están disponibles en todos los toolkits gráficos... y sin embargo, todas ellas se llaman de forma total o ligeramente distinta.

Y es que el problema es ese. Nadie se preocupa por una estandarización o compatibilidad. Cuando Google desarrolló Android, ya existían numerosos toolkits gráficos disponibles, entre ellos algunos con tanta solvencia como Qt, por poner un ejemplo. Y sin embargo, resolvieron crear el suyo propio. Desde cero. Soportando las mismas características. Pero, claro está, con nombres distintos. Y construcciones ligeramente distintas.

Uno de los consejos que se da para desarrolladores es: no reinventes la rueda. Excepto que lo estés haciendo para aprender, claro. Y sin embargo, cada vez que una nueva plataforma (cualquiera), soporta una vista gráfica, acaba desarrollando un nuevo toolkit desde cero. Con nombres total o ligeramente distintos, pero soportando exactamente las mismas funcionalidades.

No puedo dejar de mencionar específicamente a uno de los toolkits más odiosos en este sentido: gtk. Como muestra un botón: no puedes (o al menos, no debes), cambiar colores de ventanas o botones. Ellos saben mejor que tú cuál es la interfaz perfecta (utilizan este tipo de frases como "no less than perfect user interfaces"). Este virtuosismo permea también a cómo programar una interfaz con Gtk. De hecho, una app hecha con Gtk 2 será totalmente incompatible con Gtk 3, y a su vez, lo mismo para una con Gtk 3 hacia Gtk 4. Portar una app de una versión a otra es un laberinto de APIs obsoletas, funcionalidades refactorizadas, y cambios tan significativos como que los paneles (en Gtk son cajas, Box) han pasado de ser clases separadas para HBox (horizontal) y VBox (vertical), a ser una sola clase Box con un parámetro en el constructor, Orientation.Vertical, u Orientation.Horizontal.

Necesitamos estandarización. Especialmente, si las funcionalidades son las mismas, no es necesario, y de hecho, ni siquiera es aconsejable, crear versiones con interfaces distintas.

Recordemos la analogía del iceberg, de manera que las interfaces deben ser mínimas independientemente de su implementación; y también que el primer lenguaje de programación orientado a objetos, Simula, estaba orientado a la simulación, por ejemplo, de piezas de un motor, de manera que distintas piezas podían intercambiarse... solo si soportaban la misma interfaz, claro.

¿"Ingeniería" del software?

Baltasar García Perez-Schofield — Mon, 27 Jul 2026 11:23:00 +0000

El mayor reto de ingeniería del software nunca ha sido la IA. Siempre se ha tratado de convertir un "desarrollo artesano", en un proceso de ingeniería similar a la construcción, a la mecánica, o cualquier otra. Y si se quiere obtener esto, necesitamos exactamente aquello en lo que nadie está invirtiendo esfuerzo: estandarización. Porque inevitablemente, si quisiéramos apuntar a un proceso de ingeniería, necesitaríamos de algún proceso de montaje o composición de piezas. Y esas piezas son precisamente lo que no tenemos.

El primer proceso de ingeniería del software era el top-down, o también llamado "divide y vencerás", de manera que el algoritmo se divide en procedimientos y funciones. Se presentan dos problemas: el primero, que nadie coincide en qué procedimientos utilizar, y el segundo, que las aplicaciones, al margen de que la construcción de software, siguieron requiriendo más funcionalidad, haciéndose más y más complejas.

El siguiente hito fue el de los módulos. Los módulos serían colecciones de funciones y procedimientos, agrupando funcionalidad común (recordemos, alta cohesión, y bajo acoplamiento). Por ejemplo, en nuestra aplicación podemos crear módulos matemáticos, otros de interfaz de usuario, otro de creación de logs... Y lo mejor es que, para futuros proyectos, podemos reutilizar estos módulos.

No es que el proceso de divide y vencerás debiera eliminarse, sino que tenemos agrupamientos de más alto nivel que son los propios módulos.

Pero la cosa no cuajó: el problema es que cada uno tenía una idea distinta sobre qué módulos crear, y si estos debieran ser de alto nivel o bajo nivel... ¿los de alto nivel deben componerse a partir de aquellos de alto nivel? Con el tiempo, se crearon repositorios de módulos, pero difícilmente se extendió una reutilización de estos módulos.

Y además, volvemos a la problemática anterior: independientemente de que el proceso de ingeniería de software estuviese maduro o no, las aplicaciones seguían subiendo en cuanto a funcionalidad y complejidad.

El siguiente hito fue la POO (programación orientada a objetos). Los módulos se transforman así en clases, que aúnan no solo procedimientos y funciones, sino también los propios datos. La encapsulación inherente del paradigma iba a resolver automáticamente el problema de la cohesión y acoplamiento. Se podrían tener repositorios de clases que podrían reutilizarse para cada funcionalidad.

Sin entrar en detalles, la POO no fue la panacea que se esperaba. Los problemas seguían siendo los mismos: al final, cada programador tenía una idea distinta de qué clases debían componer la aplicación, del nivel de abstracción necesario, y sí, las aplicaciones siguen evolucionando en cuanto a funcionalidad y complejidad.

Y sorprendentemente, se descubrió que la POO no evitaba automáticamente, como se esperaba, que no hubiera acoplamiento entre clases, o que las clases fueran piezas genéricas que podrán transportarse de un proyecto a otro. De nuevo, la reusabilidad emergió como un problema, sin que la POO pudiera evitarlo. No, tampoco aparecieron los repositorios de clases. Aparecieron principios de programación como los SOLID, o los patrones de diseño, que tratan de guiar al programador para intentar mitigar estos problemas.

Finalmente, estamos en el hito de la programación ágil. Se asume que el desarrollo del software es un proceso artesano, y lo que se intenta es delimitar y controlar para que no "se vaya de madre". Pero, ¿hemos alcanzado algún hito de reutilización? No en mi opinión.

Ahora que hemos repasado (muy por encima), la evolución del desarrollo práctico de software, ahondaremos en próximas entradas sobre si los desarrolladores de software tienen este problema interiorizado y están haciendo algo o no.

Z80: 50 años han pasado ya

Baltasar García Perez-Schofield — Sun, 19 Jul 2026 10:41:29 +0000

En junio de 2024, Zilog decidió dejar de fabricar el z80, aunque esto no quiere decir que el Z80 dejase de existir: por ejemplo, Sharp todavía lo vende con la identificación LH0080, y NEC hace lo propio con la etiqueta D780C-1.

El Z80 era compatible con el Intel 8080. ¿Por qué entonces, si ya existía este procesador, Zilog se "animó" a crear una variante compatible? Lo cierto es que el i8080 era bastante enrevesado en cuanto a la forma de alimentarlo: necesitaba varios voltajes. El Z80, sin embargo, solo necesitaba alimentación de 5V, una sola línea de reloj (CLK), y era más rápido.

Funcionamiento interno

Registro	Funcionalidad
A	Registro acumulador.
B	Registro de uso libre.
c	Registro de uso libre.
D	Registro de uso libre.
E	Registro de uso libre.
H	Parte alta de dir. RAM.
L	Parte baja de dir. RAM.
IX	Registro de índice.
IY	Registro de índice.
SP	Stack pointer.
PC	Program counter.

Todos los registros eran de 8 bits, excepto los registros de índice IX e IY, el contador de programa PC, y el puntero de la pila de llamadas, SP, que son de 16 bits. Pero además, el resto de registros se pueden combinar. Por ejemplo, para acceder a una dirección de memoria, se colocan los 8 bits más bajos en L, y los 8 bits más altos en H, de forma que se obtiene una dirección de memoria de 16 bits (2^16 o 65536 bytes/64 K).

Además, los registros B y C se pueden utilizar juntos como registros de 16 bits, si se utiliza el nombre BC, y lo mismo para D y E, que puede ser utilizado como DE.

Los registros IX e IY son nuevos, permitiendo funcionar como índices. Supongamos que necesitas copiar una cadena de caracteres en la posición de memoria 00000000FFFFFFFF, en otra posición de memoria que sería 00000001FFFFFFFF. El primer valor se copiaría en IX, mientras que se haría lo propio con el segundo en IY. Ahora puedes ir copiando el valor apuntado por uno en la posición apuntado en el otro, e ir incrementando ambos.

8 bits bajos	8 bits altos	Registro combinado
B	C	BC
D	E	DE
H	L	HL

Es decir, que si se quiere hacer algún cálculo que involucre 16 bits, se usan BC, o DE, y si se quiere acceder a una determinada posición de memoria, HL.

Compatibilidad y legado

El uso del z80 se extendió rápidamente al ser un chip tan versátil. Esto produjo una situación en la que muchos programas podían ser compatibles a nivel de código ejecutable.

Así, Gary Kildall, programó CP/M (el antepasado del sistema operativo MS-DOS) para Z80, vendiéndolo a través de su nueva empresa Digital Research.

Por cuestiones de desacuerdo en las licencias, no creó CP/M para el IBM-PC con su i8088, y al final se adaptó QDOS (el rápido y sucio sistema operativo, o Quick & Dirty Operating System) para la máquina. Posteriormente, Digital Research desarrollaría DR-DOS, compatible con MS-DOS. Pero eso es otra historia.

Para CP/M se crearon lenguajes de programación, bases de datos... fue tremendamente popular, ya que surgieron multitud de máquinas cuyo corazón era el Z80, y para el que CP/M era muy fácilmente adaptable.

Altair BASIC fue creado originalmente por Bill Gates para el Altair 8080, antes de crear Microsoft. Ocupaba 4K de memoria. Pero la multitud de microordenadores que surgieron utilizando el Z80 hizo que Microsoft BASIC, directamente derivado del anterior, tuviera docenas de versiones adaptadas a ellos, creando máquinas cuyos programas en BASIC en binario eran compatibles entre sí, o facilitando la creación de un estándar como tal, el MSX.

...y por supuesto, fue el corazón del Investrónica/Sinclair Spectrum + 128k, el mejor de los microordenadores de 8 bits de los 80. Como curiosidad, es interesante comentar que existe un nuevo modelo de ZX Spectrum, el ZX Spectrum Next, y este lleva un Z80N. capaz de correr incluso a 28 Mhz., en contraste con los 3.5 Mhz. del original. Eso sí, es una recreación moderna del Z80 mediante una FPGA.

Lo siguiente es el código ensamblador para el "¡Hola, mundo!" en el Speccy. No hace uso de la rutina en ROM print del BASIC, sino que muestra una cadena carácter a carácter, mediante una rutina en ROM de muy bajo nivel (la $10).

org $8000
  ld bc, STR_HELLO        ; Carga en BC la dirección de la cadena

SHOW_CHAR:                ; Cada iteración muestra un carácter.
  ld a, (bc)              ; Carga el carácter actual en A
  cp 0                    ; ¿El carácter en A es un cero?
  jr z, END               ; Si el resultado es true, salta a END
  rst $10                 ; Llama a la rutina en ROM que muestra el carácter A por pantalla
  inc bc                  ; Incrementa la dirección en BC en 1
  jr SHOW_CHAR            ; Salta a SHOW_CHAR

END:
  ret                     ; Terminar el programa, y volver

STR_HELLO:                ; Define la cadena de caracteres terminada en 0
  defb "Hola, mundo!"
  defb 13, 0

El Zilog Z80 fue, por tanto, un pilar fundamental en el desarrollo de la informática, que finalmente, con la aparición de los microordenadores, se introducirá en los hogares para su uso doméstico, algo impensable en los 70.

Y además, cuando en su momento me planteé crear mi propia máquina virtual Zero, fue este micro el que tomé como modelo.