LangChain4j: IA Generativa en Java

LangChain4j es un poderoso framework para construir aplicaciones de inteligencia artificial generativa en Java. Inspirado en el popular LangChain para Python y JavaScript, este marco permite integrar modelos de lenguaje como OpenAI GPT, Llama, o Hugging Face con herramientas avanzadas, flujos de trabajo y procesamiento dinámico.

LangChain4j proporciona herramientas para manejar modelos de lenguaje de manera modular y escalable. Algunas de sus características destacadas incluyen:

• Integración de Modelos de Lenguaje (LLMs): Interactúa fácilmente con GPT-4, GPT-3, o modelos personalizados.
• Encadenamiento de Operaciones: Diseña flujos complejos combinando varios modelos y herramientas.
• Contexto Extendido: Utiliza almacenamiento vectorial para manejar contextos largos.
• Herramientas de Razonamiento y Extracción: Construye aplicaciones como chatbots avanzados, asistentes de búsqueda, o sistemas de recomendación.

Antes de comenzar, agrega la dependencia en tu proyecto Maven o Gradle:

Veamos la dependencia de maven:

<dependency>

    <groupId>com.langchain4j</groupId>

    <artifactId>langchain4j-core</artifactId>

    <version>1.0.0</version>

</dependency>

o gradle:

implementation 'com.langchain4j:langchain4j-core:1.0.0'

Veamos un cliente básico para interactuar con OpenAI GPT:

import com.langchain4j.LangChain;

import com.langchain4j.llm.OpenAiClient;

public class LangChainExample {

    public static void main(String[] args) {

        OpenAiClient client = OpenAiClient.builder()

                .apiKey("tu-api-key")

                .build();

        String response = client.chat("¿Qué es LangChain4j?");

        System.out.println("Respuesta: " + response);

    }

}

Este ejemplo muestra cómo enviar una consulta y recibir una respuesta usando OpenAI GPT.

LangChain4j soporta herramientas como cadenas de procesamiento (`Chains`) para flujos más complejos.

Veamos un ejemplo de un Flujo con Memoria:

import com.langchain4j.chain.ConversationChain;

import com.langchain4j.memory.InMemoryMemory;

public class ConversationExample {

    public static void main(String[] args) {

        ConversationChain conversation = ConversationChain.builder()

                .llm(OpenAiClient.builder().apiKey("tu-api-key").build())

                .memory(new InMemoryMemory())

                .build();

        System.out.println(conversation.chat("Hola, ¿quién eres?"));

        System.out.println(conversation.chat("¿Recuerdas mi nombre?"));

    }

}

Aquí, InMemoryMemory permite que el modelo recuerde las interacciones previas.

LangChain4j admite almacenamiento vectorial, útil para aplicaciones de búsqueda semántica o contextos largos.

import com.langchain4j.vector.PineconeVectorStore;

public class VectorStoreExample {

    public static void main(String[] args) {

        PineconeVectorStore vectorStore = PineconeVectorStore.builder()

                .apiKey("tu-api-key")

                .environment("us-west1-gcp")

                .build();

        vectorStore.add("doc1", "Este es un ejemplo de texto.");

        System.out.println(vectorStore.search("texto relacionado", 1));

    }

}

LangChain4j extiende las capacidades de los modelos de lenguaje para aplicaciones empresariales en Java. Con su enfoque modular, herramientas avanzadas, y soporte para almacenamiento vectorial, se posiciona como una opción clave para proyectos de IA generativa en el ecosistema Java.

Y falto decir que se puede integrar con spring y otros frameworks, pero eso lo voy a dejar para otro post... 

Dejo link: https://docs.langchain4j.dev/

Grafos dirigidos en Erlang

Los grafos dirigidos en Erlang se implementan como dos módulos, digraph y digraph_utils. El módulo digraph básicamente permite la construcción y modificación de un grafo dirigido: manipular aristas y vértices, encontrar caminos y ciclos, etc. Por otro lado, digraph_utils permite navegar por un grafo (postorder, preorder), probar ciclos, arborescencias o árboles, encontrar vecinos, etc.

En Erlang, los grafos dirigidos se implementan utilizando los módulos digraph y digraph_utils, que forman parte de la librería estándar. Aquí tienes ejemplos de cómo usarlos:

El módulo digraph permite crear y manipular grafos. Veamos un ejemplo básico:

-module(digraph_example).

-export([create_graph/0, add_nodes_and_edges/1, print_graph/1]).

create_graph() ->

    digraph:new().

add_nodes_and_edges(Graph) ->

    % Agregar nodos

    Node1 = digraph:add_vertex(Graph, node1, "Nodo 1"),

    Node2 = digraph:add_vertex(Graph, node2, "Nodo 2"),

    Node3 = digraph:add_vertex(Graph, node3, "Nodo 3"),

    

    % Agregar aristas dirigidas

    digraph:add_edge(Graph, Node1, Node2),

    digraph:add_edge(Graph, Node2, Node3),

    digraph:add_edge(Graph, Node1, Node3),

    Graph.

print_graph(Graph) ->

    Vertices = digraph:vertices(Graph),

    Edges = digraph:edges(Graph),

    io:format("Nodos: ~p~n", [Vertices]),

    io:format("Aristas: ~p~n", [Edges]).

Veamos como podemos usarlo: 

1> c(digraph_example).

2> Graph = digraph_example:create_graph().

3> Graph = digraph_example:add_nodes_and_edges(Graph).

4> digraph_example:print_graph(Graph).

