DEV Community: Baltasar García Perez-Schofield

¿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.

Ensamblando DotNet IL

Baltasar García Perez-Schofield — Wed, 15 Jul 2026 20:09:14 +0000

Vimos en la primera parte de esta serie que podemos fácilmente tomar un ensamblado compilado con C# (o con el lenguaje de .NET que queramos), y desensamblarlo para ver su código.

¿Podemos realizar el paso contrario? No estaría mal poder ensamblar código directamente. Veamos cómo.

var asm = AssemblyDefinition.CreateAssembly(
                                new AssemblyNameDefinition( name, new Version( 1, 0, 0, 0 ) ),
                                "tmp",
                                ModuleKind.Dll );

Con esto ya tenemos un ensamblado creado. Pero si queremos ver cualquier cosa que hagamos, vamos a tener que referenciar Console.WriteLine().

var consoleRef = new AssemblyNameReference(
                       "System.Console",
                       new Version( 10, 0, 0, 0 ) );

asm.MainModule.AssemblyReferences.Add( consoleRef );

Ahora creemos una clase llamada App (va a tener un constructor vacío):

var cls = new TypeDefinition(
                 "",
                 clsName,
                 TypeAttrs.Class | TypeAttrs.Public,
                 asm.MainModule.TypeSystem.Object );

// Add a parameterless constructor
var ctor = new MethodDefinition(
            ".ctor",
            MthAttrs.Public | MthAttrs.HideBySig | MthAttrs.SpecialName | MthAttrs.SpecialName,
            asm.MainModule.TypeSystem.Void );

cls.Methods.Add( ctor );

// Import from System.Object type
var objectCtor = asm.MainModule.ImportReference(
                       typeof(object).
                       GetConstructor( Type.EmptyTypes ) );

// Constructor body must call base class constructor
var il = ctor.Body.GetILProcessor();

il.Append( il.Create( OpCodes.Ldarg_0 ) );                      // load 'this'
il.Append( il.Create( OpCodes.Call, objectCtor ));
il.Append( il.Create( OpCodes.Ret ) );
asm.MainModule.Types.Add( toret );

Sí, el hecho de tener que crear un constructor vacío hace que para crear una clase sea necesario bastante código. En el futuro, meteremos este código en un método reusable, claro. Lo más importante son la primera y la última línea. En la primera, es donde se crea la clase (un TypeDefinition), y en la última se toma el módulo principal del ensamblado, y se añade el nuevo tipo allí.

Además, vemos por primera vez código IL siendo creado para un método. Siempre lo haremos de la misma manera: tomamos de la propiedad Body del método el procesador de IL, mediante el método GetILProcessor().

El código que estamos ensamblando es el siguiente:

class App {
    .method public instance .ctor()
    {
        ldarg.0            ; cargar "this" en la pila.
        call Object.ctor   ; base(this)
        ret
    }
}

Ya sabemos que la pila es el último que entra es el primero que sale o LIFO (last in, first out). También sabemos que los métodos llevan un parámetro oculto que es el objeto que está ejecutando el método, this. Aquellas instrucciones que empiezan por ld (load) son equivalentes a push, o meter en la pila. Por ejemplo, ldstr introduce una cadena de caracteres en la pila. Las instrucciones que empiezan por st (store), son equivalentes a pop. Por ejemplo, stfld guarda el valor en el tope de la pila en una campo de un objeto.

ldarg mete un argumento (identificado por su número de posición) en la pila. Así, ldarg 0 metería el primer argumento del método en la pila. Meter el primer argumento en la pila es tan común, que existe un opcode específico: ldarg.0. Lo que hace (lo has adivinado), es meter en la pila el primer argumento del método, que ya hemos visto que es this. call permite llamar a un método en un objeto cualquiera. ret termina el método. Todos los métodos deben tener al menos un ret... ¿sabes que si no incluyes un ret, .NET sigue ejecutando la memoria siguiente, tomándola como instrucciones? ¿Un poco "cutre", no?

Así, el constructor de Object es un constructor sin parámetros... si no contamos con this, claro está. Los parámetros deben tomarse de la pila, y en caso, de necesitar más de uno, será necesario meterlos en la pila en el orden inverso.

El código en C# sería el siguiente:

class App {
    public App() : base()
    {
    }
}

O lo que es lo mismo...

class App {
}

