Funciones en Elm

Una función transforma valores. Toma un valor y genera otro.

Por ejemplo, aquí hay una función de saludo que toma un nombre y dice hola:

> greet name =

|   "Hello " ++ name ++ "!"

| 

<function>

> greet "Alice"

"Hello Alice!"

> greet "Bob"

"Hello Bob!"

Los valores pasados ​​a la función se llaman comúnmente argumentos, así que podrías decir "saludar es una función que toma un argumento".

Bien, ahora que ya hablamos de saludos, ¿qué tal una función de madlib que toma dos argumentos?

> madlib animal adjective =

|   "The ostentatious " ++ animal ++ " wears " ++ adjective ++ " shorts."

| 

<function>

> madlib "cat" "ergonomic"

"The ostentatious cat wears ergonomic shorts."

> madlib ("butter" ++ "fly") "metallic"

"The ostentatious butterfly wears metallic shorts."

Se debe usar paréntesis para agrupar "butter" ++ "fly". Cada argumento debe ser un valor primitivo como "cat" o debe estar entre paréntesis.

Quienes usan lenguajes como JavaScript podrían sorprenderse de que las funciones se vean diferentes aquí:

madlib "cat" "ergonomic"                  -- Elm

madlib("cat", "ergonomic")                // JavaScript

madlib ("butter" ++ "fly") "metallic"      -- Elm

madlib("butter" + "fly", "metallic")       // JavaScript

Esto puede resultar sorprendente al principio, pero este estilo termina usando menos paréntesis y comas. ¡Hace que el lenguaje se sienta realmente limpio y minimalista una vez que te acostumbras!

¡Comencemos por familiarizarnos con el código Elm!

El componente más pequeño de Elm se llama valor. Esto incluye valores como 42, Verdadero y "¡Hola!".

Comencemos analizando los números:

> 1 + 1

2

Hacer cálculos matemáticos está bien, pero es sorprendentemente poco común en la mayoría de los programas. Es mucho más común trabajar con cadenas como esta:

> "hola"

"hola"

> "butter" ++ "fly"

"butterfly"

>

¡Estos valores primitivos se vuelven más interesantes cuando empezamos a escribir funciones para transformarlos! Por lo tanto en proximos post veremos funciones. 

Cómo instalar Elm en Ubuntu

Si te interesa la programación funcional y te atrae la idea de crear interfaces web robustas y sin errores, Elm puede ser una excelente elección. 

Elm es un lenguaje de programación funcional y fuertemente tipado que compila a JavaScript. Se usa principalmente para construir interfaces web confiables, sin errores en tiempo de ejecución.

Vamos a instalarlo!! 

Antes de instalar Elm, asegurate de tener instalado:

Node.js y npm (el gestor de paquetes de Node)

Podés instalarlos con:

sudo apt update

sudo apt install nodejs npm

Verificá la instalación:

node -v

npm -v

Podés instalar Elm de varias formas, pero la más sencilla y recomendada para Ubuntu es a través de npm:

sudo npm install -g elm

Esto instalará los siguientes comandos:

• elm (CLI principal)
• elm-repl (intérprete interactivo)
• elm-reactor (servidor de desarrollo)
• elm-make (compilador, alias de elm desde Elm 0.19)

Verificá que esté instalado correctamente:

elm --version

Deberías ver algo como: 0.19.1

Podés crear un proyecto de prueba:

mkdir hola-elm

cd hola-elm

elm init

Esto generará un archivo elm.json. Luego, podés crear un archivo src/Main.elm y escribir tu primer módulo Elm. Por ejemplo : 

module Main exposing (main)

import Browser

import Html exposing (text)

main =

    Browser.sandbox

        { init = ()

        , update = \_ model -> model

        , view = \_ -> text "¡Hola Mundo desde Elm!"

        }

Para ver tus archivos Elm directamente en el navegador, ejecutá:

elm reactor

Y abrí http://localhost:8000 para explorar tu proyecto visualmente.