Nodos: [#Ref<0.0.0.247>,#Ref<0.0.0.248>,#Ref<0.0.0.249>]

Aristas: [#Ref<0.0.0.250>,#Ref<0.0.0.251>,#Ref<0.0.0.252>]

El módulo digraph_utils provee funciones para analizar y transformar grafos, como encontrar caminos, ciclos, o calcular componentes conexas.

find_path_example() ->

    Graph = digraph:new(),

    Node1 = digraph:add_vertex(Graph, node1),

    Node2 = digraph:add_vertex(Graph, node2),

    Node3 = digraph:add_vertex(Graph, node3),

    digraph:add_edge(Graph, Node1, Node2),

    digraph:add_edge(Graph, Node2, Node3),

    Path = digraph_utils:path(Graph, Node1, Node3),

    io:format("Camino de Node1 a Node3: ~p~n", [Path]),

    digraph:delete(Graph).

1> c(digraph_example).

2> digraph_example:find_path_example().

Camino de Node1 a Node3: [node1,node2,node3]

Para detectar ciclos en un grafo dirigido:

detect_cycle_example() ->

    Graph = digraph:new(),

    Node1 = digraph:add_vertex(Graph, node1),

    Node2 = digraph:add_vertex(Graph, node2),

    digraph:add_edge(Graph, Node1, Node2),

    digraph:add_edge(Graph, Node2, Node1),

    Cycles = digraph_utils:strong_components(Graph),

    io:format("Ciclos detectados: ~p~n", [Cycles]),

    digraph:delete(Graph).

1> digraph_example:detect_cycle_example().

Ciclos detectados: [[node1,node2]]

digraph es eficiente para representar grafos con un gran número de nodos y aristas.

digraph_utils complementa digraph con funciones analíticas, como encontrar componentes fuertes o caminos mínimos.

Debido a que los grafos dirigidos están estrechamente relacionados con la teoría de conjuntos, el módulo sofs contiene algunas funciones que permiten convertir familias en dígrafos y dígrafos en familias.

Tipos de Polimorfismo en C++

El polimorfismo es uno de los pilares fundamentales de la programación orientada a objetos (POO) y permite a los objetos comportarse de diferentes maneras según el contexto. En C++, C# y Java y casi cualquier lenguaje orientado a objetos, se manifiesta principalmente de dos formas: en tiempo de compilación y en tiempo de ejecución.

Polimorfismo en Tiempo de Compilación (Static Polymorphism): Este tipo de polimorfismo ocurre cuando la decisión sobre qué función ejecutar se toma en tiempo de compilación. En C++, se logra a través de sobrecarga de funciones y plantillas (o template).

Se define más de una función con el mismo nombre pero diferentes parámetros.

#include <iostream>

using namespace std;

void imprimir(int x) {

    cout << "Número entero: " << x << endl;

}

void imprimir(double x) {

    cout << "Número decimal: " << x << endl;

}

int main() {

    imprimir(10);       // Llama a la versión para enteros

    imprimir(3.14);     // Llama a la versión para dobles

    return 0;

}

Las plantillas permiten definir funciones o clases genéricas que trabajan con diferentes tipos de datos.

#include <iostream>

using namespace std;

template <typename T>

void imprimir(T x) {

    cout << "Valor: " << x << endl;

}

int main() {

    imprimir(10);       // Entero

    imprimir(3.14);     // Decimal

    imprimir("Hola");   // Cadena de texto

    return 0;

}

Polimorfismo en Tiempo de Ejecución (Dynamic Polymorphism): Este tipo de polimorfismo ocurre cuando la decisión sobre qué función ejecutar se toma en tiempo de ejecución. En C++, esto se logra mediante herencia y métodos virtuales.

Los métodos virtuales permiten que una clase derivada sobrescriba el comportamiento de una función definida en la clase base.

#include <iostream>

using namespace std;

class Forma {

public:

    virtual void dibujar() {

        cout << "Dibujar una forma genérica" << endl;

    }

};

class Circulo : public Forma {

public:

    void dibujar() override {

        cout << "Dibujar un círculo" << endl;

    }

};

class Cuadrado : public Forma {

public:

    void dibujar() override {

        cout << "Dibujar un cuadrado" << endl;

    }

};

int main() {

    Forma* forma;

    Circulo circulo;

    Cuadrado cuadrado;

    forma = &circulo;

    forma->dibujar();   // Llama al método de Circulo

    forma = &cuadrado;

    forma->dibujar();   // Llama al método de Cuadrado

    return 0;

}

Si una clase tiene al menos un método virtual puro, se convierte en una clase abstracta y no puede ser instanciada directamente.

#include <iostream>

using namespace std;

class Forma {

public:

    virtual void dibujar() = 0; // Método virtual puro

};

class Triangulo : public Forma {

public:

    void dibujar() override {

        cout << "Dibujar un triángulo" << endl;

    }

};

int main() {

    Forma* forma = new Triangulo();

    forma->dibujar(); // Llama al método de Triangulo

    delete forma;

    return 0;

}

El polimorfismo es una herramienta esencial en C++, que ofrece flexibilidad y reutilización de código. El polimorfismo estático es ideal para optimizar el rendimiento, mientras que el polimorfismo dinámico es crucial para diseños extensibles y adaptables.

Set en Erlang

Hay 4 módulos principales para tratar con conjuntos en Erlang. Esto es un poco raro al principio, pero tiene más sentido una vez que te das cuenta de que se debe a que los implementadores acordaron que no había una "mejor" manera de construir un conjunto. Los cuatro módulos son ordsets, sets, gb_sets y sofs (conjuntos de conjuntos):

ordsets

Los ordsets se implementan como una lista ordenada. Son principalmente útiles para conjuntos pequeños, son el tipo de conjunto más lento, pero tienen la representación más simple y legible de todos los conjuntos. Hay funciones estándar para ellos como ordsets:new/0, ordsets:is_element/2, ordsets:add_element/2, ordsets:del_element/2, ordsets:union/1, ordsets:intersection/1, y muchas más.

sets

Sets (el módulo) se implementa sobre una estructura muy similar a la que se usa en dict. Implementan la misma interfaz que ordsets, pero se escalarán mucho mejor. Al igual que los diccionarios, son especialmente buenos para manipulaciones de lectura intensiva, como verificar si algún elemento es parte del conjunto o no.

gb_sets

Los gb_sets en sí se construyen sobre una estructura de árbol general equilibrado similar a la que se usa en el módulo gb_trees. gb_sets es a los conjuntos lo que gb_tree es a dict; una implementación que es más rápida al considerar operaciones diferentes a la lectura, lo que le permite tener más control. Si bien gb_sets implementa la misma interfaz que sets y ordsets, también agrega más funciones. Al igual que gb_trees, tiene funciones inteligentes contra ingenuas, iteradores, acceso rápido a los valores más pequeños y más grandes, etc.

sofs

Los conjuntos de conjuntos (sofs) se implementan con listas ordenadas, pegadas dentro de una tupla con algunos metadatos. Son el módulo que se debe usar si desea tener control total sobre las relaciones entre conjuntos, familias, imponer tipos de conjuntos, etc. Son realmente lo que desea si necesita un concepto matemático en lugar de "solo" grupos de elementos únicos.

Si bien tal variedad puede verse como algo grandioso, algunos detalles de implementación pueden ser francamente frustrantes. Como ejemplo, gb_sets, ordsets y sofs usan el operador == para comparar valores: si tiene los números 2 y 2.0, ambos terminarán siendo vistos como el mismo.

Sin embargo, sets (el módulo) utiliza el operador =:=, lo que significa que no necesariamente puedes cambiar de implementación como desees. Hay casos en los que necesitas un comportamiento preciso y, en ese punto, puedes perder el beneficio de tener múltiples implementaciones.

Es un poco confuso tener tantas opciones disponibles. Björn Gustavsson, del equipo Erlang/OTP y programador de Wings3D, sugiere principalmente usar gb_sets en la mayoría de las circunstancias, usar ordset cuando necesitas una representación clara que quieres procesar con tu propio código y 'sets' cuando necesitas el operador =:= (fuente).

En cualquier caso, al igual que para los almacenes de valores clave, la mejor solución suele ser realizar una evaluación comparativa y ver qué se adapta mejor a tu aplicación.

¿Cómo Crear una Librería en Elixir?

Elixir es un lenguaje poderoso y flexible, ideal para crear librerías reutilizables. En esta guía, aprenderás cómo iniciar y publicar tu propia librería.

1. Inicializando el Proyecto

Para empezar, crea un nuevo proyecto con mix:

mix new mi_libreria --module MiLibreria

Esto generará una estructura básica con carpetas como `lib` (para el código) y `mix.exs` (configuración del proyecto).  

En el archivo `mix.exs`, ajusta la metadata básica, como nombre y descripción, para que sea más descriptiva:

def project do

  [

    app: :mi_libreria,

    version: "0.1.0",

    elixir: "~> 1.15",

    description: "Una librería simple para manipular cadenas",

    start_permanent: Mix.env() == :prod

  ]

end

2. Implementando la Funcionalidad

Agregamos lógica en lib/mi_libreria.ex. Por ejemplo, una función para convertir cadenas a mayúsculas:

defmodule MiLibreria do

  @moduledoc """

  MiLibreria es una colección de funciones útiles para cadenas.

  """

  @doc """

  Convierte una cadena en mayúsculas.

  ## Ejemplo

      iex> MiLibreria.convertir_mayusculas("hola")

      "HOLA"

  """

  def convertir_mayusculas(cadena) when is_binary(cadena) do

    String.upcase(cadena)

  end

end

La documentación (`@moduledoc` y `@doc`) ayuda a otros desarrolladores a entender y usar tu librería.

3. Generando Documentación con ExDoc

Añade `ExDoc` al archivo `mix.exs` para generar documentación en HTML:

{:ex_doc, "~> 0.29", only: :dev, runtime: false}

Instala las dependencias:

mix deps.get

Genera la documentación:

mix docs

Esto crea una carpeta `doc` con una versión navegable de tu documentación.

4. Publicando en Hex

Crea una cuenta en Hex.pm:

   Tenemos que registrarnos en Hex.pm y genera una clave de autenticación con:  

   mix hex.user register

Completa la Metadata en mix.exs:

   def project do

     [

       app: :mi_libreria,

       version: "0.1.0",

       description: "Librería para manipulación de cadenas",

       package: package_info()

     ]

   end

   defp package_info do

     [

       maintainers: ["Tu Nombre"],

       licenses: ["MIT"],

       links: %{"GitHub" => "https://github.com/tu_usuario/mi_libreria"}

     ]

   end

  Publica la librería:

   mix hex.publish

Crear una librería en Elixir es sencillo y gratificante. Con estas herramientas y pasos, puedes compartir tu trabajo con la comunidad y contribuir al crecimiento del ecosistema. 

Matrices en erlang

Pero, ¿qué sucede con el código que requiere estructuras de datos con nada más que claves numéricas? Bueno, para eso, existen las matrices. Permiten acceder a elementos con índices numéricos y plegar toda la estructura, ignorando posiblemente las ranuras no definidas.

Las matrices de Erlang, al contrario de sus contrapartes imperativas, no pueden tener cosas como inserción o búsqueda en tiempo constante. Debido a que suelen ser más lentas que las de los lenguajes que admiten la asignación destructiva y que el estilo de programación realizado con Erlang no se presta necesariamente demasiado bien a las matrices y matrices, rara vez se utilizan en la práctica.

En general, los programadores de Erlang que necesitan realizar manipulaciones de matrices y otros usos que requieren matrices tienden a utilizar conceptos llamados Puertos para dejar que otros lenguajes hagan el trabajo pesado, o C-Nodos, Linked in drivers y NIF (Experimental, R13B03+).

Las matrices también son extrañas en el sentido de que son una de las pocas estructuras de datos que tienen un índice 0 (al contrario de las tuplas o listas), junto con el índice en el módulo de expresiones regulares.

Veamos un ejemplo: 

  %% Create a fixed-size array with entries 0-9 set to 'undefined'

  A0 = array:new(10).

  10 = array:size(A0).

 

  %% Create an extendible array and set entry 17 to 'true',

  %% causing the array to grow automatically

  A1 = array:set(17, true, array:new()).

  18 = array:size(A1).

 

  %% Read back a stored value

  true = array:get(17, A1).

 

  %% Accessing an unset entry returns the default value

  undefined = array:get(3, A1).

 

  %% Accessing an entry beyond the last set entry also returns the

  %% default value, if the array does not have fixed size

  undefined = array:get(18, A1).

 

  %% "sparse" functions ignore default-valued entries

  A2 = array:set(4, false, A1).

  [{4, false}, {17, true}] = array:sparse_to_orddict(A2).

 

  %% An extendible array can be made fixed-size later

  A3 = array:fix(A2).

 

  %% A fixed-size array does not grow automatically and does not

  %% allow accesses beyond the last set entry

  {'EXIT',{badarg,_}} = (catch array:set(18, true, A3)).

  {'EXIT',{badarg,_}} = (catch array:get(18, A3)).

C++ : range-based for loop (o foreach para los amigos)

C++ 11 ofrece una forma más sencilla y legible de iterar sobre los elementos de un contenedor, como un vector, list o set. Se introdujo en C++11 con el nombre de "range-based for loop" (pero yo le voy a llamar foreach) y ha ganado popularidad por su simplicidad y expresividad.

La estructura básica es:

for (declaración : contenedor) {

    // cuerpo del ciclo

}

• declaración: Representa cada elemento del contenedor.
• contenedor: Es una estructura iterable, como std::vector, std::list, o incluso un arreglo C++.

Imaginemos un vector de enteros. Con foreach, iteramos de esta forma:

#include <iostream>

#include <vector>

int main() {

    std::vector<int> numeros = {1, 2, 3, 4, 5};

    for (int numero : numeros) {

        std::cout << numero << " ";

    }

    return 0;

}

Salida: 1 2 3 4 5

Si deseas modificar los elementos dentro del bucle, usa una referencia (`&`):

#include <iostream>

#include <vector>

int main() {

    std::vector<int> numeros = {1, 2, 3, 4, 5};

    for (int& numero : numeros) {

        numero *= 2; // Duplicar cada valor

    }

    for (int numero : numeros) {

        std::cout << numero << " ";

    }

    return 0;

}

Salida: 2 4 6 8 10

En un std::map, cada elemento es un par clave-valor (std::pair). Puedes acceder a ellos directamente:

#include <iostream>

#include <map>

int main() {

    std::map<std::string, int> edades = {{"Alice", 30}, {"Bob", 25}, {"Charlie", 35}};

    for (const auto& [nombre, edad] : edades) {

        std::cout << nombre << ": " << edad << "\n";

    }

    return 0;

}

Salida:

Alice: 30

Bob: 25

Charlie: 35

Como limitaciones tenemos:

1. Elementos no modificables: Sin una referencia explícita, no puedes modificar los elementos del contenedor.
2. No apto para todos los contenedores: Aunque funciona con la mayoría de las estructuras estándar, asegúrate de que el contenedor sea compatible con iteradores.
3. Iteración sobre arreglos estáticos: También es compatible con arreglos tradicionales:

   int numeros[] = {1, 2, 3, 4};

   for (int numero : numeros) {

       std::cout << numero << " ";

   }

El foreach en C++ simplifica la iteración y mejora la legibilidad del código. 

Ecto = bases de datos + Elixir

Ecto es la herramienta principal para interactuar con bases de datos en el ecosistema de Elixir. Más que un simple ORM, Ecto combina la construcción de consultas, validaciones y migraciones, brindando una experiencia robusta y funcional.

Ecto es un toolkit para bases de datos en Elixir que se compone de tres partes principales:

• Ecto.Schema: Define la estructura de los datos.
• Ecto.Changeset: Maneja validaciones y transformaciones.
• Ecto.Query: Facilita la construcción de consultas.

Para empezar debemos añadir las dependencias en mix.exs:

defp deps do

  [

    {:ecto_sql, "~> 3.10"},

    {:postgrex, ">= 0.0.0"} # Adaptador para PostgreSQL

  ]

end

Luego debemos configurar el repositorio en config/config.exs:

config :mi_app, MiApp.Repo,

  database: "mi_app_db",

  username: "usuario",

  password: "contraseña",

  hostname: "localhost"

config :mi_app, ecto_repos: [MiApp.Repo]

Crear el repositorio:

mix ecto.gen.repo -r MiApp.Repo

Para luego ejecutar migraciones iniciales:

mix ecto.create

Creamos un módulo para tu esquema, que representa una tabla en la base de datos:

defmodule MiApp.Usuario do

  use Ecto.Schema

  schema "usuarios" do

    field :nombre, :string

    field :email, :string

    field :edad, :integer

    timestamps()

  end

end

Y ahora hagamos consultas básicas con Ecto.Query. Ecto ofrece una sintaxis declarativa para construir consultas SQL. Ejemplo:

import Ecto.Query

# Obtener todos los usuarios

query = from u in "usuarios", select: u

MiApp.Repo.all(query)

# Filtrar usuarios mayores de 18 años

query = from u in MiApp.Usuario, where: u.edad > 18, select: u.nombre

MiApp.Repo.all(query)

Los cambios en los datos se gestionan con Ecto.Changeset, lo que facilita aplicar validaciones.

defmodule MiApp.Usuario do

  use Ecto.Schema

  import Ecto.Changeset

  schema "usuarios" do

    field :nombre, :string

    field :email, :string

    field :edad, :integer

    timestamps()

  end

  def cambios_usuario(usuario, attrs) do

    usuario

    |> cast(attrs, [:nombre, :email, :edad])

    |> validate_required([:nombre, :email])

    |> validate_format(:email, ~r/@/)

    |> validate_number(:edad, greater_than_or_equal_to: 0)

  end

end

Ecto permite definir relaciones como has_many, belongs_to y many_to_many. Veamos un ejemplo: 

defmodule MiApp.Usuario do

  use Ecto.Schema

  schema "usuarios" do

    field :nombre, :string

    has_many :posts, MiApp.Post

    timestamps()

  end

end

defmodule MiApp.Post do

  use Ecto.Schema

  schema "posts" do

    field :titulo, :string

    belongs_to :usuario, MiApp.Usuario

    timestamps()

  end

end

Consultas relacionales:

query = from u in MiApp.Usuario, preload: [:posts]

usuarios = MiApp.Repo.all(query)

Ahora actualización de registros:

usuario = MiApp.Repo.get(MiApp.Usuario, 1)

cambioset = MiApp.Usuario.cambios_usuario(usuario, %{nombre: "Nuevo Nombre"})

MiApp.Repo.update(cambioset)

Y Borramos:

usuario = MiApp.Repo.get(MiApp.Usuario, 1)

MiApp.Repo.delete(usuario)

Las migraciones permiten gestionar cambios en el esquema de la base de datos.

Crear una migración:

mix ecto.gen.migration crea_usuarios

Editar la migración:

defmodule MiApp.Repo.Migrations.CreaUsuarios do

  use Ecto.Migration

  def change do

    create table(:usuarios) do

      add :nombre, :string

      add :email, :string

      add :edad, :integer

      timestamps()

    end

  end

end

Ejecutar migración:

mix ecto.migrate

Ecto transforma la interacción con bases de datos en una experiencia declarativa, segura y extensible. Ya sea que estés manejando datos simples o esquemas complejos, Ecto te da las herramientas para hacerlo de manera eficiente.

Hola mundo en Pony

¡Comencemos a programar! Nuestro primer programa será uno muy tradicional. Vamos a imprimir “¡Hola, mundo!”. Primero, crea un directorio llamado helloworld:

mkdir helloworld

cd helloworld

¿Importa el nombre del directorio? Sí, importa. ¡Es el nombre de tu programa! De manera predeterminada, cuando tu programa es compilado, el binario ejecutable resultante tendrá el mismo nombre que el directorio en el que se encuentra tu programa. También puedes establecer el nombre usando las opciones –bin-name o -b en la línea de comandos.

Luego, crea un archivo en ese directorio llamado main.pony.

¿Importa el nombre del archivo? No para el compilador, no. A Pony no le importan los nombres de archivo, excepto que terminen en .pony. ¡Pero podría importarte a ti! Al darle buenos nombres a los archivos, puede ser más fácil encontrar el código que estás buscando más tarde.

En el archivo, pongamos el siguiente código:

actor Main

    new create(env: Env) =>

    env.out.print("¡Hola, mundo!")

Ahora compílarlo:

$ ponyc

Building .

Building builtin

Generating

Optimising

Writing ./helloworld.o

Linking ./helloworld

¡Mira eso! Compiló el directorio actual, ., más las cosas que están incorporadas en Pony, builtin, generó algo de código, lo optimizó, creó un archivo de objeto (no te preocupes si no sabes qué es eso) y lo vinculó a un ejecutable con las bibliotecas que se necesitaban. Si eres un programador de C/C++, todo esto tendrá sentido para ti, de lo contrario, probablemente no lo tenga, pero no importa, puedes ignorarlo.

Espera, ¿también se vinculó? Sí. No necesitarás un sistema de compilación (como make) para Pony. Se encarga de eso por ti (incluso de manejar el orden de las dependencias cuando te vinculas a bibliotecas de C, pero llegaremos a eso más adelante).

Ahora podemos ejecutar el programa:

$ ./helloworld

¡Hola, mundo!

¡Felicitaciones, hemos escrito nuestro primer programa Pony! 

Creación de pruebas en Elixir con ExUnit

ExUnit es el framework de pruebas integrado en Elixir, diseñado para ayudarte a escribir pruebas claras y efectivas. Desde pruebas unitarias hasta pruebas más complejas, ExUnit ofrece las herramientas necesarias para asegurar que tu código funcione como esperas.

ExUnit viene incluido con Elixir, por lo que no necesitas instalar dependencias adicionales. Solo asegúrate de que tu entorno de desarrollo esté configurado para ejecutarlas.

ExUnit.start()

Los archivos de pruebas suelen estar en el directorio test/ y deben tener el sufijo _test.exs.

Veamos un ejemplo: 

defmodule MiApp.MiModuloTest do

  use ExUnit.Case

  test "una prueba simple" do

    assert 1 + 1 == 2

  end

end

Para ejecutar las pruebas, utiliza:

mix test

Las aserciones son fundamentales para comprobar el comportamiento esperado. ExUnit ofrece varias:

- assert: Verifica que una condición sea verdadera.

- refute: Verifica que una condición sea falsa.

- assert_raise: Verifica que se lance una excepción específica.

Veamos algunos ejemplos: 

assert String.length("Hola") == 4

refute String.contains?("Hola", "mundo")

assert_raise ArgumentError, fn -> String.to_integer("no_numero") end

ExUnit permite convertir ejemplos en la documentación en pruebas automáticas.

defmodule MiModulo do

  @doc """

  Duplica un número.

  ## Ejemplo

      iex> MiModulo.duplicar(2)

      4

  """

  def duplicar(n), do: n * 2

end

defmodule MiModuloTest do

  use ExUnit.Case

  doctest MiModulo

end

Para organizar tus pruebas, podemos usar describe:

defmodule MiApp.MiModuloTest do

  use ExUnit.Case

  describe "función suma/2" do

    test "suma números positivos" do

      assert MiApp.MiModulo.suma(2, 3) == 5

    end

    test "suma números negativos" do

      assert MiApp.MiModulo.suma(-2, -3) == -5

    end

  end

end

Y podemos usar setup para definir configuraciones comunes:

defmodule MiApp.MiModuloTest do

  use ExUnit.Case

  setup do

    {:ok, numero: 42}

  end

  test "usa datos de setup", %{numero: numero} do

    assert numero == 42

  end

end

Elixir soporta pruebas concurrentes por defecto. Si necesitas pruebas asincrónicas, podemos indícarlo:

defmodule MiApp.AsyncTest do

  use ExUnit.Case, async: true

  test "prueba concurrente" do

    Task.async(fn -> :ok end)

    |> Task.await()

    |> assert == :ok

  end

end

ExUnit facilita capturar salidas a consola y logs:

import ExUnit.CaptureIO

test "captura salida de IO.puts" do

  salida = capture_io(fn -> IO.puts("Hola, mundo!") end)

  assert salida == "Hola, mundo!\n"

end

import ExUnit.CaptureLog

test "captura logs" do

  salida = capture_log(fn -> Logger.info("Esto es un log") end)

  assert salida =~ "Esto es un log"

end

Para ejecutar pruebas individuales, podemos usar:

mix test test/mi_modulo_test.exs:10

ExUnit es una herramienta flexible y poderosa para escribir pruebas en Elixir. Desde las pruebas más básicas hasta configuraciones avanzadas, te ayuda a mantener un código confiable y fácil de mantener. 

ca1860: Evite utilizar el método de extensión 'Enumerable.Any()'

Me llamo la atención un warnning en mi código C# que decia: "CA1860: Avoid using 'Enumerable.Any()' extension method" y yo dije why? y así nacio este post. 

Para determinar si un tipo de colección tiene algún elemento, es más eficiente y claro usar las propiedades Length, Count o IsEmpty (si es posible) que llamar al método Enumerable.Any.

Any(), que es un método de extensión, usa consultas integradas en lenguaje (LINQ). Es más eficiente confiar en las propiedades propias de la colección y también aclara la intención.

Otro tema es que esta regla es similar a CA1827: No use Count()/LongCount() cuando se pueda usar Any(). Sin embargo, esa regla se aplica al método Count() de Linq, mientras que esta regla sugiere usar la propiedad Count.

Veamos un poco de código: 

bool HasElements(string[] strings)

{

    return strings.Any(); // esto esta mal. 

}

bool HasElements(string[] strings)

{

    return strings.Length > 0; // esto esta bien. 

}

Lo que me dejo pensando es: entiendo que sea más performante no utilizar Any() siempre si tenemos propiedades como Count, Length o IsEmpty. Pero esto no es una desventaja a la hora de cambiar el tipo de colección? 

Podemos concluir que no esta bueno que un lenguaje nos ofrezca 2 o 3 formas de hacer lo mismo y luego nos este retando porque elegimos una. 

Dejo link:

https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1860

Listas por Comprensión en Python

Las listas por comprensión (o list comprehensions) son una característica poderosa y expresiva de Python que permite construir listas nuevas a partir de iterables existentes, todo ello en una sola línea de código. Son legibles, concisas y, a menudo, más eficientes que los bucles tradicionales.

Son una forma de crear listas en Python utilizando una sintaxis compacta basada en una expresión, un iterador y (opcionalmente) una condición.

Con la forma : [nueva_expresión for elemento in iterable if condición]

• nueva_expresión: La operación o transformación a aplicar a cada elemento.
• for elemento in iterable: Itera sobre los elementos de un iterable (como una lista o rango).
• if condición(opcional): Filtra los elementos según una condición.

Convertir una lista de números en sus cuadrados:

numeros = [1, 2, 3, 4, 5]

cuadrados = [n**2 for n in numeros]

print(cuadrados)

# Salida: [1, 4, 9, 16, 25]

Seleccionar solo los números pares antes de calcular sus cuadrados:

numeros = [1, 2, 3, 4, 5]

cuadrados_pares = [n**2 for n in numeros if n % 2 == 0]

print(cuadrados_pares)

# Salida: [4, 16]

Puedes llamar funciones dentro de la expresión:

nombres = ["Ana", "Bernardo", "Carla", "Diego"]

longitudes = [len(nombre) for nombre in nombres]

print(longitudes)

# Salida: [3, 8, 5, 5]

Crear combinaciones de elementos con múltiples iteradores:

colores = ["rojo", "verde", "azul"]

tamaños = ["pequeño", "mediano", "grande"]

combinaciones = [(color, tamaño) for color in colores for tamaño in tamaños]

print(combinaciones)

# Salida: [('rojo', 'pequeño'), ('rojo', 'mediano'), ..., ('azul', 'grande')]

Usar listas por comprensión con otras estructuras, como diccionarios por comprensión

nombres = ["Ana", "Bernardo", "Carla"]

diccionario = {nombre: len(nombre) for nombre in nombres}

print(diccionario)

# Salida: {'Ana': 3, 'Bernardo': 8, 'Carla': 5}

Conjuntos: 

numeros = [1, 2, 2, 3, 4, 4]

pares = {n for n in numeros if n % 2 == 0}

print(pares)

# Salida: {2, 4}

Para listas grandes, usa generadores para ahorrar memoria:

numeros = (n**2 for n in range(10))

print(list(numeros))

# Salida: [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]

Aunque son poderosas, a veces es mejor optar por un bucle tradicional:

- Cuando la lógica es demasiado compleja y afecta la legibilidad.

- Si necesitas manejar excepciones o realizar múltiples pasos intermedios.

Las listas por comprensión son una herramienta esencial para escribir código Python limpio y eficiente. Con práctica, dominarás su uso y aprovecharás al máximo su flexibilidad. ¿Te atreves a crear tus propias transformaciones?

Estructura Key-Value en Erlang

Para pequeñas cantidades de datos, básicamente hay dos estructuras de datos que se pueden usar. La primera se llama proplist. Una proplist es cualquier lista de tuplas de la forma [{Key,Value}]. Son un tipo de estructura extraño porque no hay otra regla que esa. De hecho, las reglas son tan relajadas que la lista también puede contener valores booleanos, números enteros y lo que quieras. Sin embargo, nos interesa más la idea de una tupla con una clave y un valor en una lista. Para trabajar con proplists, puedes usar el módulo proplists. Contiene funciones como proplists: delete/2, proplists:get_value/2, proplists:get_all_values/2, proplists:lookup/2 y proplists:lookup_all/2.

Notarás que no hay ninguna función para agregar o actualizar un elemento de la lista. Esto muestra cuán vagamente definidas están las proplists como estructura de datos. Para obtener estas funcionalidades, debes construir  tu elemento manualmente ([NewElement|OldList]) y usar funciones como lists:keyreplace/4. Usar dos módulos para una pequeña estructura de datos no es lo más claro, pero debido a que las proplists están definidas de manera tan vaga, a menudo se usan para tratar con listas de configuración y descripciones generales de un elemento determinado. Las proplists no son exactamente estructuras de datos completas. Son más bien un patrón común que aparece cuando se usan listas y tuplas para representar algún objeto o elemento; el módulo proplists es una especie de caja de herramientas para este patrón.

Si desea un almacén de clave-valor más completo para pequeñas cantidades de datos, el módulo orddict es lo que necesita. Los orddicts (diccionarios ordenados) son proplists con un gusto por la formalidad. Cada clave puede estar allí una vez, la lista completa está ordenada para una búsqueda promedio más rápida, etc. Las funciones comunes para el uso de CRUD incluyen orddict:store/3, orddict:find/2 (cuando no sabe si la clave está en los diccionarios), orddict:fetch/2 (cuando sabe que está allí o que debe estar allí) y orddict:erase/2.

Los orddicts son un compromiso generalmente bueno entre complejidad y eficiencia hasta aproximadamente 75 elementos. Después de esa cantidad, deberías cambiar a diferentes almacenes de clave-valor.

Básicamente, existen dos estructuras/módulos de clave-valor para manejar mayores cantidades de datos: dicts y gb_trees. Los diccionarios tienen la misma interfaz que los orddicts: dict:store/3, dict:find/2, dict:fetch/2, dict:erase/2 y todas las demás funciones, como dict:map/2 y dict:fold/2 (¡bastante útiles para trabajar en toda la estructura de datos!). Por lo tanto, los dicts son muy buenas opciones para escalar los orddicts cuando sea necesario.

Los árboles balanceados generales, por otro lado, tienen muchas más funciones que te dejan un control más directo sobre cómo se debe usar la estructura. Básicamente, existen dos modos para gb_trees: el modo en el que conoces tu estructura al dedillo (lo llamo el "modo inteligente") y el modo en el que no puedes asumir mucho sobre ella (lo llamo el "modo ingenuo"). En el modo ingenuo, las funciones son gb_trees:enter/3, gb_trees:lookup/2 y gb_trees:delete_any/2. Las funciones inteligentes relacionadas son gb_trees:insert/3, gb_trees:get/2, gb_trees:update/3 y gb_trees:delete/2. También existe gb_trees:map/2, que siempre es una buena opción cuando la necesitas.

La desventaja de las funciones "ingenuas" sobre las "inteligentes" es que, como los gb_trees son árboles equilibrados, siempre que insertes un nuevo elemento (o elimines un montón), es posible que el árbol deba equilibrarse a sí mismo. Esto puede llevar tiempo y memoria (incluso en comprobaciones inútiles solo para asegurarse). Todas las funciones "inteligentes" suponen que la clave está presente en el árbol: esto te permite omitir todas las comprobaciones de seguridad y da como resultado tiempos más rápidos.

¿Cuándo deberías usar gb_trees en lugar de diccionarios? Bueno, no es una decisión clara. Como lo mostrará el módulo de referencia que he escrito, gb_trees y dicts tienen rendimientos algo similares en muchos aspectos. Sin embargo, la referencia demuestra que dicts tienen las mejores velocidades de lectura mientras que gb_trees tienden a ser un poco más rápidos en otras operaciones. Puede juzgar en función de sus propias necesidades cuál sería el mejor.

Ah, y otra cosa a tener en cuenta que mientras que dicts tienen una función de plegado, gb_trees no: en su lugar, tienen una función de iteración, que devuelve un fragmento del árbol en el que puede llamar a gb_trees:next(Iterator) para obtener los siguientes valores en orden. Lo que esto significa es que necesita escribir sus propias funciones recursivas sobre gb_trees en lugar de usar un genric fold. Por otro lado, gb_trees te permite tener un acceso rápido a los elementos más pequeños y más grandes de la estructura con gb_trees:smallest/1 y gb_trees:largest/1.

Por lo tanto, diría que las necesidades de tu aplicación son las que deberían determinar qué almacén de clave-valor elegir. Diferentes factores, como la cantidad de datos que tienes que almacenar, lo que necesitas hacer con ellos y demás, tienen su importancia. Mide, perfila y compara para asegurarte.

Existen algunos almacenes de clave-valor especiales para manejar recursos de diferentes tamaños. Estos almacenes son las tablas ETS, las tablas DETS y la base de datos mnesia. Sin embargo, su uso está fuertemente relacionado con los conceptos de múltiples procesos y distribución. 

A partir de la versión 17.0, el lenguaje admite un nuevo tipo de datos de clave-valor nativo, descrito en Postscript: Maps. 

Registros en Erlang

Los record de Erlang son muy parecidos a las struct en C.

Se declaran como atributos de módulo de la siguiente manera:

-module(records).

-compile(export_all).

-record(robot, {name,

                type=industrial,

                hobbies,

                details=[]}).

Aquí tenemos un registro que representa robots con 4 campos: nombre, tipo, pasatiempos y detalles. También hay un valor predeterminado para el tipo y los detalles, industrial y [], respectivamente. A continuación, se muestra cómo declarar un registro en el módulo records:

first_robot() ->

    #robot{name="Mechatron",

           type=handmade, 

           details=["Moved by a small man inside"]}.

Y ejecutando el código:

1> c(records).

{ok,records}

2> records:first_robot().

{robot,"Mechatron",handmade,undefined,

       ["Moved by a small man inside"]}

Los registros de Erlang son simplemente azúcar sintáctico sobre tuplas. Afortunadamente, hay una forma de mejorarlo. El shell de Erlang tiene un comando rr(Module) que le permite cargar definiciones de registros desde Module:

3> rr(records).

[robot]

4> records:first_robot().         

#robot{name = "Mechatron",type = handmade,

       hobbies = undefined,

       details = ["Moved by a small man inside"]}