¿Metemos un "¡Hola, mundo!"? Veamos, las instrucciones que necesitaremos ya las hemos visto en su mayoría. Necesitaremos llamar a Console.WriteLine() con una cadena de caracteres como parámetro. Esta cadena de caracteres tendrá que meterse en la pila, antes de la llamada, claro.

    class App {
        public static void Main()
        {
            Console.WriteLine( "¡Hola, mundo!" );
        }
    }

Repasemos entonces lo que es necesario hacer: meter en la pila la cadena de caracteres "¡Hola, mundo!"; hacer la llamada Console.WriteLine(), y finalmente, retornar.

class App {
    .method public static void Main()
    {
        ldstr "¡Hola, mundo!"
        call void [System.Console]System.Console::WriteLine(string)
        ret
    }
}

Lo primero de todo, necesitamos localizar el método WriteLine() en la consola.

var consoleRef = this.Assembly.MainModule.AssemblyReferences.
        FirstOrDefault( r => r.Name == "System.Console" )
        ?? throw new TypeLoadException(
            "missing System.Console assembly reference" );

var consoleType = new TypeReference(
                          "System",
                          "Console",
                          methodInfo.Module,
                          consoleRef );

var writeLineMethod = new MethodReference(
                          "WriteLine",
                          methodInfo.Module.TypeSystem.Void,
                          consoleType );

writeLineMethod.Parameters.Add(
    new ParameterDefinition( methodInfo.Module.TypeSystem.String ) );

Así que necesitamos crear un método Main, dentro de nuestra clase App. Necesitamos las tres instrucciones que hemos visto un poco más arriba.

var mth = new MethodDefinition( mthName,
                                attrs,
                                cls.Module.TypeSystem.Void );

cls.Methods.Add( mth );
il = mth.Body.GetILProcessor();
il.Append( il.Create( OpCodes.Ldstr, "¡Hola, mundo!" ) );
il.Append( il.Create( OpCodes.Call, writeLineMethod ) );
il.Append( il.Create( OpCodes.Ret ) );

Ahora marcamos el método Main() como el punto de entrada del ensamblado, y escribirmos el ensamblado terminado en disco.

asm.Assembly.EntryPoint = mth;
asm.Assembly.Write( "hola.dll" );

Vale. Ahora solo queda ejecutarlo, y comprobar que tenemos el ensamblado creado. Y una vez comprobado... ¡lo ejecutamos!

$ dotnet run
$ ls *.dll
hola.dll
$ dotnet hola.dll
¡Hola, mundo!

¿No te parece fascinante? ¡A mi sí!

Decompilando C#

Baltasar García Perez-Schofield — Fri, 10 Jul 2026 09:24:04 +0000

C# compila a una máquina virtual, llamada CLR (Common Language Runtime), en código ensamblador llamado originalmente MSIL.

El proyecto Mono nació como un versión multiplataforma de C#. En 2016 la empresa creadora, Ximian, fue comprada por Microsoft, y en 2024 Microsoft cedió el proyecto al proyecto Wine.

Así, aunque Mono parece obsoleto hoy en día, el subproyecto CECIL de Mono se mantiene al día, conformándose como una excelente herramienta para analizar IL.

Así, si queremos crear un decompilador, solo tenemos que preparar un proyecto que incluya el paquete NuGET Mono.Cecil.

$ mkdir disasm
$ cd disasm
$ dotnet new console
$ dotnet package new Mono.Cecil

Solo necesitamos una clase muy sencilla para decompilar.

class Disasm {
    public static Instruction[] GetMethodInstructions(string assemblyPath, string typeName, string methodName)
    {
        var toret = Array.Empty<Instruction>();

        using (var assembly = AssemblyDefinition.ReadAssembly( assemblyPath ))
        {
            var type = assembly.MainModule.Types.FirstOrDefault( t => t.Name == typeName );
            var method = type?.Methods.FirstOrDefault( m => m.Name == methodName );

            if ( method?.HasBody == true ) {
                toret = [ .. method.Body.Instructions ];
            }
        }

        return toret;
    }

    public static string StrFromInstructions(Instruction[] instructions)
    {
        return string.Join(
                        "\n",
                        instructions.Select(
                            i => $"{i.Offset:X4}: {i.OpCode} {i.Operand}" ) );
    }
}

Ya solo necesitamos llamar a los métodos de la case con un nombre de ensamblado, otro de clase y finalmente, un nombre de método.

class App {
    static void Decompile(string dllName, string clsName, string mthName)
    {
        var instructions = Disasm.GetMethodInstructions(
                                                dllName, clsName, mthName );

        Console.WriteLine( "DisAsm\n" );
        Console.WriteLine( Disasm.StrFromInstructions( instructions ) );
    }