Elm es un lenguaje potente con un ecosistema pequeño pero muy enfocado. Si venís de JavaScript o TypeScript, o simplemente te interesa la programación funcional, Elm te va a sorprender.

1 Billon de iteraciones de bucles anidados

Me encanto esta comparativa por lo que quería compartirla, básicamente es un benchmark en diferentes lenguajes :

Dejo link

https://benjdd.com/languages/

Conversiones implicit y explicit en C#

En C#, los operadores implicit y explicit nos permiten definir conversiones personalizadas entre tipos. Esto es útil cuando trabajamos con estructuras o clases que representan conceptos que pueden transformarse naturalmente en otros valores, como metros a kilómetros, grados a radianes, o monedas.

Cuando diseñamos tipos personalizados, muchas veces necesitamos que se comporten como si fueran valores comunes. Por ejemplo, si tenemos un struct Metros, queremos poder escribir:

Metros distancia = 100.0;

En lugar de tener que usar un constructor o un método auxiliar. O, si ya tenemos un objeto de tipo Metros, queremos poder convertirlo a double sin esfuerzo.

Sin conversiones definidas, tendríamos que hacer algo como:

var distancia = new Metros(100.0);

double d = distancia.Valor;

Definiendo operadores de conversión, podemos hacer que esta interacción sea más fluida.

El modificador implicit permite definir una conversión automática cuando no hay pérdida de información. El compilador permitirá esta conversión sin necesidad de cast.

Por ejemplo:

public struct Metros

{

    public double Valor { get; }

    public Metros(double valor) => Valor = valor;

    public static implicit operator Metros(double valor) => new Metros(valor);

}

Uso:

Metros distancia = 100.0; // conversión implícita desde double

Cuando una conversión puede perder información, o puede fallar, se recomienda marcarla como explicit. Esto obliga al programador a escribir el cast, dejando claro que está realizando una operación que podría tener consecuencias.

Por ejemplo:

public static explicit operator double(Metros metros) => metros.Valor;

Uso:

double d = (double)distancia; // cast explícito requerido

Las conversiones implicit y explicit en C# permiten diseñar APIs más amigables, legibles y seguras. Usá implicit cuando estés seguro de que la conversión no va a fallar ni perder datos, y explicit cuando quieras que el programador sea consciente del riesgo de la conversión.

Tipos Abstractos y Polimorfismo en Programación Funcional

Cuando pensamos en abstracción y polimorfismo, solemos imaginar clases, interfaces y herencia. Pero ¿sabías que la programación funcional también tiene sus propios superpoderes para modelar el comportamiento genérico y abstraer detalles? 

En POO, usamos clases abstractas o interfaces para definir estructuras que deben ser implementadas. En programación funcional, el enfoque es distinto, pero el objetivo es similar: ocultar detalles de implementación y exponer un comportamiento general.

Un ADT define un tipo por sus operaciones, no por cómo están implementadas. Por ejemplo:

data Pila a = Vacía | Empujar a (Pila a)

Este tipo Pila podría representar una pila genérica, y podríamos tener funciones que operen sobre ella sin importar cómo esté construida internamente.

En la programación funcional se identifican varios tipos de polimorfismo:

Polimorfismo Paramétrico: Permite escribir funciones genéricas sobre cualquier tipo. Es como los genéricos de Java, pero más poderoso:

identidad :: a -> a

identidad x = x

La función identidad funciona para cualquier tipo a.

Polimorfismo ad-hoc (Typeclasses / Traits / Protocolos) : En Haskell, Rust, Scala o Elixir podemos definir interfaces de comportamiento según el tipo. Esto recuerda al "método virtual" de POO.

class Metrico a where

    distancia :: a -> a -> Double

instance Metrico (Double, Double) where

    distancia (x1, y1) (x2, y2) =

        sqrt ((x2 - x1)^2 + (y2 - y1)^2)

Veamos un ejemplo en Scala:

trait Metrico[T] {

  def distancia(a: T, b: T): Double

}

