Translate

martes, 9 de septiembre de 2025

Introducción a Borgo Programming Language


Ya hablamos de Borgo y en este post vamos a recorrer paso a paso cómo empezar a trabajar con él, desde la instalación hasta la ejecución de un programa sencillo. 

Actualmente, Borgo está disponible como un compilador ligero que se distribuye en GitHub. Para instalarlo:


# Clonar el repositorio oficial

git clone https://github.com/borgo-lang/borgo.git

cd borgo

# Compilar el compilador

make

# Instalar en tu sistema (requiere permisos de administrador)

sudo make install


Una vez instalado, podés comprobar la versión con:

borgoc --version


Un proyecto en Borgo no necesita estructura compleja. Podés empezar creando una carpeta y un archivo de código fuente:


mkdir mi_proyecto

cd mi_proyecto

touch main.borgo


El clásico primer ejemplo. En Borgo, un "Hola Mundo" se vería así:


fn main() {

    print("Hola, mundo!")

}


Para compilar tu programa:

borgoc main.borgo -o main


Esto genera un ejecutable llamado main. Para ejecutarlo:


./main


Y deberías ver:

Hola, mundo!


Podemos sumar dos números y mostrar el resultado:


fn suma(a: Int, b: Int): Int {

    return a + b

}


fn main() {

    let resultado = suma(3, 4)

    print("El resultado es: ", resultado)

}


Compilás y ejecutás de la misma manera:


borgoc main.borgo -o main

./main


Salida:

El resultado es: 7


Borgo es un lenguaje minimalista pero potente, con una curva de aprendizaje muy baja. Lo interesante es que te permite escribir y compilar programas rápidamente, sin demasiada configuración.

domingo, 7 de septiembre de 2025

Comandos y suscripciones

 Anteriormente vimos cómo la arquitectura Elm gestiona las interacciones del ratón y el teclado, pero ¿qué ocurre con la comunicación con los servidores? ¿Con la generación de números aleatorios?

Para responder a estas preguntas, es útil comprender mejor cómo funciona la arquitectura Elm en segundo plano. Esto explicará por qué las cosas funcionan de forma ligeramente diferente a lenguajes como JavaScript, Python, etc.


Sandbox

No le he dado mucha importancia, pero hasta ahora todos nuestros programas se crearon con Browser.sandbox. Proporcionamos un modelo inicial y describimos cómo actualizarlo y visualizarlo.

Puedes imaginar Browser.sandbox como la configuración de un sistema como este:



Nos mantenemos en el mundo de Elm, escribiendo funciones y transformando datos. Esto se conecta al sistema de ejecución de Elm. Este sistema determina cómo renderizar HTML eficientemente. ¿Ha cambiado algo? ¿Cuál es la modificación mínima del DOM necesaria? También detecta cuándo alguien hace clic en un botón o escribe en un campo de texto. Lo convierte en un mensaje y lo introduce en el código de Elm.

Al separar claramente toda la manipulación del DOM, es posible utilizar optimizaciones extremadamente agresivas. Por lo tanto, el sistema de ejecución de Elm es una de las razones principales por las que Elm es una de las opciones más rápidas disponibles.


element

En los siguientes ejemplos, usaremos Browser.element para crear programas. Esto introducirá los conceptos de comandos y suscripciones que nos permiten interactuar con el mundo exterior.

Puedes imaginar Browser.element como la configuración de un sistema como este:


Además de generar valores HTML, nuestros programas también enviarán valores Cmd y Sub al sistema de ejecución. En este contexto, nuestros programas pueden ordenar al sistema de ejecución que realice una solicitud HTTP o genere un número aleatorio. También pueden suscribirse a la hora actual.

Creo que los comandos y las suscripciones cobran más sentido al ver ejemplos, por lo tanto, en los próximos posts veremos ejemplos. 



sábado, 6 de septiembre de 2025

Patrones de Diseño Comunes en el Uso de Colas



En sistemas distribuidos y arquitecturas modernas, el uso de colas de mensajes (Message Queues) se ha vuelto fundamental. Una cola permite que distintos procesos o servicios se comuniquen de forma asíncrona, desacoplada y tolerante a fallos.

Pero más allá de la idea básica, a lo largo del tiempo han surgido patrones de diseño comunes que nos ayudan a organizar y resolver problemas típicos en el uso de colas.


Productor – Consumidor

Es el patrón más simple:

  • Un productor envía mensajes a la cola.
  • Un consumidor los procesa en orden.

Ventajas: desacopla quién genera la tarea de quién la resuelve.

Ejemplo: un servicio de e-commerce que recibe pedidos (productor) y un servicio de facturación que los procesa (consumidor).


Work Queue (Cola de trabajo)

Extiende el patrón anterior:

  • Varios consumidores leen de la misma cola.
  • Los mensajes se reparten entre ellos.

Ventajas: balanceo de carga automático.

Ejemplo: procesamiento de imágenes en paralelo por múltiples workers.


Publish – Subscribe (Pub/Sub)

Un mensaje publicado puede llegar a muchos consumidores al mismo tiempo.

Cada suscriptor recibe su propia copia.

Ventajas: facilita arquitecturas basadas en eventos.

Ejemplo: al registrarse un nuevo usuario, se notifican:

  • el servicio de email de bienvenida,
  • el sistema de analíticas,
  • y el motor de recomendaciones.


Routing (Enrutamiento de mensajes)

Los mensajes llevan una clave de enrutamiento, y solo ciertos consumidores los reciben.

Ventajas: flexibilidad en la distribución de tareas.

Ejemplo:

Clave email → va al microservicio de correo.

Clave sms → va al microservicio de mensajería.


Priority Queue (Cola con prioridad)

Los mensajes tienen prioridad, y los más urgentes se procesan primero.

Ventajas: asegura la atención de los eventos críticos.

Ejemplo: en un sistema de soporte, los tickets urgentes se atienden antes que los normales.


Dead Letter Queue (Cola de mensajes fallidos)

Cuando un mensaje no puede ser procesado correctamente después de varios intentos, se envía a una cola especial de errores.

Ventajas: no se pierden mensajes y se pueden auditar.

Ejemplo: una orden de compra inválida que requiere revisión manual.


Delayed Queue (Cola con retardo)

Los mensajes no se procesan inmediatamente, sino que quedan en espera hasta que pasa cierto tiempo.

Ventajas: permite programar tareas futuras.

Ejemplo: enviar un recordatorio de pago 24 horas antes del vencimiento.


Las colas no son solo un mecanismo para mover datos entre procesos:

  • Implementan patrones que ayudan a construir sistemas robustos, escalables y fáciles de mantener.
  • Elegir el patrón correcto (Productor-Consumidor, Work Queue, Pub/Sub, Routing, etc.) puede simplificar la arquitectura y mejorar el rendimiento.


En el mundo de los microservicios y las arquitecturas event-driven, los patrones de diseño con colas son una pieza clave del rompecabezas.

jueves, 4 de septiembre de 2025

Uso de la cláusula WITH de oracle


Cuando trabajamos con consultas SQL complejas en Oracle, a menudo tenemos que repetir subconsultas o escribir expresiones largas que hacen que el código sea difícil de leer y mantener.

Para resolver esto, Oracle nos ofrece la cláusula WITH, también conocida como subquery factoring.