    static void Main(string[] args)
    {
        if ( args.Length < 4 ) {
            Console.WriteLine( "Please provide: file_name class_name mth_name" );
        } else {
            Decompile( args[ 1 ], args[ 2 ], args[ 3 ] );
        }
    }

Y ahora podemos ejecutarlo, por ejemplo, utilizando el propio ejecutable, y dirigirlo al método Disasm.StrFromInstructions().

$ dotnet run bin/Debug/net11.0/disasm.dll Disasm StrFromInstructions
DisAsm

0000: nop 
0001: ldstr 

0006: ldarg.0 
0007: ldsfld System.Func`2<Mono.Cecil.Cil.Instruction,System.String> Disasm/<>c::<>9__1_0
000C: dup 
000D: brtrue.s IL_0026: call System.Collections.Generic.IEnumerable`1<!!1> System.Linq.Enumerable::Select<Mono.Cecil.Cil.Instruction,System.String>(System.Collections.Generic.IEnumerable`1<!!0>,System.Func`2<!!0,!!1>)
000F: pop 
0010: ldsfld Disasm/<>c Disasm/<>c::<>9
0015: ldftn System.String Disasm/<>c::<StrFromInstructions>b__1_0(Mono.Cecil.Cil.Instruction)
001B: newobj System.Void System.Func`2<Mono.Cecil.Cil.Instruction,System.String>::.ctor(System.Object,System.IntPtr)
0020: dup 
0021: stsfld System.Func`2<Mono.Cecil.Cil.Instruction,System.String> Disasm/<>c::<>9__1_0
0026: call System.Collections.Generic.IEnumerable`1<!!1> System.Linq.Enumerable::Select<Mono.Cecil.Cil.Instruction,System.String>(System.Collections.Generic.IEnumerable`1<!!0>,System.Func`2<!!0,!!1>)
002B: call System.String System.String::Join(System.String,System.Collections.Generic.IEnumerable`1<System.String>)
0030: stloc.0 
0031: br.s IL_0033: ldloc.0
0033: ldloc.0 
0034: ret

Con Mono.Cecil, podremos incluso generar nuestros propios ensamblados, modificando el ensamblado original. ¿Te apuntas?

¿Necesitas más velocidad en tu PC? ¡Pulsa el "turbo"!

Baltasar García Perez-Schofield — Fri, 03 Jul 2026 08:05:37 +0000

El otro día, me sentí muy mayor. Un alumno explicaba cómo había creado desde cero un clon de un programa que solo existía para 16bits... sobre MS-DOS. Se trataba de una herramienta para simular una arquitectura de computador extremadamente simple, sin apenas registros excepto para la ULA (que solo suma), y 256 bytes de RAM en 16 palabras de 16 bits. Se parece a esta Máquina Simple, aunque incluso era más recortada.

El trabajo realizado era excelente. Pero empezó la charla hablando de las limitaciones de la herramienta que se utilizaba actualmente en la asignatura, remarcando que tenía que ser ejecutada con DOSBox, y todo el conjunto era muy lento porque al fin y al cabo, "MS-DOS se ejecutaba a 300 Mhz"...

Miré brevemente, con disimulo, en derredor. Me di cuenta de que era más que probable que fuera el único en la sala que... primero, hubiera usado MS-DOS, y segundo, que se acordase de cómo funcionaba; y de que, desde luego, no corría a 300 Mhz. No sé por qué me acuerdo de estas cosas, pero lo de los 300 MHz ya vino en la época del arranque en popularidad de Windows.

El IBM PC nació como una arquitectura acompañando a un microprocesador Intel 8088, o i8088. El microprocesador que realmente "tocaba" era el i8086, no el i8088, pero este procesador era "puro", con un bus de direcciones y de datos de 16 bits. En cambio, el i8088 era un microprocesador de 16 bits... que se comunicaba con el resto de la placa base a 8 bits. Esto quiere decir que cuando quería acceder a una posición de memoria, o escribir o leer un dato, primero mandaba 8 bits, y después los 8 bits restantes (a esto se le conoce como multiplexación en el tiempo).

El IBM PC salió con el i8088 para abaratar costes, pues en aquella época las placas base de 8 bits eran muy comunes.

Bueno, el caso es que el i8088 funcionaba a 5 Mhz (en realidad, unos 4.7 Mhz). El i8086 era capaz de funcionar con más velocidad, podía llegar incluso a 12 Mhz. Después llegó el i80286, que era capaz de llegar hasta los 25 Mhz.