Esto hace que sea mucho más fácil trabajar con registros de esa manera. Notarás que en first_robot/0, no habíamos definido el campo de pasatiempos y no tenía un valor predeterminado en su declaración. Erlang, por defecto, establece el valor como indefinido.

Para ver el comportamiento de los valores predeterminados que establecimos en la definición del robot, compilemos la siguiente función:

car_factory(CorpName) ->

    #robot{name=CorpName, hobbies="building cars"}.

Y ejecutalo:

5> c(records).

{ok,records}

6> records:car_factory("Jokeswagen").

#robot{name = "Jokeswagen",type = industrial,

       hobbies = "building cars",details = []}

Y tenemos un robot industrial al que le gusta pasar el tiempo construyendo coches.

La función rr() puede tomar más que un nombre de módulo: puede tomar un comodín (como rr("*")) y también una lista como segundo argumento para especificar qué registros cargar.

Hay algunas otras funciones para manejar registros en el shell: rd(Name, Definition) le permite definir un registro de una manera similar a la función -record(Name, Definition) utilizada en nuestro módulo. Puede usar rf() para "descargar" todos los registros, o rf(Name) o rf([Names]) para deshacerse de definiciones específicas.

Puede usar rl() para imprimir todas las definiciones de registros de una manera que pueda copiar y pegar en el módulo o usar rl(Name) o rl([Names]) para restringirlo a registros específicos.