La cláusula WITH permite definir subconsultas temporales que luego pueden ser utilizadas dentro de una consulta principal.

Es como declarar variables en programación: escribimos la subconsulta una sola vez, le damos un nombre, y la reutilizamos en la consulta final.

Veamos un ejemplo básico

Supongamos que tenemos una tabla ventas con las columnas:

  • id
  • producto
  • cantidad
  • precio


Queremos obtener el total de ventas por producto y luego filtrar aquellos productos con ventas mayores a 1000.


WITH ventas_totales AS (

    SELECT producto,

           SUM(cantidad * precio) AS total

    FROM ventas

    GROUP BY producto

)

SELECT producto, total

FROM ventas_totales

WHERE total > 1000;


1. En la parte del WITH definimos ventas_totales como una subconsulta.

2. Luego usamos ventas_totales como si fuera una tabla en la consulta principal.


Las ventajas son:

  • Hace que las consultas largas sean más legibles.
  • Evita duplicar subconsultas.
  • Permite estructurar consultas de forma modular.


Podemos definir más de una subconsulta en el mismo WITH:


WITH

    ventas_totales AS (

        SELECT producto, SUM(cantidad * precio) AS total

        FROM ventas

        GROUP BY producto

    ),

    productos_top AS (

        SELECT producto

        FROM ventas_totales

        WHERE total > 1000

    )

SELECT p.producto, v.total

FROM productos_top p

JOIN ventas_totales v ON p.producto = v.producto;


Aquí usamos dos subconsultas (ventas_totales y productos_top) y las combinamos en la consulta final.

Desde Oracle 11g, la cláusula WITH también soporta consultas recursivas, muy útiles para recorrer jerarquías (como empleados y jefes, o categorías anidadas).

Ejemplo:


WITH empleados_recursivo (id, nombre, manager_id, nivel) AS (

    SELECT id, nombre, manager_id, 1

    FROM empleados

    WHERE manager_id IS NULL

    UNION ALL

    SELECT e.id, e.nombre, e.manager_id, er.nivel + 1

    FROM empleados e

    JOIN empleados_recursivo er ON e.manager_id = er.id

)

SELECT *

FROM empleados_recursivo;


Esto nos da una vista jerárquica de empleados y sus jefes, similar a CONNECT BY, pero más flexible.


Conclusión:

La cláusula WITH en Oracle es una herramienta poderosa para:

  • Hacer más claras las consultas complejas.
  • Reutilizar resultados intermedios.
  • Explorar jerarquías con recursividad.


Cuando tus consultas SQL se vuelvan largas o difíciles de leer, pensá en usar WITH para organizarlas mejor.


martes, 2 de septiembre de 2025

Informe de errores en Elm


Quizás tengamos un sitio web donde la gente introduzca su edad. Podríamos comprobar si la edad es razonable con una función como esta:

isReasonableAge : String -> Result String Int

isReasonableAge input =

  case String.toInt input of

    Nothing ->

      Err "That is not a number!"


    Just age ->

      if age < 0 then

        Err "Please try again after you are born."


      else if age > 135 then

        Err "Are you some kind of turtle?"


      else

        Ok age


-- isReasonableAge "abc" == Err ...

-- isReasonableAge "-13" == Err ...

-- isReasonableAge "24"  == Ok 24

-- isReasonableAge "150" == Err ...


No solo podemos comprobar la edad, sino que también podemos mostrar mensajes de error según los detalles de la entrada. ¡Este tipo de retroalimentación es mucho mejor que nada!

El tipo Result también puede ayudarte a recuperarte de errores. Esto se observa al realizar solicitudes HTTP. Supongamos que queremos mostrar el texto completo de Ana Karenina de León Tolstói. Nuestra solicitud HTTP genera una cadena de error de resultado para indicar que la solicitud puede tener éxito con el texto completo o puede fallar de diversas maneras:


type Error

= BadUrl String

| Timeout

| NetworkError

| BadStatus Int

| BadBody String


-- Ok "All happy ..." : Result Error String

-- Err Timeout : Result Error String

-- Err NetworkError : Result Error String

A partir de ahí, podemos mostrar mensajes de error más atractivos, como ya comentamos, pero también podemos intentar recuperarnos del fallo. Si vemos un Timeout, puede que funcione esperar un poco e intentarlo de nuevo. Mientras que si vemos un BadStatus 404, no tiene sentido volver a intentarlo.


Result de Elm


El tipo Maybe puede ser útil con funciones simples que podrían fallar, pero no indica el motivo. Imagina que un compilador simplemente indicara "Nothing" si algo fallaba en tu programa. ¡Buena suerte intentando averiguar qué falló!

Aquí es donde el tipo Result resulta útil. Se define así:


type Result error value

  = Ok value

  | Err error


El objetivo de este tipo es proporcionar información adicional cuando algo falla. Es muy útil para el informe y la recuperación de errores.


jueves, 28 de agosto de 2025

Maybe en Elm


 Seguimos con el Maybe

Este tipo "Maybe" es bastante útil, pero tiene sus límites. Los principiantes tienden a entusiasmarse con "Maybe" y a usarlo en todas partes, aunque un tipo personalizado sería más apropiado.

Por ejemplo, supongamos que tenemos una aplicación de ejercicios en la que competimos contra nuestros amigos. Se empieza con una lista de nombres de amigos, pero se puede cargar más información de fitness sobre ellos más adelante. Podrías tener la tentación de modelarlo así:


type alias Friend =

  { name : String

  , age : Maybe Int

  , height : Maybe Float

  , weight : Maybe Float

  }


Toda la información está ahí, pero no estás modelando realmente el funcionamiento de tu aplicación. Sería mucho más preciso modelarlo así:

type Friend

  = Less String

  | More String Info


type alias Info =

  { age : Int

  , height : Float

  , weight : Float

  }


Este nuevo modelo captura mucha más información sobre tu aplicación. Solo hay dos situaciones reales. O solo tienes el nombre, o tienes el nombre y mucha información. En el código de tu vista, simplemente piensa si estás mostrando una vista Less o More del amigo. No tienes que responder preguntas como "¿qué pasa si tengo la edad pero no el peso?". ¡Eso no es posible con nuestro tipo más preciso!

La cuestión es que, si usas Maybe en todas partes, vale la pena examinar las definiciones de tipo y alias de tipo para ver si puedes encontrar una representación más precisa. ¡Esto suele dar lugar a muchas refactorizaciones útiles en tu código de actualización y vista!

El inventor de las referencias nulas, Tony Hoare, las describió así:

Lo llamo mi error de mil millones de dólares. Fue la invención de la referencia nula en 1965. En aquel entonces, estaba diseñando el primer sistema de tipos completo para referencias en un lenguaje orientado a objetos (ALGOL W). Mi objetivo era garantizar que todo uso de referencias fuera absolutamente seguro, con la comprobación realizada automáticamente por el compilador. Pero no pude resistir la tentación de incluir una referencia nula, simplemente por su facilidad de implementación. Esto ha provocado innumerables errores, vulnerabilidades y fallos del sistema, que probablemente han causado miles de millones de dólares en daños y perjuicios en los últimos cuarenta años.

Ese diseño hace que el fallo sea implícito. Cada vez que creas tener una cadena, podrías tener un valor nulo. ¿Deberías comprobarlo? ¿Lo comprobó quien te dio el valor? ¿Quizás no haya problema? ¿Quizás bloquee tu servidor? ¡Supongo que lo averiguaremos más adelante!