Después vendría el i80386, un micro con gestión de memoria incorporada, que podía ejecutar sistemas operativos "serios" como UNIX.

Sí, estoy hablando de megaherzios, no de gigaherzios. Pero espera, que ahora llega lo más grande. El caso es que tú tenías tu software de gestión y tus juegos... Si te pasabas a un i80286, de repente, todo iba demasiado rápido. En el software de gestión muchas veces no lo notabas, pero los juegos se tornaban... injugables.

Así que en el chásis tenías un botón, etiquetado "Turbo", que te permitía volver a la velocidad de la generación anterior. Por ejemplo, si tu procesador "corría" a 24 Mhz, pulsando en el botón "Turbo" volvía a los 12 Mhz, por ejemplo. Esto se hacía de múltiples maneras. Una de ellas, con el i80386, era desactivar su caché de 64Kb (que sí, que no eran Megabytes o Gigabytes...).

Cuando salías del juego podías pulsar de nuevo el botón para que el ordenador corriera de nuevo a toda velocidad. Como el recurso empleado era por hardware, los cambios eran inmediatos.

Con el i80486... ¡podías llegar hasta a 100MHz! ¡Toma ya!

Después llegó el Intel Pentium, que sí, ya podía correr a incluso a 300 Mhz. Intel estaba cansada de que sus competidores, como Cyrix o AMD, le copiarán impunemente el nombre de sus micros, pero no podía hacer nada porque los números no pueden registrarse. Así que cambió a Pentium, lo que vendría a rememorar que lo que "tocaba" era el 586. Para entonces en 1995, por todas partes el sistema operativo pasaba a ser Windows 95, y solo los programadores, y raritos, seguíamos usando MS-DOS.

Incluso las aplicaciones empezaban a traer ya un "modo gráfico", que aún ejecutándose sobre MS-DOS, permitía el uso de menús y algo más parecido a WYSIWYG. Por ejemplo, WordPerfect 5.2.

Además, programar para Windows era un suplicio (la biblia del momento para programar para Windows 95, de Petzold, tenía más de 1000 páginas), y hasta que llegó Delphi, entonces de Borland, ahora de Embarcadero, se continuaba programando para MS-DOS, y como mucho, se ejecutaba en una ventana de DOS de Windows, llamada "Símbolo de comando" (?). Excepto grandes empresas, claro.

Pero eso ya es otra historia.

El caso de VIM como editor de textos

Baltasar García Perez-Schofield — Wed, 24 Jun 2026 08:05:48 +0000

Puede parecer que no es cierto, pero Unix fue creado en 1969. Las herramientas de UNIX fueron apareciendo a medida que surgían las necesidades para trabajar con él. El primer editor de textos fue ed, escrito en ensamblador en 1971. Se trataba de una editor de líneas muy parecido a EDLIN, presente en MS-DOS, y ED, presente en CP/M (antecesor de MS_DOS).

En un editor orientado a líneas, nunca se trabaja sobre todo el documento a la vez, sino que se listan (comando l), una serie de líneas, se borran (comando d), o se insertan (comando i). Cuando se quiere que el comando se aplique a varias líneas, se indica el intervalo separado por una coma, y el comando al final. Por ejemplo, 2i insertaría una línea de texto en la actual línea número 2.

> l
1: Esta es la primera línea.
2: Esta es la segunda línea.
3: Esta es la tercera línea.

> 1,2l
1: Esta es la primera línea.
2: Esta es la segunda línea.

> 2i
Esta es una línea insertada entre la primera y la segunda.

> l
1: Esta es la primera línea.
2: Esta es la segunda línea.
3: Esta es una línea insertada entre la primera y la segunda.
4: Esta es la tercera línea.

Pero esta entrada ahonda en el editor de textos vi, que nació en 1976 (hace unos 50 años, o medio siglo, en el momento de escribir este texto). Tras unos quince años, en 1991, nació vim, o Vi IMproved, una mejora sobre vi.

Vi surgió como una interfaz para Ex, un editor orientado a líneas. Al contrario que estos editores, Vi mostraba el texto completo, en toda la pantalla, de manera que era mucho más cómodo que cualquier editor de textos orientado a líneas. Divide su funcionalidad, en cambio, en dos modos: el modo de edición, y el modo de comando. Así, si en cualquier momento se pulsa ESC para salir del modo de edición (si es que se está en este modo), y después se teclea :q se sale del programa. Si se teclea :q!, se sale del programa inmediatamente, descartando posibles cambios. Si se teclea :w, entonces el archivo se escribe a disco. Se pueden combinar comandos, como :wq, que escribe el texto en disco y sale del programa.