Por último, rp(Term) le permite convertir una tupla en un registro (siempre que exista la definición).

Escribir registros por sí solo no hará mucho. Necesitamos una manera de extraer valores de ellos. Básicamente, hay dos maneras de hacer esto. El primero tiene una "sintaxis de punto" especial. Suponiendo que tiene cargada la definición de registro para robots:

5> Crusher = #robot{name="Crusher", hobbies=["Crushing people","petting cats"]}. 

#robot{name = "Crusher",type = industrial,

       hobbies = ["Crushing people","petting cats"],

       details = []}

6> Crusher#robot.hobbies.

["Crushing people","petting cats"]

No es una sintaxis muy bonita. Esto se debe a la naturaleza de los registros como tuplas. Como son solo una especie de truco del compilador, tienes que mantener las palabras claves para definir qué registro va con qué variable, de ahí la parte #robot de Crusher#robot.hobbies. Es triste, pero no hay forma de evitarlo. Peor aún, los registros anidados se vuelven bastante feos:

7> NestedBot = #robot{details=#robot{name="erNest"}}.

#robot{name = undefined, type = industrial,

       hobbies = undefined,

       details = #robot{name = "erNest",type = industrial,

                        hobbies = undefined,details = []}}

8> (NestedBot#robot.details)#robot.name. 

"erNest"

Para mostrar aún más la dependencia de los registros en las tuplas, veamos :

9> #robot.type.

3

Lo que esto genera es qué elemento de la tupla subyacente es.

Una característica de ahorro de los registros es la posibilidad de usarlos en los encabezados de funciones para hacer coincidir patrones y también en los guards. Declare un nuevo registro de la siguiente manera en la parte superior del archivo y luego agregue las funciones debajo:

-record(user, {id, name, group, age}).

%% use pattern matching to filter

admin_panel(#user{name=Name, group=admin}) ->

    Name ++ " is allowed!";

admin_panel(#user{name=Name}) ->

    Name ++ " is not allowed".

%% can extend user without problem

adult_section(U = #user{}) when U#user.age >= 18 ->

    %% Show stuff that can't be written in such a text

    allowed;

adult_section(_) ->

    %% redirect to sesame street site

    forbidden.

Esto nos permite ver que no es necesario hacer coincidir todas las partes de la tupla o incluso saber cuántas hay al escribir la función: solo podemos hacer coincidir la edad o el grupo si es lo que se necesita y olvidarnos del resto de la estructura. Si utilizáramos una tupla normal, la definición de la función podría tener que parecerse un poco a function({record, _, _, ICareAboutThis, _, _}) -> .... Entonces, cada vez que alguien decida agregar un elemento a la tupla, alguien más (probablemente enojado por todo esto) tendría que ir y actualizar todas las funciones donde se usa esa tupla.

La siguiente función ilustra cómo actualizar un registro (de lo contrario, no serían muy útiles):

repairman(Rob) ->

    Details = Rob#robot.details,

    NewRob = Rob#robot{details=["Repaired by repairman"|Details]},

    {repaired, NewRob}.

Y luego:

16> c(records).

{ok,records}

17> records:repairman(#robot{name="Ulbert", hobbies=["trying to have feelings"]}).

{repaired,#robot{name = "Ulbert",type = industrial,

                 hobbies = ["trying to have feelings"],

                 details = ["Repaired by repairman"]}}

Y puedes ver que mi robot ha sido reparado. La sintaxis para actualizar registros es un poco especial aquí. Parece que estamos actualizando el registro en su lugar (Rob#robot{Field=NewValue}) pero todo es un truco del compilador para llamar a la función subyacente erlang:setelement/3.

Una última cosa sobre los registros. Debido a que son bastante útiles y la duplicación de código es molesta, los programadores de Erlang comparten registros con frecuencia entre módulos con la ayuda de archivos de encabezado. Los archivos de encabezado de Erlang son bastante similares a su contraparte de C: no son más que un fragmento de código que se agrega al módulo como si estuviera escrito allí en primer lugar. Crea un archivo llamado records.hrl con el siguiente contenido:

%% this is a .hrl (header) file.

-record(included, {some_field,

                   some_default = "yeah!",

                   unimaginative_name}).

Para incluirlo en records.erl, simplemente agregue la siguiente línea al módulo:

-include("records.hrl").

Y luego la siguiente función para probarlo:

included() -> #included{some_field="Some value"}.

Ahora, pruébalo como siempre:

18> c(records).

{ok,records}

19> rr(records).

[included,robot,user]

20> records:included().

#included{some_field = "Some value",some_default = "yeah!",

          unimaginative_name = undefined}

Eso es todo sobre los registros; son feos pero útiles. Su sintaxis no es bonita, no son gran cosa, pero son relativamente importantes para la capacidad de mantenimiento de su código.

A menudo verá software de código abierto que utiliza el método que se muestra aquí de tener un archivo .hrl para todo el proyecto para los registros que se comparten entre todos los módulos. Si bien me sentí obligado a documentar este uso, recomiendo enfáticamente que mantenga todas las definiciones de registros locales, dentro de un módulo. Si desea que algún otro módulo observe las entrañas de un registro, escriba funciones para acceder a sus campos y mantenga sus detalles lo más privados posible. Esto ayuda a prevenir conflictos de nombres, evita problemas al actualizar el código y, en general, mejora la legibilidad y la capacidad de mantenimiento de su código.

Macros en Elixir

Elixir no solo es conocido por su modelo de concurrencia y eficiencia, sino también por su poderosa capacidad de metaprogramación, gracias a sus macros. Con ellas, puedes escribir código que genera más código, permitiendo crear herramientas, DSLs (lenguajes específicos de dominio) y extender el lenguaje.

En Elixir, las macros son funciones especiales que reciben expresiones y devuelven otras expresiones transformadas. Estas transformaciones ocurren en tiempo de compilación, lo que las diferencia de las funciones normales.

defmodule EjemploMacro do

  defmacro saludo do

    quote do

      IO.puts("¡Hola, mundo!")

    end

  end

end

require EjemploMacro

EjemploMacro.saludo()

# Salida: ¡Hola, mundo!

¿Cómo funciona esto?

• quote/2: Captura código como datos. Convierte un bloque en su representación AST (Abstract Syntax Tree).
• unquote/1: Inserta valores dinámicos en el código generado.
• defmacro: Declara macros.

Imagina que necesitas loguear todas las llamadas a funciones en un módulo. Con macros, puedes automatizar este proceso:

defmodule LoggerMacro do

  defmacro log_call(fun_name, do: block) do

    quote do

      IO.puts("Llamando a #{unquote(fun_name)}")

      result = unquote(block)

      IO.puts("Resultado: #{result}")

      result

    end

  end

end

defmodule Ejemplo do

  require LoggerMacro

  def calcular do

    LoggerMacro.log_call(:calcular) do

      1 + 2

    end

  end

end

Ejemplo.calcular()

# Salida:

# Llamando a calcular

# Resultado: 3

Los macros son herramientas poderosas para crear DSLs. Por ejemplo, un DSL para rutas web (similar a Plug.Router):

defmodule MiniRouter do

  defmacro route(method, path, do: block) do

    quote do

      def handle_request(unquote(method), unquote(path)) do

        unquote(block)

      end

    end

  end

end

defmodule MyRouter do

  require MiniRouter

  MiniRouter.route(:get, "/") do

    IO.puts("¡Bienvenido!")

  end

  MiniRouter.route(:post, "/create") do

    IO.puts("¡Creando recurso!")

  end

end

MyRouter.handle_request(:get, "/")

# Salida: ¡Bienvenido!

Aunque las macros son útiles, pueden complicar el código:

• Usa macros solo si la lógica no puede resolverse con funciones.
• Opta por composición funcional siempre que sea posible.

Las macros en Elixir son una herramienta increíblemente poderosa para extender el lenguaje y crear soluciones elegantes. Sin embargo, requieren un buen entendimiento del AST y un uso responsable. 

¿Por qué C++ utiliza punteros para implementar el polimorfismo?

En C++, los punteros son fundamentales para implementar el polimorfismo debido a cómo se gestionan los objetos y sus referencias en tiempo de ejecución. 

En C++, el polimorfismo en tiempo de ejecución se logra mediante el uso de funciones virtuales y tablas de métodos virtuales (vtable). Para que el compilador pueda llamar al método adecuado de una clase derivada, necesita acceso indirecto al objeto en memoria.

• Cuando usamos punteros o referencias, el compilador puede determinar el tipo del objeto en tiempo de ejecución y acceder a la vtable correcta.
• Si usáramos valores en lugar de punteros, el objeto sería copiado, y la información dinámica sobre su tipo (necesaria para el polimorfismo) se perdería.

#include <iostream>

using namespace std;

class Base {

public:

    virtual void speak() const {

        cout << "Soy Base\n";

    }

};

class Derived : public Base {

public:

    void speak() const override {

        cout << "Soy Derived\n";

    }

};

int main() {

    Base* obj = new Derived(); // Usamos puntero para polimorfismo

    obj->speak();             // Llama al método de Derived en tiempo de ejecución

    delete obj;

}

Aquí, el puntero obj permite que la llamada a speak() sea resuelta dinámicamente en tiempo de ejecución.

Otro problema es el slicing, que ocurre cuando un objeto derivado se asigna a un objeto base por valor. Esto copia solo la parte de la clase base, perdiendo los datos específicos de la clase derivada.

Por ejemplo: 

Derived d;

Base b = d; // Copia solo la parte "Base" del objeto

b.speak();  // Siempre llamará a Base::speak(), incluso si es virtual

El uso de punteros evita este problema, ya que siempre apuntan al objeto completo en memoria.

En C++, el polimorfismo suele estar vinculado a la asignación dinámica. Los punteros son necesarios para gestionar la memoria del heap y permiten que un programa decida en tiempo de ejecución qué tipo de objeto crear y manipular.

Base* createObject(bool flag) {

    if (flag)

        return new Derived();

    else

        return new Base();

}

Sin punteros, esta flexibilidad sería difícil de implementar.

Por ultimo, los punteros permiten acceder a objetos grandes en el heap sin necesidad de copiar toda su estructura. Esto es especialmente útil para jerarquías complejas de clases.

En vez de manejar múltiples copias de objetos derivados, los punteros permiten trabajar con una referencia común al objeto base, pero respetando el comportamiento dinámico. Si bien esto no tiene que ver directamente con el polimorfismo lo agregamos para ser más completos :D

C++ utiliza punteros para implementar el polimorfismo porque permiten:

• Resolución dinámica de métodos a través de las vtables.
• Evitar el problema de slicing.
• Compatibilidad con asignación dinámica.
• Referencias eficientes a objetos complejos.

La filosofía Ponylang: "hacer las cosas bien"

En el espíritu de Richard Gabriel, la filosofía Pony no es ni “lo correcto” ni “lo peor es mejor”. Es “hacer las cosas bien”.

• Corrección. La incorrección simplemente no está permitida. No tiene sentido intentar hacer las cosas si no puedes garantizar que el resultado sea correcto.
• Rendimiento. La velocidad en tiempo de ejecución es más importante que todo excepto la corrección. Si se debe sacrificar el rendimiento por la corrección, intenta encontrar una nueva forma de hacer las cosas. Cuanto más rápido pueda el programa hacer las cosas, mejor. Esto es más importante que cualquier cosa excepto un resultado correcto.
• Simplicidad. La simplicidad se puede sacrificar por el rendimiento. Es más importante que la interfaz sea simple que la implementación. Cuanto más rápido pueda el programador hacer las cosas, mejor. Está bien hacer las cosas un poco más difíciles para el programador para mejorar el rendimiento, pero es más importante hacer las cosas más fáciles para el programador que para el lenguaje/tiempo de ejecución.
• Coherencia. La consistencia puede sacrificarse por la simplicidad o el rendimiento. No permita que una consistencia excesiva se interponga en el camino de hacer las cosas.
• Completitud. Es bueno cubrir tantas cosas como sea posible, pero la completitud puede sacrificarse por cualquier otra cosa. Es mejor hacer algunas cosas ahora que esperar hasta que todo pueda hacerse más tarde.

El enfoque de "hacer las cosas" tiene la misma actitud hacia la corrección y la simplicidad que "lo correcto", pero la misma actitud hacia la consistencia y la completitud que "lo peor es mejor". También agrega el rendimiento como un nuevo principio, tratándolo como la segunda cosa más importante (después de la corrección).

A lo largo del diseño y desarrollo del lenguaje se deben respetar los siguientes principios.

• Utilice el enfoque de hacer las cosas.
• Gramática simple. El lenguaje debe ser trivial de analizar tanto para humanos como para computadoras.
• Sin código cargable. Todo es conocido por el compilador.
• Totalmente seguro para los tipos. No existe la coerción del tipo “confía en mí, sé lo que estoy haciendo”.
• Totalmente seguro para la memoria. No existe la coerción del tipo “este número aleatorio es en realidad un puntero, de verdad”.
• No hay fallos. Un programa que compila nunca debería fallar (aunque puede quedarse colgado o hacer algo no deseado).
• Mensajes de error sensatos. Siempre que sea posible, utilice mensajes de error simples para casos de error específicos. Está bien asumir que el programador conoce las definiciones de las palabras en nuestro léxico, pero evite la jerga de compiladores u otra jerga informática.
• Sistema de compilación inherente. No se requieren aplicaciones separadas para configurar o compilar.
• Trate de reducir los errores de programación comunes mediante el uso de una sintaxis restrictiva.
• Proporcione una forma única, limpia y clara de hacer las cosas en lugar de atender los prejuicios preferidos de cada programador.
• Realice actualizaciones limpias. No intente fusionar las nuevas características con las que están reemplazando, si algo está roto, elimínelo y reemplácelo de una sola vez. Siempre que sea posible, proporcione utilidades de reescritura para actualizar el código fuente entre versiones de lenguaje.
• Tiempo de compilación razonable. Reducir el tiempo de compilación es importante, pero menos importante que el rendimiento y la corrección en tiempo de ejecución.
• Está bien permitir que el programador omita algunas cosas del código (argumentos predeterminados, inferencia de tipos, etc.), pero siempre se debe permitir la especificación completa.
• Sin ambigüedad. El programador nunca debería tener que adivinar lo que hará el compilador, o viceversa.
• Documentar la complejidad requerida. No todas las características del lenguaje tienen que ser triviales de entender, pero las características complejas deben tener explicaciones completas en la documentación para que se permitan en el lenguaje.
• Las características del lenguaje deben ser mínimamente intrusivas cuando no se usan.
• Semántica completamente definida. La semántica de todas las características del lenguaje debe estar disponible en la documentación estándar del lenguaje. No es aceptable dejar el comportamiento sin definir o "dependiente de la implementación".
• Debe estar disponible un acceso eficiente al hardware, pero esto no tiene que impregnar todo el lenguaje.
• La biblioteca estándar debe implementarse en Pony.
• Interoperabilidad. Debe ser interoperable con otros lenguajes, pero esto puede requerir una capa de corrección si se utilizan tipos no primitivos.
• Evite problemas con la biblioteca. El uso de bibliotecas Pony de terceros debe ser lo más sencillo posible, sin sorpresas. Esto incluye escribir y distribuir bibliotecas y usar múltiples versiones de una biblioteca en un solo programa.

Introducción a Plug de Elixir

Elixir, con su enfoque funcional y capacidad para manejar concurrencia de manera eficiente, es un lenguaje ideal para aplicaciones web. Si bien Phoenix es el framework más conocido, Plug es una alternativa minimalista perfecta para quienes buscan simplicidad y flexibilidad, similar a lo que Sinatra ofrece en Ruby.

Plug es un conjunto de especificaciones y módulos para construir aplicaciones web en Elixir. Se centra en el manejo de conexiones HTTP y proporciona herramientas básicas para construir rutas y middlewares.

• Minimalista: Perfecto para aplicaciones simples o como base para proyectos más grandes.
• Rápido: Aprovecha Cowboy, un servidor HTTP eficiente.
• Flexible: Puedes usarlo directamente o integrarlo en frameworks más grandes como Phoenix.

Para comenzar, necesitas agregar Plug y Cowboy a tu proyecto. En el archivo `mix.exs`:

Antes creas el proyecto : 

mix new hello_world

Y Luego editamos mix.exs

defp deps do

  [

    {:plug, "~> 1.13"},

    {:plug_cowboy, "~> 2.6"}

  ]

end

Ejecuta mix deps.get para instalar las dependencias.

Para comenzar a crear Plugs, necesitamos conocer, y adherirse a la especificación Plug. Afortunadamente para nosotros, sólo hay dos funciones necesarias: init/1 y call/2.

Aquí hay un Plug simple que devuelve “Hello World!”:

defmodule Example.HelloWorldPlug do

  import Plug.Conn

  def init(options), do: options

  def call(conn, _opts) do

    conn

    |> put_resp_content_type("text/plain")

    |> send_resp(200, "Hello World!")

  end

end

Guarda el archivo en lib/example/hello_world_plug.ex.

La función init/1 se utiliza para inicializar las opciones de nuestros Plugs. Esta es llamada por el árbol de supervisión. De momento, está será una lista vacía que es ignorada.

El valor retornado por la función init/1 eventualmente será pasado a call/2 como su segundo argumento.

La función call/2 es ejecutada por cada petición que viene desde el servidor web, Cowboy. Esta recibe una estructura de conexión %Plug.Conn{} como su primer argumento y se espera que retorne una estructura de conexión %Plug.Conn{}.

Debido a que estamos iniciando nuestra aplicación plug desde cero, necesitamos definir el módulo de la aplicación. Actualiza lib/example.ex para iniciar y supervisar Cowboy:

defmodule Example do

  use Application

  require Logger

  def start(_type, _args) do

    children = [

      Plug.Adapters.Cowboy.child_spec(:http, Example.HelloWorldPlug, [], port: 8080)

    ]

    Logger.info("Started application")

    Supervisor.start_link(children, strategy: :one_for_one)

  end

end

Esto supervisa Cowboy, y a su vez, supervisa nuestro HelloWorldPlug.

En la petición a Plug.Adapters.Cowboy.child_spec/4, el tercer argumento será pasado a Example.HelloWorldPlug.init/1.

Aún no hemos terminado. Abre mix.exs de nuevo, y busca la función applications. De momento la parte de aplication en mix.exs necesita dos cosas:

• Una lista de aplicaciones de dependencia (cowboy, logger, and plug) que necesintan iniciar, y
• Configuración para nuestra aplicación, la cual también deberá iniciar automáticamente. Vamos a actualizarla para hacerlo:

def application do

  [

    extra_applications: [:cowboy, :logger, :plug],

    mod: {Example, []}

  ]

end

Estamos listos para probar este servidor web, minimalístico basado en Plug. En la línea de comando ejecuta:

mix run --no-halt

Cuando todo termine de compilar, y el mensaje [info] Started app aparece, abre el explorador web en 127.0.0.1:8080. Este debera de desplegar:

Hello World!

Plug es ideal para quienes buscan simplicidad y control en sus aplicaciones web. Su integración con Cowboy y su flexibilidad lo hacen una excelente opción para proyectos ligeros, APIs o como base para aprender Elixir.

Dejo link: https://elixirschool.com/es/lessons/misc/plug

QuickSort en Pony

Un Algoritmo que me gusta mucho es el quicksort, porque es un algoritmo por demás claro. Ya he escrito lo fácil que es implementarlo en scala, erlang, rust, haskell , F# y lisp.

Ahora le toca a Pony. Básicamente el algoritmo toma un pivot y agrupa los menores del pivot al principio y los mayores al final y aplica quicksort a estos 2 grupos. Y si la lista es vacía o tiene un elemento, ya esta ordenada. 

Vamos al código:  

 actor Main

  new create(env: Env) =>

    let data = [4; 2; 7; 1; 3; 6; 5]

    env.out.print("Original: " + data.string())

    let sorted = quicksort(data)

    env.out.print("Sorted: " + sorted.string())

  fun quicksort(data: Array[U64]): Array[U64] =>

    if data.size() <= 1 then

      data

    else

      let pivot = data(0)?

      let less = data.values().filter(lambda(x: U64): Bool => x < pivot end)

      let greater = data.values().filter(lambda(x: U64): Bool => x > pivot end)

      let less_sorted = quicksort(less)

      let greater_sorted = quicksort(greater)

      let result = less_sorted.append(pivot)

      result.append(greater_sorted)

    end

Elixir: Concurrencia Hecha Sencilla

Elixir, basado en la máquina virtual de Erlang (BEAM), utiliza el modelo de actores como su paradigma de concurrencia. Este modelo permite manejar múltiples procesos de manera eficiente y segura, lo que lo hace ideal para sistemas distribuidos y concurrentes.

El modelo de actores es un paradigma de concurrencia en el que las entidades llamadas actores:

• Son unidades independientes de ejecución.
• Tienen su propio estado y no comparten memoria con otros actores.
• Se comunican mediante el envío de mensajes.

En Elixir, los procesos son implementaciones del modelo de actores y son extremadamente ligeros gracias a la eficiencia de la VM de Erlang.

En Elixir, los actores se implementan utilizando módulos como GenServer. Vamos a crear un ejemplo básico de un contador que incrementa su valor en respuesta a mensajes.

   defmodule Counter do

     use GenServer

     # Inicio del actor con un estado inicial

     def start_link(initial_value) do

       GenServer.start_link(__MODULE__, initial_value, name: __MODULE__)

     end

     # Callbacks

     def init(initial_value) do

       {:ok, initial_value}

     end

     # Manejar el mensaje para incrementar el contador

     def handle_call(:increment, _from, state) do

       {:reply, state + 1, state + 1}

     end

     def handle_call(:get, _from, state) do

       {:reply, state, state}

     end

   end

   # Iniciar el actor con un valor inicial de 0

   {:ok, _pid} = Counter.start_link(0)

   # Incrementar el contador

   Counter.call(:increment) # Devuelve 1

   Counter.call(:increment) # Devuelve 2

   # Obtener el valor actual

   Counter.call(:get) # Devuelve 2

Ahora crearemos múltiples actores que se comuniquen entre sí. Supongamos que tenemos un sistema donde un actor recopila datos y otro los procesa.

   defmodule DataCollector do

     use GenServer

     def start_link(processor_pid) do

       GenServer.start_link(__MODULE__, processor_pid, name: __MODULE__)

     end

     def init(processor_pid) do

       {:ok, processor_pid}

     end

     def handle_cast({:collect, data}, processor_pid) do

       send(processor_pid, {:process, data})

       {:noreply, processor_pid}

     end

   end

 

   defmodule DataProcessor do

     use GenServer

     def start_link(_) do

       GenServer.start_link(__MODULE__, [], name: __MODULE__)

     end

     def init(_) do

       {:ok, []}

     end

     def handle_info({:process, data}, state) do

       IO.puts("Procesando: #{data}")

       {:noreply, [data | state]}

     end

   end

   {:ok, processor_pid} = DataProcessor.start_link([])

   {:ok, collector_pid} = DataCollector.start_link(processor_pid)

   GenServer.cast(collector_pid, {:collect, "dato1"})

   GenServer.cast(collector_pid, {:collect, "dato2"})

DataCollector recopila datos y los envía a DataProcessor. DataProcessor procesa los datos recibidos y los guarda en su estado.

Como ventaja del modelo de actores tenemos:

Aislamiento Total: Los actores no comparten memoria, eliminando condiciones de carrera.

Escalabilidad: Los procesos son livianos y se ejecutan de manera concurrente.

Resiliencia: Si un actor falla, el sistema no se detiene; los supervisores pueden reiniciarlo.

El modelo de actores de Elixir proporciona una forma poderosa, segura y eficiente de manejar concurrencia. Al entender cómo implementar actores y supervisarlos, puedes construir sistemas robustos que escalen sin problemas.

Primeros pasos en Pony

Pony es un lenguaje de programación orientado a objetos, actor-modelo, capacidades seguras. Es orientado a objetos porque tiene clases y objetos, como Python, Java, C++ y muchos otros lenguajes. Es actor-modelo porque tiene actores (similares a Erlang, Elixir o Akka). Estos se comportan como objetos, pero también pueden ejecutar código de forma asincrónica. Los actores hacen que Pony sea increíble.

Cuando decimos que Pony es seguro en cuanto a capacidades, nos referimos a algunas cosas:

• Es seguro en cuanto a tipos. Realmente seguro en cuanto a tipos. 
• Es seguro en cuanto a memoria. Esto viene con seguridad en cuanto a tipos, pero sigue siendo interesante. No hay punteros, ni desbordamientos de búfer, ni siquiera tiene el concepto de nulo.
• Es seguro en cuanto a excepciones. No hay excepciones en tiempo de ejecución. Todas las “situaciones excepcionales” tienen una semántica definida y siempre se manejan.
• No tiene carreras de datos. Pony no tiene bloqueos ni operaciones atómicas ni nada parecido. En cambio, el sistema de tipos garantiza en tiempo de compilación que su programa concurrente nunca pueda tener carreras de datos. Así que puede escribir código altamente concurrente y nunca equivocarse.
• No tiene interbloqueos. Esto es fácil, Pony no tiene bloqueos en absoluto. Así que definitivamente no se bloquean, porque no existen.

Pony no puede impedir que se escriba errores lógicos, pero puede evitar que clases enteras de errores sean posibles. El compilador Pony evita que accedas a la memoria de forma insegura de forma concurrente. Si alguna vez has hecho programación concurrente, sabes lo difícil que puede ser rastrear este tipo de cosas.