Elm evita estos problemas al no tener referencias nulas. En su lugar, usamos tipos personalizados como Maybe para que el fallo sea explícito. De esta forma, nunca hay sorpresas. Una cadena siempre es una cadena, y cuando ves una cadena Maybe, el compilador se asegurará de que se tengan en cuenta ambas variantes. De esta forma, obtienes la misma flexibilidad, pero sin los fallos inesperados.

martes, 26 de agosto de 2025

Lambdas en C++: Entendiendo los []




En C++ las funciones anónimas (lambdas) se definen con la siguiente sintaxis general:


[capturas](parámetros) -> tipo_retorno {

    // cuerpo de la función

}


La parte más llamativa son los corchetes [] al inicio.

Ahí se especifica cómo la lambda accede a las variables externas a su alcance (scope).

¿Por qué C++ necesita los []? En muchos lenguajes (como JavaScript o Python) las funciones anónimas pueden usar directamente variables externas sin decir nada especial.

En cambio, C++ es un lenguaje con:

  • tipado fuerte,
  • control de memoria explícito,
  • y reglas claras de tiempo de vida de las variables.

Por eso, el estándar obliga a indicar en los [] qué variables del entorno queremos capturar y cómo (por valor o por referencia).

Esto evita accesos accidentales y hace explícito el costo en memoria/copias.

Modos de captura en C++ :

1. Sin captura

[]() { cout << "Hola lambda!" << endl; }();

La lambda no accede a nada externo. Sirve como función pura.


2. Captura por valor

int x = 10;

auto f = [x]() { cout << x << endl; };

f(); // imprime 10


Se copia la variable x dentro de la lambda. Y si después cambias x, la lambda no lo ve.


3. Captura por referencia

int x = 10;

auto f = [&x]() { x++; };

f();

cout << x << endl; // imprime 11


Se captura la referencia, por lo que la lambda puede modificar la variable externa.


4. Captura de todo por valor


int a = 1, b = 2;

auto f = [=]() { cout << a + b << endl; };

f(); // imprime 3


5. Captura de todo por referencia


int a = 1, b = 2;

auto f = [&]() { a++; b++; };

f();

cout << a << ", " << b << endl; // imprime 2, 3


6. Mixtas


int a = 1, b = 2;

auto f = [=, &b]() { cout << a + b << endl; b++; };

f(); // imprime 3

cout << b << endl; // 3


Aquí capturamos todo por valor, excepto b que es por referencia.


7. Captura de `this`


En clases, podemos capturar this para acceder a miembros:


class Persona {

    int edad = 20;

public:

    void mostrar() {

        auto f = [this]() { cout << edad << endl; };

        f();

    }

};


Desde C++17 también existe [=, this] (por valor y this por referencia implícita).


Los [] de una lambda en C++ son la forma explícita de indicar qué variables externas queremos usar y cómo.

Esto es necesario porque:

  • C++ cuida la propiedad de los datos.
  • No siempre es obvio si queremos copiar o referenciar algo.
  • Evita errores de memoria y da más control al programador.


viernes, 22 de agosto de 2025

Maybe en Elm


A medida que trabajemos más con Elm, veremos el tipo Maybe con bastante frecuencia. Se define así:


type Maybe a

  = Just a

  | Nothing


-- Just 3.14 : Maybe Float

-- Just "hi" : Maybe String

-- Just True : Maybe Bool

-- Nothing   : Maybe a


Este tipo tiene dos variantes: Nothing o Just a value. La variable de tipo permite tener Maybe Float y Maybe String según el valor.

Esto puede ser útil en dos escenarios principales: funciones parciales y campos opcionales.

A veces se necesita una función que responda a algunas entradas, pero no a otras. Mucha gente se encuentra con esto con String.toFloat al intentar convertir la entrada del usuario en números. Veámoslo en acción:


> String.toFloat

<function> : String -> Maybe Float


> String.toFloat "3.1415"

Just 3.1415 : Maybe Float


> String.toFloat "abc"

Nothing : Maybe Float


No todas las cadenas tienen sentido como números, así que esta función lo modela explícitamente. ¿Se puede convertir una cadena en un valor de punto flotante? ¡Quizás! A partir de ahí, podemos hacer una coincidencia de patrones con los datos resultantes y continuar según corresponda.

Otro lugar donde se ven comúnmente valores "Maybe" es en registros con campos opcionales.

Por ejemplo, supongamos que gestionamos una red social. Conectamos personas, buscamos amistad, etc. Ya conoces la explicación. The Onion describió nuestros verdaderos objetivos en 2011: extraer la mayor cantidad de datos posible para la CIA. Y si queremos todos los datos, debemos facilitar el acceso a los usuarios. Permitir que los añadan más adelante. Añadir funciones que los animen a compartir más y más información con el tiempo.

Comencemos con un modelo simple de usuario. Debe tener un nombre, pero la edad será opcional.


type alias User =

  { name : String

  , age : Maybe Int

  }


Ahora digamos que Sue crea una cuenta, pero decide no proporcionar su fecha de nacimiento:


sue : User

sue =

  { name = "Sue", age = Nothing }


Sin embargo, los amigos de Sue no pueden desearle un feliz cumpleaños. Me pregunto si realmente les importa... Más tarde, Tom crea un perfil y sí proporciona su edad:


tom : User

tom =

  { name = "Tom", age = Just 24 }


Genial, eso será genial en su cumpleaños. Pero lo más importante es que Tom forma parte de un grupo demográfico valioso. Los anunciantes estarán encantados.

Bien, ahora que tenemos algunos usuarios, ¿cómo podemos promocionarles alcohol sin infringir ninguna ley? Probablemente se enfadarían si lo hiciéramos para menores de 21 años, así que vamos a comprobarlo:


canBuyAlcohol : User -> Bool

canBuyAlcohol user =

  case user.age of

    Nothing ->

      False


    Just age ->

      age >= 21


Observa que el tipo Maybe nos obliga a realizar una coincidencia de patrones con la edad del usuario. De hecho, es imposible escribir código olvidando que los usuarios pueden no tener edad. ¡Elm se encarga de ello! Ahora podemos anunciar alcohol con la seguridad de que no estamos influyendo directamente en menores. Solo en sus compañeros mayores.


martes, 19 de agosto de 2025

Manejo de errores en Elm


Una de las garantías de Elm es que no se observarán errores de ejecución en la práctica. Esto se debe, en parte, a que Elm trata los errores como datos. En lugar de bloquearse, modelamos explícitamente la posibilidad de fallo con tipos personalizados. Por ejemplo, supongamos que desea convertir la entrada del usuario en una edad. Podría crear un tipo personalizado como este:


type MaybeAge

= Age Int

| InvalidInput


toAge : String -> MaybeAge

toAge userInput =

...


-- toAge "24" == Age 24

-- toAge "99" == Age 99

-- toAge "ZZ" == InvalidInput


Independientemente de la entrada que se proporcione a la función toAge, siempre produce un valor. Una entrada válida produce valores como Age 24 y Age 99, mientras que una entrada no válida produce el valor InvalidInput. A partir de ahí, utilizamos la coincidencia de patrones para garantizar que se consideren ambas posibilidades. ¡Sin bloqueos!