implicit object Punto2D extends Metrico[(Double, Double)] {

  def distancia(a: (Double, Double), b: (Double, Double)) =

    math.sqrt(math.pow(a._1 - b._1, 2) + math.pow(a._2 - b._2, 2))

}

def calcularDistancia[T](a: T, b: T)(implicit m: Metrico[T]) =

  m.distancia(a, b)

Pattern Matching como Polimorfismo Estructural: Otro recurso poderoso es el pattern matching, que permite seleccionar comportamiento según la "forma" del dato.

sealed trait Forma

case class Circulo(r: Double) extends Forma

case class Rectangulo(ancho: Double, alto: Double) extends Forma

def area(f: Forma): Double = f match {

  case Circulo(r)       => math.Pi * r * r

  case Rectangulo(a, h) => a * h

}

¿Y qué ganamos con esto?

• Abstracción sin herencia: no hay jerarquías rígidas.
• Mayor seguridad de tipos: muchos errores se detectan en tiempo de compilación.
• Separación de datos y comportamiento: las funciones no "viven" dentro de las estructuras de datos, lo cual facilita la composición y el testing.

La programación funcional ofrece mecanismos muy sólidos y expresivos para manejar abstracción y polimorfismo. Aunque no se usa herencia, se logra el mismo efecto (o incluso uno más flexible) usando funciones genéricas, pattern matching y typeclasses.

¿Por qué un lenguaje funcional como Elm?

Puedes obtener algunas ventajas de programar con un estilo funcional, pero hay cosas que solo se pueden conseguir con un lenguaje funcional como Elm:

• Sin errores de ejecución en la práctica.
• Mensajes de error intuitivos.
• Refactorización fiable.
• Control de versiones semántico automático para todos los paquetes de Elm.

Ninguna combinación de bibliotecas JS puede ofrecerte todas estas garantías. ¡Provienen del diseño del propio lenguaje! Y gracias a estas garantías, es bastante común que los programadores de Elm digan que nunca se sintieron tan seguros programando. Seguros para añadir funciones rápidamente. Seguros para refactorizar miles de líneas. ¡Pero sin la ansiedad de pensar que se te ha pasado algo importante!

El Archivo de Anna