Modo	Explicación
Edición	Cada tecla pulsada es un nuevo carácter en el texto.
Comando	Las teclas son parte de un comando.

Comando	Pasa modo	Explicación
i	Edición	Insertar texto antes de la posición actual.
a	Edición	Insertar texto tras la posición actual.
ESC	Comando	Salir del modo de edición.
h, j, k, l	Comando	Mover el cursor por el texto.

En 1985 surgió EMACS, otro editor de textos fuertemente basado en LISP(un lenguaje funcional), para su extensión mediante complementos. La extensión por complementos se hizo tan viral que existen un montón de complementos para él, y de hecho, es conocido como un sistema operativo, en lugar de un simple editor de texto.

Vi se apuntó a esta posibilidad de extensión por complementos, de forma que también se convirtió en un editor configurable para múltiples lenguajes de programación, y otras funcionalidades. El hecho es que ambos se han convertido en editores de textos extraordinariamente complejos en cuanto a configuración, de forma que el archivo de configuración de .vimrc se convierte en un activo complejo, que es necesario compartir entre todos los ordenadores en los que se use.

Durante muchos años, cuando se estilaban las discusiones espúreas, (como por ejemplo, Windows vs Mac), mucha gente con toneladas de tiempo libre se dedicaban a discutir cuál de ambos editores de texto (Vi vs Emacs), era mejor que el otro.

Aunque parece que el uso de Emacs ha ido decreciendo, con un porcentaje de uso de menos de un 9%, VIM mantiene un uso de casi un 25%. Entre los programadores en UNIX/LINUX, claro. Hoy en día, con más de un 70%, parece que el editor de textos más popular es Visual Studio Code, incluso con un uso indirecto en editores como Cursor, que utilizan el código fuente de Visual Studio Code para crear su propio editor con el soporte para agentes IA.

Pero siempre me sorprende que todavía haya mucha gente utilizando Vi o Vim. Por supuesto, con el tiempo, aparecieron "ayudas": además de poder utilizar h, j, k, l para mover el cursor, se mapearon las flechas del cursor, por poner un ejemplo. Y es que, ¿por qué utilizar teclas "normales" para utilizar funciones de edición de texto?

La respuesta es realmente muy simple: porque no había otras teclas disponibles. Lo de arriba es un terminal "tonto", no un ordenador completo; es lo que se utilizaba para comunicarse con el ordenador central. Pero es muy moderno para lo que estamos hablando aquí. El terminal se conoce como tty, o máquina de escribir en teletipo (teleprinter o teletypewriter); y es que era exactamente eso, una máquina de escribir para enviar comandos al ordenador central, y un papel de teletipo para recibir la respuesta. El terminal del que estamos hablando aparece a continuación.

¿Parece una máquina de escribir? Efectivamente, la máquina de escribir era lo más parecido por aquella época con respecto a un terminal de ordenador. Teclas para las letras del abecedario, otras para los dígitos del 0 al 9, un tabulador, una barra espaciadora, salto de línea, y poco más.

¿Sabías que la distribución de teclado qwerty no está pensada para poder escribir tan rápido como sea posible? ¡No! Está pensada para que las teclas más comunes estén muy separadas, y así, las primeras máquinas de escribir no se atascaran...

Así que Vi utilizaba estas teclas "comunes", simplemente, porque no había otras. De ahí que existieran varios modos de operación: de otra forma, no sería posible introducir las teclas de comando en el texto.

Con el tiempo, aparecieron las teclas especiales: las flechas para el cursor, suprimir y borrar, las flechas de modificación como Ctrl y Alt, o incluso, Shift (no, al principio los ordenadores no tenían letras minúsculas). Una vez que aparecen las teclas especiales, editores de texto como Vi, con múltiples modos, símplemente no son necesarios.

¿Por qué, entonces, Vi ha sobrevivido con tanta popularidad hasta nuestros días? Sin duda, parte de la respuesta es la aparición de innumerables complementos para el editor. El resto, para mi es un misterio. Sobre todo cuando tenemos en cuenta que Vi, con un par de docenas de complementos, es lo mismo que un editor de textos moderno.

En cualquier caso, si usas Vi, eres un usuario retro, te guste o no, de un programa que tiene sus raíces en los años 70 del siglo pasado.