¡Este tipo de problemas surgen constantemente! Por ejemplo, quizás quieras convertir un conjunto de entradas de usuario en una publicación para compartir. Pero, ¿qué ocurre si olvidan añadir un título? ¿O si la publicación no tiene contenido? Podríamos modelar todos estos problemas explícitamente:


type MaybePost

= Post { title : String, content : String }

| NoTitle

| NoContent


toPost : String -> String -> MaybePost

toPost title content =

...


-- toPost "hi" "¿qué tal?" == Post { title = "hi", content = "¿qué tal?" }

-- toPost "" "" == NoTitle

-- toPost "hi" "" == NoContent


En lugar de simplemente indicar que la entrada no es válida, describimos cada una de las posibles causas del error. Si tenemos una función viewPreview : MaybePost -> Html msg para previsualizar publicaciones válidas, ahora podemos mostrar mensajes de error más específicos en el área de vista previa cuando algo falla.

Este tipo de situaciones son extremadamente comunes. Suele ser útil crear un tipo personalizado para cada situación, pero en algunos casos más sencillos, puede usar un tipo estándar. 



Inner Classes en Java vs Nested Classes en C#


En muchos lenguajes podemos anidar clases dentro de otras, pero no siempre significan lo mismo ni tienen las mismas capacidades. Veamos la comparación entre Java y C#.

Java tiene Inner Classes. Cuando declaramos una clase dentro de otra, tenemos dos opciones principales:

Static nested class: funciona como una clase estática, no tiene referencia a la instancia externa.

Inner class (no estática): mantiene una referencia implícita a la instancia de la clase que la contiene.

Esto permite escribir cosas como:


class Contenedora {

    private int valor = 42;


    class Inner {

        void mostrar() {

            // Acceso implícito a la instancia externa

            System.out.println("Valor: " + Contenedora.this.valor);

        }

    }


    public static void main(String[] args) {

        Contenedora c = new Contenedora();

        Contenedora.Inner i = c.new Inner();

        i.mostrar(); // Valor: 42

    }

}


Aquí, Contenedora.this es una referencia implícita que permite acceder directamente a la instancia de la clase externa.


En C# tenemos Nested Classes. En C#, todas las clases anidadas son conceptualmente clases estáticas (aunque no las declares static).

Esto significa que no existe referencia implícita a la instancia externa.


Ejemplo equivalente en C#:


public class Contenedora

{

    private int valor = 42;


    public class Nested

    {

        // No existe "Contenedora.this"

        public void Mostrar(Contenedora externa)

        {

            Console.WriteLine($"Valor: {externa.valor}");

        }

    }


    public static void Main()

    {

        var c = new Contenedora();

        var n = new Nested();

        n.Mostrar(c); // Valor: 42

    }

}


Si querés acceder a los atributos de la clase externa, tenés que pasar explícitamente la referencia (Contenedora externa en este caso).

Entonces, Java Inner Class:

  • Tiene un puntero implícito a la instancia externa.
  • Podés usar Outer.this.atributo.
  • Muy útil en callbacks o cuando la clase interna depende fuertemente de la externa.


C# Nested Class:

  • No tiene referencia implícita.
  • No existe Outer.this.
  • Son más “independientes”, como una clase estática que solo vive en el scope de otra.


¿Por qué esta diferencia?

  • Java diseñó las inner classes como un mecanismo para trabajar con GUI y callbacks (ejemplo clásico: listeners en Swing). Por eso necesitan la referencia a la instancia externa.
  • C# tomó otro camino: sus delegates y lambdas con closures resuelven ese escenario sin necesidad de que las nested classes tengan referencia implícita.



viernes, 15 de agosto de 2025

Pattern Matching en elm


Aprendimos a crear tipos personalizados con la palabra clave type. Nuestro ejemplo principal fue un usuario en una sala de chat:


type User

  = Regular String Int

  | Visitor String


Los usuarios habituales tienen nombre y edad, mientras que los visitantes solo tienen nombre. Ya tenemos nuestro tipo personalizado, pero ¿cómo lo usamos?

Supongamos que queremos una función toName que decida el nombre que se mostrará para cada usuario. Necesitamos usar una expresión case:


toName : User -> String

toName user =

  case user of

    Regular name age ->

      name

    Visitor name ->

      name


-- toName (Regular "Thomas" 44) == "Thomas"

-- toName (Visitor "kate95")    == "kate95"


La expresión case nos permite ramificar según la variante que veamos, así que, independientemente de si vemos a Thomas o a Kate, siempre sabremos cómo mostrar su nombre.

Y si probamos argumentos inválidos como toName (Visitar "kate95") o toName Anonymous, el compilador nos lo notifica inmediatamente. Esto significa que muchos errores simples se pueden corregir en segundos, en lugar de informar a los usuarios y consumir mucho más tiempo.

La función toName que acabamos de definir funciona de maravilla, pero ¿se da cuenta de que la edad no se utiliza en la implementación? Cuando algunos de los datos asociados no se utilizan, es habitual usar un comodín en lugar de asignarles un nombre:


toName : User -> String

toName user =

  case user of

    Regular name _ ->

      name

    Visitor name ->

      name


El _ reconoce los datos, pero también indica explícitamente que nadie los está utilizando.



martes, 12 de agosto de 2025

Sobrecarga de métodos en TypeScript: limitaciones y soluciones


A diferencia de lenguajes como Java o C#, TypeScript sí permite declarar sobrecargas… pero con una particularidad: solo podemos implementar un único método que soporte todas las variantes declaradas.

Esto significa que no podemos tener múltiples implementaciones distintas como en otros lenguajes, sino que debemos manejar la lógica dentro de un único cuerpo de función.

Supongamos que queremos una función procesar que:

  • Si recibe un string, lo devuelva en mayúsculas.
  • Si recibe un number, devuelva su cuadrado.
  • Si recibe dos number, devuelva su suma.


En Java o C# esto serían tres métodos distintos.

En TypeScript lo declaramos así:


class Procesador {

  procesar(dato: string): string;

  procesar(dato: number): number;

  procesar(a: number, b: number): number;


  // Implementación única obligatoria

  procesar(arg1: string | number, arg2?: number): string | number {

    if (typeof arg1 === 'string') {

      return arg1.toUpperCase();

    }

    if (typeof arg1 === 'number' && typeof arg2 === 'number') {

      return arg1 + arg2;

    }

    if (typeof arg1 === 'number') {

      return arg1 * arg1;

    }

    throw new Error('Parámetros no soportados');

  }

}


const p = new Procesador();

console.log(p.procesar('hola'));    // "HOLA"

console.log(p.procesar(5));         // 25

console.log(p.procesar(3, 4));      // 7


En otros lenguajes, cada sobrecarga tiene su propio cuerpo.

En TypeScript, todas las sobrecargas deben compartir una única implementación que maneje la lógica de todos los casos.

¿Cómo simular implementaciones separadas?  Una opción para acercarnos al comportamiento tradicional es delegar la lógica a métodos privados:


class ProcesadorSeparado {

  procesar(dato: string): string;

  procesar(dato: number): number;

  procesar(a: number, b: number): number;


  procesar(arg1: string | number, arg2?: number): string | number {

    if (typeof arg1 === 'string') return this.procesarString(arg1);

    if (typeof arg1 === 'number' && typeof arg2 === 'number') return this.procesarDosNumeros(arg1, arg2);

    if (typeof arg1 === 'number') return this.procesarUnNumero(arg1);

    throw new Error('Parámetros no soportados');

  }