Les quiero recomendar el sitio el Archivo de Anna (del inglés Anna's Archive) que es un metabuscador en línea gratuito y sin ánimo de lucro de bibliotecas fantasma que proporciona acceso a una colección de libros, creado por un equipo de archivistas anónimos (conocidos como Anna o el equipo Pirate Library Mirror, abreviado como PiLiMi), ​ y publicado en respuesta directa a los esfuerzos de las fuerzas de seguridad, con la ayuda formal de The Publishers Association y Authors Guild, para cerrar el sitio web de Z-Library en noviembre de 2022.

En este sentido, el equipo del Archivo de Anna afirma proporcionar acceso a los metadatos de los materiales de Open Library, ser una copia de seguridad de las bibliotecas fantasma Library Genesis y Z-Library, presentar información sobre ISBN, no almacenar materiales protegidos por derechos de autor en su sitio web y solo indexar metadatos que ya están disponibles públicamente. Anna's Archive señala que su sitio web, un proyecto sin ánimo de lucro, acepta donaciones para cubrir gastos (alojamiento, nombres de dominio, desarrollo y relacionados).

Dejo link:

https://es.annas-archive.org

Clases padres, clases hijas… ¿y las madres qué?

La programación orientada a objetos (POO) nos trajo muchas cosas lindas: encapsulación, herencia, polimorfismo, y sobre todo, la posibilidad de inventarnos familias disfuncionales de clases sin necesidad de pasar por terapia.

Pero hay algo que siempre nos hizo ruido:

• ¿Por qué hablamos de clases padre y clases hijas? 
• ¿Dónde quedaron las madres, los tíos, las primas, o la abuela que todo lo sabe?

Lo más raro es que una clase padre puede ser hija de otra clase. Rarisisimo...

Todo empieza con el inglés. En POO se habla de parent class para referirse a la clase de la cual heredan otras. Y parent, significa “padre o madre”.

Pero claro, en español, por alguna razón misteriosa que seguro involucra a la Real Academia, siempre traducimos parent class como “clase padre”, y no “clase madre” o “clase progenitor/a” (aunque esa última suena a trámites en ANSES).

Entonces… ¿por qué decimos “clase hija”? Acá la gramática mete la cuchara. Como la palabra “clase” es femenina, cuando hablamos de su descendencia lógica usamos “hija” para que concuerde: La clase padre tiene muchas clases hijas.

¿Y si dijéramos “clase madre”?

¡Podemos! No hay ninguna ley que lo impida. De hecho, si queremos romper esquemas y escribir:

class Mamífero // clase madre

class Perro extends Mamífero // clase hija

...nadie de Scala te va a venir a buscar. Al contrario, tal vez sumes puntos con tus profes de literatura.

Eso sí, el término "clase madre" no es tan común, así que si lo usás, preparate para explicar o educar. (O poner una nota al pie tipo “uso madre porque soy inclusivo/a y rebelde”).

La POO no distingue género, pero el lenguaje humano sí. Y en nuestra necesidad de ponerle nombre a todo, terminamos replicando convenciones culturales sin cuestionarlas.

¿Querés decir clase madre? ¡Decilo!

¿Preferís clase base? ¡También está bien!

Lo importante es que tus clases compilen… y que no traumen a sus hijas.

Trabajando con partes de colecciones sin copiar: slices, spans y más

Cuando trabajamos con colecciones o buffers de datos, es muy común necesitar operar solo sobre una parte de ellos: una porción de un array, un segmento de texto, o un rango de bytes. La solución más directa suele ser copiar esa parte a una nueva estructura… pero eso introduce sobrecarga innecesaria de memoria y CPU. Si queremos trabajar con partes de una colección (por ejemplo, un array, un string o un buffer de bytes) sin crear copias, es decir, tener una vista o referencia a un fragmento de la colección original.  

Es decir, queremos qu esta solución sea:

• Ligera en memoria (sin asignaciones adicionales)
• Segura (sin acceder fuera de los límites)
• Eficiente (idealmente sin costo en tiempo de ejecución)

Muchos lenguajes modernos han ido incorporando construcciones para resolver este problema. Veamos cómo lo hacen C#, Go y Rust.

A partir de C# 7.2, se introdujo Span<T>, una estructura de tipo ref struct que representa una ventana sobre memoria contigua. 

int[] datos = { 10, 20, 30, 40 };

Span<int> segmento = datos.AsSpan(1, 2); // contiene {20, 30}

Podés usar Span<T> para:

• Evitar copiar arrays o strings.
• Trabajar con memoria en el stack (stackalloc).
• Reutilizar buffers en pipelines o parsers.
• Procesar archivos grandes en trozos.

Span<byte> buffer = stackalloc byte[1024]; // sin heap

Limitaciones:

• No puede usarse como campo de clases (sólo en structs).
• No se puede usar con async/await ni capturar en lambdas.
• Solo dentro del alcance del stack (por diseño).

Go tiene slices desde siempre: son una capa por encima de los arrays. Un slice guarda un puntero al array subyacente, longitud y capacidad.

arr := [5]int{1, 2, 3, 4, 5}

s := arr[1:4] // contiene {2, 3, 4}

Ventajas:

• Livianos y eficientes.
• Se puede modificar el contenido (afecta al array original).
• Permiten crecer mediante append si hay capacidad.

s[0] = 99 // también cambia arr[1]

La semántica de slicing en Go es natural y permite componer operaciones sin asignar memoria.

Rust maneja este problema con referencias segmentadas: &[T] para vistas inmutables y &mut [T] para mutables.

let arr = [1, 2, 3, 4];

let slice = &arr[1..3]; // &[2, 3]

Características:

• Completamente seguras en tiempo de compilación.
• El borrow checker impide aliasing mutable.
• Altamente eficientes, sin sobrecarga.
• Son la base de muchas APIs estándar.

fn print_slice(s: &[i32]) {

    for val in s {

        println!("{}", val);

    }

}

¿Y cuál conviene?

• Si estás en un lenguaje GC-friendly como C#, Span<T> te da poder sin pagar costo de GC.
• Si buscás simplicidad y velocidad de desarrollo, Go es imbatible con su slicing natural.
• Si necesitás seguridad al máximo y performance nativa, Rust con slices es lo más robusto.

Es decir, depende del lenguaje que estes usando ... 

Y Otros lenguajes tambien tenemos cosas parecidas: 

• C++20: std::span<T> cumple un rol casi idéntico a Span<T> de C#, y también es zero-copy.
• Python: memoryview permite trabajar con buffers sin copiar, aunque menos seguro.
• Java: No tiene slices como tal, pero ByteBuffer puede simularlos.
• Nim, Zig, D: Todos ofrecen slices como vistas eficientes sobre datos.

En la práctica, estas estructuras son fundamentales para escribir código eficiente, especialmente en procesamiento de datos, parsers, sistemas embebidos o cualquier aplicación donde el rendimiento importa.  

Beans Singleton en Spring: ¿Son un riesgo en entornos concurrentes?

Cuando trabajamos con Spring Framework, una de las primeras cosas que aprendemos es que los beans por defecto son singleton. Es decir, Spring crea una única instancia de cada bean y la reutiliza a lo largo de toda la aplicación. Ojo aca, no es igual que el patron singleton, porque el patron singleton es una instancia por clase. Spring realiza una instancia por bean, pero varios beans pueden ser de la misma clase. 

Pero de igual manera nos podemos preguntar ¿No podría causar problemas si múltiples hilos usan el mismo objeto?

Veamos por qué no, y en qué casos sí.

Cuando marcamos una clase con @Component, @Service, @Repository, etc., sin indicar un @Scope, Spring crea una única instancia de esa clase cuando arranca el contexto, y luego la reutiliza para inyectarla donde haga falta.

@Service

public class MiServicio {

    public void hacerAlgo() {

        // lógica

    }

}

Este bean se compartirá entre todas las partes de la aplicación que lo necesiten.

¿Y si lo usan varios hilos?

Acá es donde entra el concepto de thread safety. Si el bean no guarda estado mutable (es stateless), no hay ningún problema. Puede ser accedido por múltiples hilos al mismo tiempo sin consecuencias.

Pero si el bean mantiene estado mutable (por ejemplo, una variable de instancia que se modifica en cada método), entonces puede haber condiciones de carrera, errores y comportamiento impredecible.

Veamos un ejemplo peligroso:

@Component

public class ContadorCompartido {

    private int contador = 0;

    public void incrementar() {

        contador++;

    }

    public int getContador() {

        return contador;

    }

}

Este bean no es thread-safe: si lo usan múltiples hilos al mismo tiempo, el contador puede tener resultados inesperados.

Otra pregunta puede ser ¿Spring crea múltiples instancias si hay mucha carga?

No. Este es un mito común. Spring no crea múltiples instancias de un bean singleton automáticamente bajo carga. La única forma en que podrías tener más de una instancia es:

• Si usamos un @Scope("prototype"), @RequestScope, etc.
• Si instanciás manualmente objetos sin pasar por el contenedor de Spring (lo cual rompe la inyección de dependencias).
• O si usás proxies o mecanismos especiales para aislar contexto por request, como ocurre con algunos beans en entornos web.

Podemos concluir que : 

• Si tu bean necesita guardar estado por usuario o por request, no lo hagas singleton. Usá un scope adecuado.
• Si tu bean puede ser stateless, mantenelo así. Es más simple, más eficiente y seguro en entornos multihilo.
• Si el bean debe tener estado compartido, usá sincronización o mecanismos thread-safe como AtomicInteger, ConcurrentHashMap, etc.

En Spring, los beans singleton son una gran herramienta para reutilización de lógica y eficiencia de memoria. Pero es tu responsabilidad asegurarte de que no mantengan estado mutable que pueda generar conflictos en concurrencia.

Introducción a Elm: Programación Funcional para el Frontend

Elm es un lenguaje de programación funcional, tipado estáticamente, diseñado específicamente para construir interfaces web robustas y sin errores. Es conocido por su simplicidad, rendimiento y su sistema de tipos que prácticamente elimina los errores en tiempo de ejecución.

Elm es un lenguaje compilado que genera JavaScript. Fue creado por Evan Czaplicki y se enfoca en facilitar la construcción de aplicaciones web escalables y mantenibles. Entre sus características más destacadas están:

• Inmutabilidad por defecto
• Sistema de tipos fuerte y sin null
• Compilador amigable
• Arquitectura unificada (Elm Architecture)

¿Por qué usar Elm?

• Cero excepciones en tiempo de ejecución: el sistema de tipos atrapa muchos errores antes de que tu aplicación se ejecute.
• Aplicaciones web rápidas: el código generado es optimizado.
• Mantenimiento más simple: ideal para proyectos grandes gracias a su claridad y estructura.
• El compilador te guía: es uno de los mejores errores de compilación que verás.

Elm organiza las aplicaciones con un patrón simple basado en tres conceptos:

1. Model: el estado de la aplicación
2. Update: cómo cambia el estado
3. View: cómo se representa visualmente el estado

Este patrón ha influido incluso en bibliotecas como Redux en JavaScript.

Veamos un poco de código: 

module Main exposing (..)

import Browser

import Html exposing (Html, button, div, text)

import Html.Events exposing (onClick)

-- Modelo

type alias Model = Int

-- Mensajes

type Msg = Increment | Decrement

-- Estado inicial

init : Model

init = 0

-- Actualización del modelo

update : Msg -> Model -> Model

update msg model =

    case msg of

        Increment -> model + 1

        Decrement -> model - 1

-- Vista

view : Model -> Html Msg

view model =

    div []

        [ button [ onClick Decrement ] [ text "-" ]

        , div [] [ text (String.fromInt model) ]

        , button [ onClick Increment ] [ text "+" ]

        ]

-- Programa principal

main =

    Browser.sandbox { init = init, update = update, view = view }

Este ejemplo muestra un contador que incrementa y decrementa con botones, ¡todo en unas pocas líneas claras!

Herramientas y Ecosistema:

• elm repl: consola interactiva
• elm make: compila Elm a JS
• elm install: para instalar paquetes
• elm-format: para mantener código limpio y uniforme

Elm es una opción excelente para quienes quieren construir interfaces web seguras, claras y libres de errores. Su enfoque funcional y su arquitectura consistente lo convierten en un lenguaje ideal para proyectos de frontend con alta demanda de calidad.

Span en C#: Acceso seguro y eficiente a la memoria

A partir de C# 7.2 y .NET Core 2.1, Microsoft introdujo una de las herramientas más poderosas para manipular memoria sin sacrificar seguridad: Span<T>. Esta estructura permite trabajar con porciones contiguas de memoria (arrays, segmentos de strings, buffers, etc.) de forma eficiente, sin generar asignaciones en el heap ni usar punteros directamente.

Span<T> es una estructura stack-only que representa una ventana mutable sobre un bloque contiguo de memoria. Podés usarlo para acceder, cortar o modificar datos de arrays, slices de strings, buffers nativos, y más, sin necesidad de copiar datos.

Veamos un ejemplo: 

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

Span<int> slice = numbers.AsSpan(1, 3); // Contiene 2, 3, 4

slice[0] = 42;

Console.WriteLine(numbers[1]); // Muestra 42 (modificó el array original)

¿Por qué usar Span<T>?

• Evita copias de memoria innecesarias
• No genera asignaciones en el heap 
• Mejora la performance en procesamiento de strings, buffers y arrays  
• Ofrece seguridad de tipos y bounds-checking
• Solo puede usarse dentro del stack (no puede almacenarse en campos de clase)

Limitaciones:

• No puede usarse en métodos async o iteradores (async, yield return)  
• No puede almacenarse en campos de clase o como parte de objetos del heap
• Si necesitás algo similar pero heap-safe, podés usar Memory<T>

Veamos un ejemplo de string: 

ReadOnlySpan<char> span = "Hola Mundo".AsSpan(5);

Console.WriteLine(span.ToString()); // Mundo

Esto es ideal para parsear strings sin crear substrings intermedias.

Span<T> es una herramienta fundamental si querés escribir código de alto rendimiento en .NET. Es ideal para manipular datos binarios, strings o buffers, con el mínimo impacto en el garbage collector. Aunque tiene limitaciones (no se puede escapar del stack), su potencia compensa con creces en escenarios críticos de performance.

Simular punteros en Javascript

JavaScript no tiene punteros como en C o C++, pero sí se puede simular su comportamiento usando objetos y referencias. En JavaScript, los objetos se pasan por referencia, lo que significa que si modificas una propiedad del objeto dentro de una función, el cambio se refleja afuera.

Veamos un ejemplo:

function incrementar(valor) {

    valor.numero++;

}

let puntero = { numero: 10 };

incrementar(puntero);

console.log(puntero.numero); // 11

Aquí puntero simula un puntero: su campo numero puede ser modificado por funciones.

Se pasa la referencia al objeto, no una copia.

Otra forma es con arreglos para simular puntero a variables primitivas

function setValor(arr, nuevoValor) {

    arr[0] = nuevoValor;

}

let x = [5];

setValor(x, 42);

console.log(x[0]); // 42

x es un arreglo de un solo elemento. Se comporta como una caja que puede modificarse dentro de funciones.

Esto puede verse como una simulación de un int* en C++.

Veamos un ejemplo sin utilizar funciones: 

let a = { valor: 10 };

let b = a; // b apunta al mismo objeto que a

b.valor = 99;

console.log(a.valor); // 99

console.log(b.valor); // 99

a y b apuntan al mismo objeto.

Cambiar b.valor también afecta a.valor.

También se puede utilizar arreglos:

let x = [42];

let y = x;

y[0] = 100;

console.log(x[0]); // 100

console.log(y[0]); // 100

En JavaScript, los valores primitivos (números, strings, booleanos, etc.) se pasan por valor, pero los objetos y arrays se pasan por referencia y podemos utilizarlos para simular punteros.

¿Qué significa Nullable en el archivo .csproj de C#?

Desde C# 8, el lenguaje introdujo el análisis de nulabilidad (nullable reference types), una herramienta poderosa para ayudarte a detectar posibles null en tiempo de compilación. Esta funcionalidad se activa o desactiva con la propiedad <Nullable> en el archivo .csproj.

Cuando está activado, el compilador trata los tipos de referencia como no anulables por defecto, a menos que explícitamente los marques con ?.

Veamos un ejemplo: 

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

  <PropertyGroup>

    <TargetFramework>net8.0</TargetFramework>

    <Nullable>enable</Nullable>

  </PropertyGroup>

</Project>

Y en el projecto: 

string name = null; // Warning: posible asignación nula

string? nickname = null; // Permitido

con Nullable deshabilitado:

string name = null; // No hay advertencias, aunque puede fallar en runtime

Activar Nullable te permite:

• Recibir advertencias si estás usando variables que podrían ser null.
• Hacer que tus APIs sean más expresivas (string? vs string).
• Reducir errores en tiempo de ejecución por NullReferenceException.
• Trabajar mejor con herramientas de análisis estático.

Usar <Nullable>enable</Nullable> en tus proyectos de C# modernos es una excelente práctica. Aumenta la robustez del código y te da más control sobre los errores relacionados con null, una de las fuentes más comunes de fallos en producción.