  private procesarString(valor: string): string {

    return valor.toUpperCase();

  }


  private procesarUnNumero(valor: number): number {

    return valor * valor;

  }


  private procesarDosNumeros(a: number, b: number): number {

    return a + b;

  }

}


const p2 = new ProcesadorSeparado();

console.log(p2.procesar('hola')); // "HOLA"

console.log(p2.procesar(5));      // 25

console.log(p2.procesar(3, 4));   // 7



Esto no elimina la restricción del lenguaje, pero hace que el código sea más limpio y cercano al estilo de sobrecarga en otros lenguajes.


sábado, 9 de agosto de 2025

Mensajes y Modelos en Elm


Ya vimos un par de ejemplos de definición de un tipo Msg. Este tipo de tipo es extremadamente común en Elm. En nuestra sala de chat, podríamos definir un tipo Msg de la siguiente manera:


type Msg

   = PressedEnter

   | ChangedDraft String

   | ReceivedMessage { user: User, message: String }

   | ClickedExit


Tenemos cuatro variantes. Algunas no tienen datos asociados, otras tienen muchos. Observe que ReceivedMessage tiene un registro como dato asociado. Esto es perfectamente correcto. ¡Cualquier tipo puede ser un dato asociado! Esto le permite describir las interacciones en su aplicación con mucha precisión.

Los tipos personalizados se vuelven extremadamente potentes cuando empieza a modelar situaciones con mucha precisión. Por ejemplo, si está esperando a que se carguen datos, podría querer modelarlos con un tipo personalizado como este:


type Profile

   = Failure

   | Loading

   | Success { name : String, description : String }


Así, puedes comenzar en el estado Loading y luego pasar a Failure o Success según lo que suceda. Esto simplifica enormemente la creación de una función de vista que siempre muestre algo razonable cuando se cargan los datos.

Los tipos personalizados son la característica más importante de Elm. Ofrecen mucha profundidad, especialmente una vez que te acostumbras a modelar escenarios con mayor precisión. 

is, as de C# y el viejo amigo instanceof de Java


En C#, trabajar con tipos en tiempo de ejecución es bastante cómodo gracias a dos operadores clave: is y as.

is nos dice si un objeto es de un tipo determinado, y desde C# 7 nos deja incluso declarar la variable directamente en la comprobación.


if (obj is string texto)

{

    Console.WriteLine(texto.ToUpper());

}


De esta forma, la verificación y el cast se hacen en una sola línea, clara y segura.


El otro operador, as, va un paso más allá: intenta convertir el objeto y, si no puede, devuelve null en lugar de lanzar una excepción. Ideal para esos casos donde la conversión no es obligatoria, pero sí útil si ocurre:


var texto = obj as string;

if (texto != null)

{

    Console.WriteLine(texto.Length);

}


Con estos dos, en C# rara vez tenemos que hacer casts inseguros, y eso se agradece.


Ahora, en el mundo Java siempre hemos tenido a instanceof, que durante años fue… digamos… más básico: verificaba el tipo, pero luego había que castear manualmente:


if (obj instanceof String) {

    String texto = (String) obj;

    System.out.println(texto.toUpperCase());

}


Esto cambió en Java 14, cuando instanceof adoptó pattern matching. Ahora podemos escribir:


if (obj instanceof String texto) {

    System.out.println(texto.toUpperCase());

}


Sí, muy similar a lo que C# ya hacía.



Y con Java 21 llegó la verdadera vuelta de tuerca: pattern matching dentro de switch. Esto no solo ahorra código, sino que hace más expresivas estructuras de control que antes eran un desfile de if/else.


switch (obj) {

    case String s -> System.out.println("Cadena: " + s.toUpperCase());

    case Integer i -> System.out.println("Entero: " + (i * 2));

    default -> System.out.println("Otro tipo");

}


Así que hoy, si trabajás en C#, tenés en is y as dos herramientas muy potentes para escribir código seguro y legible. Y si venís de Java, sabé que instanceof ya no es el operador limitado de antes: está alcanzando la versatilidad de C#, y con switch incluso ofrece caminos nuevos para organizar la lógica.

En ambos lenguajes, dominar estas técnicas significa escribir código más limpio, menos propenso a errores y, sobre todo, más agradable de mantener.


viernes, 8 de agosto de 2025

Tipos personalizados en Elm



Hasta ahora hemos visto varios tipos como Bool, Int y String. Pero ¿cómo definimos los nuestros?

Supongamos que estamos creando una sala de chat. Todos necesitan un nombre, pero algunos usuarios no tienen una cuenta permanente. Simplemente dan un nombre cada vez que acceden.

Podemos describir esta situación definiendo el tipo UserStatus, enumerando todas las posibles variaciones:


type UserStatus = Regular | Visitor


El tipo UserStatus tiene dos variantes: un usuario puede ser Regular o un Visitante. Por lo tanto, podríamos representar a un usuario como un registro de la siguiente manera:


type UserStatus

   = Regular

   | Visitor


type alias User =

{ status : UserStatus

, name : String

}


thomas = { status = Regular, name = "Thomas" }

kate95 = { status = Visitor, name = "kate95" }


Ahora podemos rastrear si un usuario es Regular con cuenta o un Visitante de paso. No es muy complicado, ¡pero podemos simplificarlo!


En lugar de crear un tipo personalizado y un alias, podemos representar todo esto con un solo tipo personalizado. Las variantes Regular y Visitor tienen datos asociados. En nuestro caso, estos datos son un valor de cadena:


type User

   = Regular String

    | Visitor String


thomas = Regular "Thomas"

kate95 = Visitor "kate95"


Los datos se adjuntan directamente a la variante, por lo que ya no es necesario el registro.

Otra ventaja de este enfoque es que cada variante puede tener diferentes datos asociados. Supongamos que los usuarios Regulares proporcionaron su edad al registrarse. No hay una forma sencilla de capturar esto con registros, pero al definir tu propio tipo personalizado, no hay problema. Añadamos algunos datos asociados a la variante Regular :


> type User

   = Regular String Int

   | Visitor String


> Regular

<function> : String -> Int -> User


> Visitor

<function> : String -> User


> Regular "Thomas" 44

Regular "Thomas" 44 : User


> Visitor "kate95"

Visitor "kate95" : User


Solo hemos añadido la edad, pero las variantes de un tipo pueden variar bastante. Por ejemplo, quizá queramos añadir la ubicación de los usuarios Regulares para poder sugerir salas de chat regionales. O quizá queramos tener usuarios anónimos:


type User

  = Regular String Int Location

  | Visitor String

  | Anonymous



martes, 5 de agosto de 2025

Modelado en Elm


Los tipos personalizados se vuelven extremadamente potentes cuando se empiezan a modelar situaciones con mucha precisión. Por ejemplo, si se espera la carga de datos, se podría modelar con un tipo personalizado como este:


type Profile

   = Failure

   | Loading

   | Success { name : String, description : String }


De esta forma, se puede empezar en el estado de carga y luego pasar a Failure o Success según lo que ocurra. Esto simplifica enormemente la creación de una función de vista que siempre muestre algo razonable cuando se cargan los datos.

Los tipos personalizados son la característica más importante de Elm. Ofrecen mucha profundidad, especialmente una vez que se adquiere el hábito de modelar escenarios con mayor precisión. 

¿Qué es un LLM y como empezamos a aprenderlo?


Un Large Language Model (LLM) es un modelo de inteligencia artificial entrenado con enormes volúmenes de texto para entender y generar lenguaje humano. Son la base de tecnologías como ChatGPT, Copilot o traductores automáticos avanzados.

Lo revolucionario de los LLMs es su capacidad para responder preguntas, escribir código, redactar textos, traducir, razonar y aprender patrones del lenguaje con una fluidez que antes parecía imposible.

Los LLMs no son solo una moda: están transformando la manera en que interactuamos con la información, automatizamos tareas y diseñamos productos inteligentes.


Y ¿Por dónde empezar? Libros para aprender sobre LLMs:

  • "Deep Learning" – Ian Goodfellow, Yoshua Bengio, Aaron Courville (Clásico, incluye fundamentos clave para entender redes profundas)
  • "Natural Language Processing with Transformers" – Lewis Tunstall, Leandro von Werra, Thomas Wolf (Excelente para entender cómo funcionan los LLMs modernos, como los de Hugging Face)
  • "Transformers for Natural Language Processing" – Denis Rothman  (Explica en detalle el modelo Transformer y cómo se aplica en NLP)
  • "The Hundred-Page Machine Learning Book" – Andriy Burkov  (Rápido, claro, cubre muchos fundamentos útiles para entender modelos como los LLMs)



Mensajes en Elm


En este post vimos un par de ejemplos de definición de un tipo Msg. Este tipo de tipo es muy común en Elm. En nuestra sala de chat, podríamos definir un tipo Msg de la siguiente manera:


type Msg

    = PressedEnter

    | ChangedDraft String

    | ReceivedMessage {user: User, message: String}

    | ClickedExit


Tenemos cuatro variantes. Algunas no tienen datos asociados, otras sí. Observe que ReceivedMessage tiene un registro como dato asociado. Esto es perfectamente correcto. ¡Cualquier tipo puede ser un dato asociado! Esto le permite describir las interacciones en su aplicación con mucha precisión.


Constructores de Registros en Elm


Al crear un alias de tipo específico para un registro, también se genera un constructor de registros. Por lo tanto, si definimos un alias de tipo Usuario, podemos empezar a construir registros de la siguiente manera:


> type alias Usuario = { nombre: String, edad: Int}


> Usuario

<función>: String -> Int -> Usuario


> Usuario "Sue" 58

{ nombre = "Sue", edad = 58}: Usuario


> Usuario "Tom" 31

{ nombre = "Tom", edad = 31}: Usuario


Ten en cuenta que el orden de los argumentos en el constructor de registros coincide con el orden de los campos en el alias de tipo.


Reiteramos que esto es solo para registros. Crear alias de tipo para otros tipos no generará un constructor.

viernes, 1 de agosto de 2025

Modelos en Elm


Es muy común usar alias de tipo al diseñar un modelo. Cuando estábamos aprendiendo sobre la arquitectura de Elm, vimos un modelo como este:


type alias Model =

  { name : String

  , password : String

  , passwordAgain : String

  }


La principal ventaja de usar un alias de tipo para esto es que al escribir las anotaciones de tipo para las funciones de actualización y vista, es mucho más fácil escribir Msg -> Modelo -> Modelo que la versión completa. Además, permite añadir campos a nuestro modelo sin necesidad de modificar ninguna anotación de tipo.

miércoles, 30 de julio de 2025

Alias de tipo en Elm


Las anotaciones de tipo pueden llegar a ser largas. Esto puede ser un verdadero problema si tiene registros con muchos campos. Esta es la razón principal de ser de los alias de tipo. Un alias de tipo es un nombre más corto para un tipo. Por ejemplo, podría crear un alias de usuario como este:


type alias User =

{ name : String, age : Int }


En lugar de escribir el tipo de registro completo constantemente, podemos simplemente escribir User. Esto nos ayuda a escribir anotaciones de tipo más fáciles de leer:


-- WITH ALIAS


isOldEnoughToVote : User -> Bool

isOldEnoughToVote user =

user.age >= 18


-- WITHOUT ALIAS


isOldEnoughToVote : { name : String, age : Int } -> Bool

isOldEnoughToVote user =

user.age >= 18


Estas dos definiciones son equivalentes, pero la que tiene un alias de tipo es más corta y fácil de leer. Entonces, lo único que estamos haciendo es crear un alias para un tipo largo.

martes, 29 de julio de 2025

Comparando obj != null, obj is { } y obj is not null en C#


En C#, hay varias formas de verificar si una variable no es null. Con la introducción de pattern matching, surgieron nuevas opciones como obj is { } y obj is not null. Aunque parecen equivalentes, no son exactamente lo mismo y conviene entender cuándo usar cada uno.


obj != null


Es la forma clásica de comprobar si una referencia no es null. Evalúa directamente la igualdad.


if (obj != null)

{

    // obj no es null

}


Cuándo usarlo:

  • Para chequeos simples de null.
  • En código tradicional o cuando la variable no participa en pattern matching.


Pero esto, no hace type test ni pattern matching. Solo evalúa igualdad.


obj is not null

Usa pattern matching para comprobar si la variable no es null.


if (obj is not null)

{

    // obj no es null

}


Cuándo usarlo:

  • Cuando querés mantener consistencia con otros patrones (`is int`, `is string s`, etc.).
  • Útil en expresiones más complejas con pattern matching.
  • Funciona igual que obj != null, pero es más expresivo en escenarios donde se usan patrones.


obj is { }


Este patrón comprueba que obj no sea null y coincida con un patrón de objeto.

{ } significa un objeto con cualquier valor de propiedades.


if (obj is { })

{

    // obj no es null

}


Cuándo usarlo:

  • Cuando querés usar pattern matching y, además, extraer propiedades en la misma expresión.


Ejemplo:


if (obj is { Nombre: var nombre, Edad: > 18 })

{

    Console.WriteLine($"{nombre} es mayor de edad");

}


¿Cuál es más performante?

obj != null : más rápido, es una simple comparación de referencia.

obj is not null: ligeramente más lento, pero casi idéntico (usa pattern matching internamente).

obj is { } : un poco más costoso porque implica verificar coincidencia de patrón de objeto.


Pero en la práctica, la diferencia de rendimiento es mínima y solo importa en código crítico (hot paths).


También se puede usar el operador null-coalescing (??):


var valor = obj ?? new MiObjeto();


O el null-conditional (?.):


obj?.Metodo();


Pero ese tema es para otro post ... 


lunes, 28 de julio de 2025

Variables de Tipo Restringidas en Elm


En Elm, existe una variante especial de variables de tipo llamadas variables de tipo restringido. El ejemplo más común es el tipo numérico. La función negate la utiliza:


> negate

<function> : number -> number


Normalmente, las variables de tipo se pueden rellenar con cualquier valor, pero number solo se puede rellenar con valores Int y Float. Esto limita las posibilidades.


La lista completa de variables de tipo restringido es:


number permite Int y Float

appendable permite String y List a

comparable permite Int, Float, Char, String y listas/tuplas de valores comparables

compappend permite String y List comparable

Estas variables de tipo restringido existen para que operadores como (+) y (<) sean un poco más flexibles.


miércoles, 23 de julio de 2025

Variables de tipo en elm


A medida que revise más código de Elm, comenzará a ver anotaciones de tipo con letras minúsculas. Un ejemplo común es la función List.length:


> List.length

<función> : Lista a -> Int


¿Observa la a minúscula en el tipo? Esto se denomina variable de tipo. Puede variar según cómo se use List.length:


> List.length [1,1,2,3,5,8]

6 : Int


> List.length [ "a", "b", "c" ]

3 : Int


> List.length [ Verdadero, Falso ]

2 : Int


Solo necesitamos la longitud, así que no importa el contenido de la lista. Por lo tanto, la variable de tipo a indica que podemos coincidir con cualquier tipo. Veamos otro ejemplo común:


> List.reverse

<función>: Lista a -> Lista a


> List.reverse [ "a", "b", "c" ]

["c","b","a"] : List String


> List.reverse [ Verdadero, Falso ]

[Falso, Verdadero] : List Bool


De nuevo, el tipo de variable a puede variar según cómo se use List.reverse. Pero en este caso, tenemos una a en el argumento y en el resultado. Esto significa que si se proporciona un Int de lista, también se debe obtener un Int de lista. Una vez que definimos qué es a, eso es lo que es en todas partes.

Las variables de tipo deben comenzar con una letra minúscula, pero pueden ser palabras completas. Podríamos escribir el tipo de List.length como List value -> Int y podríamos escribir el tipo de List.reverse como List element -> List element. Esto es correcto siempre que comiencen con una letra minúscula. Las variables de tipo a y b se utilizan por convención en muchos lugares, pero algunas anotaciones de tipo se benefician de nombres más específicos.

lunes, 21 de julio de 2025

Anotaciones de tipo en Elm


Hasta ahora, solo hemos dejado que Elm determine los tipos, pero también permite escribir una anotación de tipo en la línea superior a una definición. Así, al escribir código, se pueden escribir cosas como esta:


half: Float -> Float

half n =

n / 2


-- half 256 == 128

-- half "3" -- ¡error!


hypotenuse: Float -> Float -> Float

hypotenuse a b =

sqrt (a^2 + b^2)


-- hypotenuse 3 4 == 5

-- hypotenuse 5 12 == 13


checkPower: Int -> String

checkPower powerLevel =

if powerLevel > 9000 then "¡Es más de 9000!" else "Meh"


-- checkPower 9001 == "¡Es más de 9000!"

-- checkPower True -- ¡error! 


Añadir anotaciones de tipo no es obligatorio, ¡pero sí muy recomendable! 


Beneficios:

  • Calidad del mensaje de error: Al añadir una anotación de tipo, se le indica al compilador lo que se intenta hacer. La implementación puede tener errores, y ahora el compilador puede compararla con la intención establecida. "¡Dijiste que el argumento powerLevel era un Int, pero se está usando como String!".
  • Documentación: Al revisar el código posteriormente (o cuando un compañero lo consulta por primera vez), puede ser muy útil ver exactamente qué entra y sale de la función sin tener que leer la implementación con mucho cuidado.

Sin embargo, se pueden cometer errores con las anotaciones de tipo, así que ¿qué ocurre si la anotación no coincide con la implementación? El compilador determina todos los tipos por sí solo y comprueba que la anotación coincida con la respuesta real. En otras palabras, el compilador siempre verificará que todas las anotaciones que se añadan sean correctas. Así, se obtienen mejores mensajes de error y la documentación se mantiene siempre actualizada.

martes, 15 de julio de 2025

Operador |> en Elm


Elm también tiene un operador de canalización que se basa en la aplicación parcial. Por ejemplo, supongamos que tenemos una función de sanitización para convertir la entrada del usuario en enteros:


sanitize : String -> Maybe Int

sanitize input =

String.toInt (String.trim input)


Podemos reescribirlo así:


sanitize : String -> Maybe Int

sanitize input =

input

|> String.trim

|> String.toInt


En esta "canalización", pasamos la entrada a String.trim y luego esta a String.toInt.


Esto es útil porque permite una lectura de izquierda a derecha que a muchos les gusta. Cuando tienes tres o cuatro pasos, el código suele ser más claro si se desglosa una función auxiliar de nivel superior. Ahora la transformación tiene un nombre. Los argumentos tienen nombre. Tiene una anotación de tipo. De esta manera, se autodocumenta mucho mejor, ¡y tus compañeros de equipo y tu yo futuro lo agradecerán! Probar la lógica también se vuelve más fácil.

lunes, 14 de julio de 2025

Tipos de funciones en Elm


Veamos el tipo de algunas funciones:


> String.length

<función> : String -> Int


La función String.length es de tipo String -> Int. Esto significa que debe aceptar un argumento String y,  devolverá un valor Int. Intentemos asignarle un argumento:


> String.length "Supercalifragilisticexpialidocious"

34 : Int


Empezamos con una función String -> Int y le asignamos un argumento String. Esto da como resultado un valor Int.

Las funciones que aceptan varios argumentos terminan teniendo cada vez más flechas. Por ejemplo, aquí hay una función que toma dos argumentos:


> String.repeat

<función> : Int -> String -> String


Dar dos argumentos como String.repeat 3 "ja" producirá "jajaja". Parece que "->" es una forma extraña de separar argumentos, pero esto tiene una razón.  

Al revisar paquetes como elm/core y elm/html, seguramente verá funciones con múltiples flechas. Por ejemplo:


String.repeat: Int -> String -> String

String.join: String -> List String -> String

¿Por qué tantas flechas? ¿Qué está pasando?


Se vuelve más claro al ver todos los paréntesis. Por ejemplo, también es válido escribir el tipo de String.repeat así:


String.repeat: Int -> (String -> String)

Es una función que toma un entero y luego produce otra función. Veamos esto en acción:


> String.repeat

<función> : Int -> String -> String


> String.repeat 4

<función> : String -> String


> String.repeat 4 "ha"

"hahahaha" : String


> String.join

<función> : String -> List String -> String


> String.join "|"

<función> : List String -> String


> String.join "|" ["rojo","amarillo","verde"]

"rojo|amarillo|verde" : String


Conceptualmente, cada función acepta un argumento. Puede devolver otra función que acepte un argumento, etc. En algún momento, dejará de devolver funciones.

Siempre podríamos poner los paréntesis para indicar que esto es lo que realmente sucede, pero empieza a ser bastante complicado cuando se tienen varios argumentos. Es la misma lógica detrás de escribir 4 * 2 + 5 * 3 en lugar de (4 * 2) + (5 * 3). Esto significa que hay algo más que aprender, pero es tan común que vale la pena.

Bien, pero ¿cuál es el propósito de esta función en primer lugar? ¿Por qué no usar (Int, String) -> String y proporcionar todos los argumentos a la vez?


Es bastante común usar la función List.map en programas Elm:


List.map : (a -> b) -> List a -> List b


Toma dos argumentos: una función y una lista. A partir de ahí, transforma cada elemento de la lista con esa función. Aquí hay algunos ejemplos:


List.map String.reverse ["part","are"] == ["trap","era"]

List.map String.length ["part","are"] == [4,3]


¿Recuerdas cómo String.repeat 4 tenía el tipo String -> String por sí solo? Bueno, eso significa que podemos decir:


List.map (String.repeat 2) ["ha","choo"] == ["haha","choochoo"]

La expresión (String.repeat 2) es una función String -> String, por lo que podemos usarla directamente. No es necesario decir (\str -> String.repeat 2 str).

Elm también utiliza la convención de que la estructura de datos siempre es el último argumento en todo el ecosistema. Esto significa que las funciones suelen diseñarse teniendo en cuenta este posible uso, lo que la convierte en una técnica bastante común.

Es importante recordar que esto puede abusar. A veces es conveniente y claro, pero creo que es mejor usarlo con moderación. Por eso, siempre recomiendo desglosar las funciones auxiliares de alto nivel cuando las cosas se complican un poco. De esta manera, tiene un nombre claro, los argumentos tienen nombre y es fácil probar esta nueva función auxiliar. En nuestro ejemplo, esto significa crear:


-- List.map reduplicate ["ha","choo"]


reduplicar : String -> String

reduplicar string =

String.repeat 2 string


Este caso es muy simple, pero (1) ahora está más claro que me interesa el fenómeno lingüístico conocido como reduplicación y (2) será bastante fácil añadir nueva lógica a la reduplicación a medida que mi programa evolucione. 

En otras palabras, si su aplicación parcial se está haciendo larga, conviértala en una función auxiliar. Y si es multilínea, ¡definitivamente debería convertirse en una función auxiliar de alto nivel! Este consejo también aplica al uso de funciones anónimas.

domingo, 13 de julio de 2025

Mapeo de Herencia en JPA


JPA ofrece 3 estrategias principales para mapear la herencia :


@Inheritance(strategy = SINGLE_TABLE) : Todo se guarda en una sola tabla con una columna discriminadora. 

@Inheritance(strategy = JOINED): Se usa una tabla por clase, relacionadas por claves foráneas.        

@Inheritance(strategy = TABLE_PER_CLASS): Una tabla para cada clase, sin relaciones.                           


Veamos un ejemplo usando la estrategia: SINGLE_TABLE.



package com.ejemplo.demo.entidad;

import jakarta.persistence.*;


@Entity

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

@DiscriminatorColumn(name = "tipo_empleado", discriminatorType = DiscriminatorType.STRING)

public abstract class Empleado {


    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;


    private String nombre;

    // Getters y setters

}


@Inheritance(...): Define la estrategia de herencia.

@DiscriminatorColumn(...):  Crea una columna adicional (tipo_empleado) que almacena el tipo real de cada instancia.


📄 Gerente.java

package com.ejemplo.demo.entidad;


import jakarta.persistence.*;


@Entity

@DiscriminatorValue("GERENTE")

public class Gerente extends Empleado {


    private String departamento;

    // Getters y setters

}


📄 Desarrollador.java


package com.ejemplo.demo.entidad;


import jakarta.persistence.*;


@Entity

@DiscriminatorValue("DESARROLLADOR")

public class Desarrollador extends Empleado {


    private String lenguajeFavorito;

    // Getters y setters

}


Se crea una única tabla empleado, con las columnas:

id, nombre, departamento, lenguajeFavorito y tipo_empleado (con valores como GERENTE, DESARROLLADOR)


Ventajas de SINGLE_TABLE

    • Más simple y rápida para consultas.

    • Ideal si la mayoría de los campos son comunes.


Desventajas

    • Muchos campos nulos en columnas que sólo usa una subclase.


Otras estrategias: 

    • JOINED: separa en tablas, y junta usando claves foráneas. Útil si los datos son muy distintos y no querés campos nulos.

    • TABLE_PER_CLASS: evita JOINs, y es util cuando no necesitas hacer consultas a nivel de clase padre. 


En conclusión SINGLE_TABLE lo usamos cuando tenemos herencia la cual las clases hijas no agregan muchos o ningun dato. JOINED cuando queremos hacer consultas a nivel clase padre y tenemos muchos datos diferentes y TABLE_PER_CLASS cuando no necesitamos hacer query a nivel clase padre. 

sábado, 12 de julio de 2025

Tipos en Elm parte 2


Seguimos con los tipos de datos en ELM. Ingresemos algunas expresiones simples y veamos qué sucede:


> "hello"

"hello" : String


> not True

False : Bool


> round 3.1415

3 : Int



Bien, pero ¿qué ocurre exactamente? Cada entrada muestra el valor y su tipo. Puedes leer estos ejemplos en voz alta así:

  • El valor "hello" es una cadena.
  • El valor "False" es un booleano.
  • El valor 3 es un entero.
  • El valor 3.1415 es un float.
¡Elm puede determinar el tipo de cualquier valor que introduzcas! Veamos qué ocurre con las listas:

> [ "Alice", "Bob" ]
["Alice","Bob"] : List String

> [ 1.0, 8.6, 42.1 ]
[1.0,8.6,42.1] : List Float

Estos tipos se pueden interpretar como:
  1. Tenemos una lista con valores de cadena.
  2. Tenemos una lista con valores de coma flotante.
El tipo es una descripción aproximada del valor específico que estamos analizando.

lunes, 7 de julio de 2025

Mapeo de Herencia en JPA


JPA ofrece 3 estrategias para mapear herencia:

  • @Inheritance(strategy = SINGLE_TABLE) : Todo se guarda en una sola tabla con una columna discriminadora. 
  • @Inheritance(strategy = JOINED): Se usa una tabla por clase, relacionadas por claves foráneas.        
  • @Inheritance(strategy = TABLE_PER_CLASS): Una tabla para cada clase, sin relaciones.                           

Veamos un ejemplo: Clase base y subclases

Vamos a usar la estrategia: SINGLE_TABLE.


package com.ejemplo.demo.entidad;

import jakarta.persistence.*;


@Entity

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

@DiscriminatorColumn(name = "tipo_empleado", discriminatorType = DiscriminatorType.STRING)

public abstract class Empleado {


    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;

    private String nombre;


    // Getters y setters

}


@Inheritance(...): Define la estrategia de herencia.

@DiscriminatorColumn(...):  Crea una columna adicional (tipo_empleado) que almacena el tipo real de cada instancia.


📄 Gerente.java


package com.ejemplo.demo.entidad;


import jakarta.persistence.*;


@Entity

@DiscriminatorValue("GERENTE")

public class Gerente extends Empleado {


    private String departamento;


    // Getters y setters

}


📄 Desarrollador.java


package com.ejemplo.demo.entidad;


import jakarta.persistence.*;


@Entity

@DiscriminatorValue("DESARROLLADOR")

public class Desarrollador extends Empleado {


    private String lenguajeFavorito;


    // Getters y setters

}


Resultado en la base de datos


Se crea una única tabla empleado, con las columnas:

id, nombre, departamento, lenguajeFavorito y tipo_empleado (con valores como GERENTE, DESARROLLADOR)


Ventajas de SINGLE_TABLE

    • Más simple y rápida para consultas.

    • Ideal si la mayoría de los campos son comunes.

Desventajas

    • Muchos campos nulos en columnas que sólo usa una subclase.


Otras estrategias: 

    • JOINED: separa en tablas, y junta usando claves foráneas. Útil si los datos son muy distintos y no querés campos nulos.

    • TABLE_PER_CLASS: evita JOINs, pero no es tan usada. No permite relaciones polimórficas fácilmente.