viernes, 18 de septiembre de 2020

Corre Groovy en tu browser con Grooscript


Si existe Scala.js por que no puede existir un Groovy que corra en el browser. Y existe y se llama Grooscript. 

Grooscript es todo lo que has soñado y si no lo soñaste te cuento. Este es un lenguaje muy similar a groovy que compila a javascript. 

Y se puede utilizar en framework como node, veamos un ejemplo: 

//DSL using Node.js with Express

server {
    get('/') {
        render 'Hello World!'
    }
    get('/spanish') {
        render 'Hola Mundo!'
    }
    get('/salute/:name') {
        render "Hello ${req.params.name}!"
    }
}.start(3000)


Para poder utilizarlo debemos instalar node y groovy y luego instalar con npm grooscript : 

> npm install grooscript


Luego de instalada podemos crear nuestros archivos groovy, por ejemplo : 

class Hello {

  def methodMissing(String name, args) {

    println "Hello ${name}!"

  }

}

def hello = new Hello()

hello.Groovy()

hello.Javascript()

hello.grooscript()


Luego tenemos que compilar este script groovy a javascript : 

 @Grab('org.grooscript:grooscript:1.2.2')

import org.grooscript.GrooScript


def conversionOptions = [:]

conversionOptions['initialText'] = "var gs = require('grooscript');"

GrooScript.convert 'source.groovy', '.', conversionOptions


luego con este último script, compilamos el script inicial de la siguiente forma : 

groovy convert.groovy

con este paso obtenemos el source.js, que podemos ejecutarlo así  : 

> node source.js

Hello Groovy!

Hello Javascript!

Hello grooscript!

Y listo, se ve que esta tecnología esta en pañales pero agárrate typescript!!



lunes, 14 de septiembre de 2020

for/else de python


Hay muchas cosas que no sé y llego tarde, una es esta. Existe en python el for/else. 

Como es esto? La cláusula else se ejecuta después de que el ciclo se completa normalmente. Esto significa que el bucle no encontró una declaración de interrupción o break.

Por ejemplo : 

 for item in container:

    if search_something(item):

        # Found it!

        process(item)

        break

else:

    # Didn't find anything..

    not_found_in_container()

Esto nos libra de tener una variable bandera para saber si salio del for por el break o porque completo el for. Muy útil, muy fácil, y listo!


domingo, 13 de septiembre de 2020

Rosetta code


Encontré una pagina, que hace siglos que esta en Internet pero yo no la había visto antes, y como para mi es noticia. La quiero compartir con ustedes. 

Es una pagina donde hay código de muchos lenguajes, casi todos.  La idea es presentar soluciones a la misma tarea en tantos lenguajes diferentes como sea posible, demostrando cómo los lenguajes son similares y diferentes, y ayudar a una persona con una base en un enfoque de un problema para aprender otro. Rosetta Code tiene actualmente 1.067 tareas, 206 borradores de tareas y 800 lenguajes.

Dejo link: http://www.rosettacode.org/wiki/Rosetta_Code

sábado, 12 de septiembre de 2020

Utilizar valores implícitos atenta contra la legibilidad del código?


El Zen de Python dice : Explicit is better than implicit o Explícito es mejor que implícito. Cosa que me ha dejado pensando porque no aplica siempre. Por ejemplo: 

boolean b;

if (b == true) then: ...

b por defecto es false, pero no se lo estamos diciendo, en este caso yo particularmente prefiero ser explicito, es decir dejar claro cual es el valor de la variable: 

boolean b = false

pero me choca y me disgusta (es que ya estoy viejo) el if , es como que el programador no tiene en cuenta que b es un dato. Y ese dato lo podemos comprobar, prefiero: 

if (b) then: ...

Pero hay cosas implicitas en los lenguajes que a mi modo de ver las cosas, atentan contra la legibilidad. 

El caso más fácil de ejemplificar es que valores de otros tipos sean false o true, eso hace más fácil a vida del experto pero sin duda no deja tan clara las cosas. Por ejemplo: 

if (typeof(some_variable) != 'undefined' && some_variable != null)

{

    // Do something with some_variable

}

por : 

if (some_variable)

{

    // Do something with some_variable

}

Claro que la ultima es más corto, pero que diablos hace? Si sabes javascript es fácil, pero lo puede entender todo el mundo? 

Que opinan?

Feliz Día!!


Dice la wikipedia: El Día de los Programadores es un día festivo profesional oficial en algunos países del mundo.[¿cuál?] Se celebra el 256º día de cada año (13 de septiembre durante los años normales y el 12 de septiembre durante los bisiestos)

Por lo tanto, Feliz día!!!!

jueves, 10 de septiembre de 2020

Libros gratuitos de Java Code Geeks

 

Download IT Guides!

 

Microservices for Java Developers

Microservices are a software development technique – a variant of the service-oriented architecture (SOA) structural style – that arranges an application as a collection of loosely...

 
 

JMeter Tutorial

JMeter is an application that offers several possibilities to configure and execute load, performance and stress tests using different technologies and protocols. It allows simulating...

 
 

Java Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be...

 
 

Elasticsearch Tutorial

Elasticsearch is a search engine based on Lucene. It provides a distributed, multitenant-capable full-text search engine with an HTTP web interface and schema-free JSON documents....

 

miércoles, 9 de septiembre de 2020

Por qué AdoptOpenJDK te pregunta sobre utilizar OpenJ9 o HotSpot?

Una JDK debe proporcionar :

  • Un compilador de lenguaje de programación Java para crear archivos de código de bytes de Java .class a partir de sus archivos de código fuente .java.
  • Una máquina virtual de Java (JVM) que puede, en tiempo de ejecución, interpretar y / o compilar esos archivos de código de bytes de Java, convirtiéndolos en código ejecutable que puede ejecutarse en los núcleos de la computadora host utilizando el conjunto de instrucciones nativo de esa CPU.
  • Un entorno de ejecución que conecta las aplicaciones Java con los recursos de la máquina host, como el sistema de archivos y la instalación de red.
  • Un conjunto obligatorio de bibliotecas de clases de Java (java.util, java.time, etc.).
  • Una implementación de Java tiene la opción de proporcionar un compilador / optimizador Just-In-Time (JIT) como parte de la JVM. El proyecto OpenJDK incluye código fuente para HotSpot JIT.

Las personas que proporcionan compilaciones o instaladores para la plataforma Java son libres de usar HotSpot o de elegir otra tecnología de compilación JIT. OpenJ9 en uno de esos JIT alternativos, desarrollado en IBM, ahora de código abierto a través de la Fundación Eclipse, y se proporciona de forma gratuita. En el pasado, otro JIT alternativo era JRockit, propiedad de Oracle. Partes de JRockit se han fusionado en la versión actual de HotSpot.


El proyecto AdoptOpenJDK ofrece la opción entre el motor HotSpot proporcionado por Oracle a través del proyecto OpenJDK o el motor OpenJ9 alternativo proporcionado por Eclipse Foundation.

Con cualquiera de las opciones, obtiene las mismas bibliotecas de clases de la base de código OpenJDK, las mismas herramientas que incluyen Mission Control y Flight Recorder de OpenJDK, y las mismas utilidades de OpenJDK. Solo el JIT / JVM es diferente si elige HotSpot u OpenJ9.


AdoptOpenJDK es sólo uno de los varios proveedores que ofrecen distribuciones de tecnología Java como binarios / instaladores. La mayoría de estos se basan principalmente, si no completamente, en las versiones del código fuente del proyecto OpenJDK. A continuación, se muestra un diagrama de flujo que muestra los distintos proveedores.



Y aquí hay una lista de posibles motivaciones a considerar al seleccionar un proveedor.



domingo, 6 de septiembre de 2020

Agda


 Agda es un lenguaje funcional con dependently typed. Pero que es dependently typed? 

Te lo explico en este post : https://emanuelpeg.blogspot.com/2016/03/dependently-typed-languages.html

Pero si te da fiaca ir, te cuento: 

Dependent type es un concepto de la programación pero también de la lógica; Dependent type es un tipo que depende de un valor. En la programación funcional se utiliza para prevenir errores, al permitir un sistema de tipo extensivo.

Dependent type añaden complejidad a un sistema de tipos. Es decir, para saber un tipo en algunos casos se deben realizar cálculos o ejecutar sentencias; esto hace bastante complejo el proceso de chequeo de tipos; y en algunos casos imposible. Pero algunos aspectos del comportamiento de un programa se pueden especificar con precisión en el tipo.

Que ventajas trae Dependently typed:

  • Se pueden encontrar más errores en tiempo de compilación
  • Editores que nos ayuden más
  • Puede checkear que los elementos de tu programa estén bien.
Agda se basa en la teoría de tipos intuicionista, un sistema fundamental para las matemáticas constructivas desarrollado por el lógico sueco Per Martin-Löf. Tiene muchas similitudes con otros lenguajes basados en dependently typed, como Coq, Epigram, Matita y NuPRL.

Agda es de código abierto y disfruta de las contribuciones de muchos autores. El centro del desarrollo de Agda es el grupo Programming Logic en Chalmers y la Universidad de Gotemburgo. Los principales desarrolladores son Ulf Norell, Nils Anders Danielsson, Andreas Abel y Jesper Cockx.

Vamos un pequeño ejemplo, definimos un tipo y luego la suma : 

data Nat : Set where
zero : Nat
suc : Nat -> Nat

_+_ : Nat -> Nat -> Nat
zero + m = m
suc n + m = suc (n + m)

y multiplicar : 

_*_ : Nat -> Nat -> Nat
zero * m = zero
suc n * m = m + n * m

Dejo link : 

Manejo de errores en Go vs Rust



Sin duda alguna si hablamos de lenguajes de sistemas los que están haciendo más ruido hoy en día son Go y Rust. 

Son lenguajes que se pensaron para la performance y son de más bajo nivel que Java o Python. Pero a pesar de eso son lenguajes modernos que tienen una especial visión de los errores. 

Go utiliza valores de error para indicar un estado anormal. Por ejemplo, la función os.Open devuelve un valor de error que no es nulo cuando no puede abrir un archivo.

func Open(name string) (file *File, err error)

Por lo tanto si queremos ver si ocurrio un error podemos hacer : 

f, err := os.Open("filename.ext")

if err != nil {

    log.Fatal(err)

}

Lo interesante de esta visión es que nos alejamos del pensamiento o la filosofía de Java en el que el error es un valor especial que debe ser lanzado o tratado, y no es necesario utilizar secuencias try-catch. 

En cambio Rust tiene una visión más funcional, maneja los errores como Haskell. Es decir, devuelve algo llamado Result.

El tipo Result <T, E> es una enumeración que tiene dos variantes: Ok (T) para valor exitoso o Err (E) para valor de error:

enum Result<T, E> {

   Ok(T),

   Err(E),

}

Devolver errores en lugar de lanzarlos es un cambio de paradigma en el manejo de errores y es similar a lo que hace Go, pero en este caso me gusta mucho más porque funciona muy bien con pattern matching pero vamos de a poco.

Si necesitamos ignorar el manejo de errores, no sé porque estamos seguros que no va a pasar o solo porque somos inconscientes podemos utilizar unwrap, por ejemplo : 

use std::fs;

fn main() {

  let content = fs::read_to_string("./Cargo.toml").unwrap();

  println!("{}", content)

}

Aunque sabemos que el archivo estaría presente, el compilador no tiene forma de saberlo. Entonces usamos unwrap para decirle al compilador que confíe en nosotros y devuelva el valor. Si la función read_to_string devuelve un valor Ok (), desenvolver obtendrá el contenido y lo asignará a la variable de contenido. Si devuelve un error, el programa entrará en pánico. Panic termina el programa o sale del hilo actual. (en otro post voy a hablar de panic!) 

expect es lo mismo que unwrap pero nos permite agregar un mensaje de error adicional.

use std::fs;

fn main() {

  let content = fs::read_to_string("./Cargo.toml").expect("Can't read Cargo.toml");

  println!("{}", content)

}

También tenemos varios métodos que nos permiten hacer algo si sale un error cuando desenvolvemos un valor, como unwrap_or_else, unwrap_or_default, veamos un ejemplo : 

use std::env;

fn main() {

  let port = env::var("PORT").unwrap_or("3000".to_string());

  println!("{}", port);

}

Muy elegante, me gusta mucho en Go deberíamos hacer : 

port, ok := os.LookupEnv("PORT")

if !ok {

port = 3000

En Rust tambien podemos utilizar pattern matching que lo hace un tanto más fácil de leer, veamos un ejemplo:

fn main() {
  match fxParaLeerData() {
    Ok(data) => println!("pudimos leer {}!!", data),
    Err(e) => eprintln!("Hubo un problema  {}", e),
  }
}

La verdad que me gusta mucho más el concepto de try-catch es como que separa más la lógica de el manejo de problemas o errores. Más allá de esta opinión creo que una visión más elegante fue la que tomo Rust. Por favor dejen su opinión. 

Hasta acá llego el post pero seguro que va a ver parte 2 ... 


jueves, 3 de septiembre de 2020

Rust 1.46.0 fue liberada


La versión 1.46.0 de Rust fue liberada. Esta versión trae mejoras a las habilidades de escritura const fn, estabiliza el # [track_caller] que promete un mejor manejo de errores y múltiples adiciones o estabilizaciones a las bibliotecas estándar. La lista completa de características está aquí: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1460-2020-08-27

Las características del lenguaje central que se pueden usar en contextos estáticos se acaban de ampliar, por lo que a partir de esta versión se pueden usar operadores condicionales (if, if let y match), bucles (while, while let y loop) y operadores bit a bit (&& y | |) en contextos estáticos. También es posible lanzar y coaccionar un corte o incluso usar mem :: transmute. Aunque estas características de lenguaje no son nuevas, su principal beneficio está en el espacio de rendimiento, por ejemplo, durante un ejercicio en Microsoft, trajo una mejora de 40 veces en los enlaces de Microsoft WinRT para Rust en comparación con la implementación de C ++. Siguiendo la misma idea, también el método std :: mem :: olvide ahora es una constante fn.

Ahora pueden usar enlaces dinámicos para las plataformas Apple iOS y tvOS. Esto es posible al permitir como target cdylib en las plataformas Apple iOS y tvOS.

También en el lado de la estabilidad, en el lado de la API, Option :: zip y vec :: Drain :: as_slice se estabilizaron en la versión actual. Mientras que en el lado de las bibliotecas, también ocurrieron cambios, entre los cuales String implementa From <char> que permite la escritura de la siguiente construcción:

fn char_to_string() -> String {

  'a'.into()

}

Dejo link:

https://blog.rust-lang.org/2020/08/27/Rust-1.46.0.html

miércoles, 2 de septiembre de 2020

Que es Inyección de dependencia y como funciona en Asp.net con .net core?


Empecemos por el principio, .net Core es un Framework de código abierto creado por Microsoft, que nos proporciona herramientas para el desarrollo de aplicaciones multiplataforma lo que significa que podemos desarrollar y ejecutar una aplicación en varios sistemas operativos, como Linux, Windows, iOS. Se pueden desarrollar en .net Core: aplicaciones de escritorio, aplicaciones web, aplicaciones móviles, juegos, inteligencia artificial, etc.

ASP.NET Core es un marco de trabajo para desarrollar aplicaciones web multiplataforma compilado con .Net Core.

Una técnica muy utilizada en java y tambien en .net es la inyección de dependencias que es una técnica en la que un objeto suministra las dependencias de otro. Está técnica nos permite evitar la creación de objetos, para lograr legibilidad y reuso de código.

Cualquier aplicación no trivial está formada por dos o más clases que colaboran entre sí para realizar alguna lógica. Tradicionalmente cada objeto se hacía cargo de obtener sus propias referencias a los objetos a los cuales colaboraba (sus dependencias). Esto lleva a código acoplado y difícil de probar.

Cuando se aplica inyección de dependencia le decimos a una entidad externa que provea las dependencias a los objetos. Esto nos resuelve el problema del acoplamiento.

El acoplamiento es un mal necesario ya que sin él los objetos no podrían interactuar para resolver problemas, pero cuan menor sea el acoplamiento es más reutilizable, comprobable y flexible.

La ventaja clave de inyección de dependencia es el acoplamiento débil. Si un objeto solo conoce sus dependencias mediante su interfaz (no su implementación o como fueron definidos) entonces la dependencia puede intercambiarse con una implementación diferente sin que el objeto dependiente sepa la diferencia.

La inyección de dependencias es una de las maneras de implementar Inversión de Control o IoC.

Netcore posee soporte nativo para Inyección de Dependencias, el cual es utilizado en Asp.net

Para injectar objetos, debemos utilizar los constructores de la clase. En los constructores indicamos que debe injectar el contenedor de .net, por ejemplo :

   public class EjemploService

    {                

        public EjemploService(UnRepositorio repository)

        {

            ...

        }

    }

En el ejemplo se puede ver que se esta inyectando un UnRepositorio al servicio EjemploService y el contenedor puede saber que inyectar, dado que busca en la clase Startup que instancia debe injectar según el tipo. Esto se indica con esta linea :

services.AddTransient<UnRepositorio, UnRepositorioImpl>();

En la clase Startup.

Algo que no dije es que UnRepositorio debe ser una interfaz.De esta forma desacopamos la implementación. 

La clase Startup esta contenida en el archivo Startup.cs en la carpeta raíz del proyecto.

Las aplicaciones ASP.NET Core debe incluir esta clase. Como su nombre indica, se ejecuta primero cuando se inicia la aplicación. Y tiene como objetivo brindar un conjunto de configuraciones para que nuestra aplicación pueda funcionar.

El método ConfigureServices es un lugar donde se registran las clases dependientes en el contenedor IoC o injección de dependencia. Después de registrar la clase dependiente, se puede usar en cualquier lugar de la aplicación. Solo necesita incluirlo en el parámetro del constructor de una clase donde desea usarlo y el contenedor de IoC lo inyectará automáticamente.

El método Configure es un lugar donde puede configurar la canalización de solicitudes de aplicaciones para su aplicación utilizando la instancia IApplicationBuilder que proporciona el contenedor IoC.


viernes, 28 de agosto de 2020

Que lenguaje de programación debo aprender?


Este es un post de opinión no me apoyo en ninguna encuesta o nada, es opinión de lo que voy leyendo. A la vez ya hice post similares pero lo actualice a 2020. 

Dicho esto, me pongo a opinar. Si queres aprender un lenguaje de programación, lo que primero que debes hacer es pensar a que te queres dedicar. Dado que la programación tiene varios objetivos y si bien hay lenguajes que son buenos para todo pero no son populares en todo, por lo tanto, dependiendo a que te queres dedicar es el lenguaje que debes aprender. 

Voy a listar temas y poniendo los lenguajes. 

Backend : Java, C#, Kotlin, Scala, Groovy, PHP, Python, Haskell, Go, SQL, Ruby

Frontend : Javascript, Typescript, Elm

Mobile : Java, Kotlin, C#, Dart

Data science : SQL, Python, Julia, R

Sistemas (bajo nivel) : Rust, Go, C

Sistemas concurrentes : Rust, Go, Scala, Haskell, Erlang, Elixir

Juegos : C, C++, Rust, Go, Lua, Elm, C#



miércoles, 26 de agosto de 2020

Cursos Gugler

Quiero invitarlos a los cursos Gugler que están muy buenos y son super baratos, etc ...





sábado, 22 de agosto de 2020

Cursos en developer.android.com


Si querer llegue a https://developer.android.com/courses y me sorprendió por sus cursos gratuitos de buena calidad por lo tanto quiero compartirlo con ustedes. 

Hay cursos en Java y Kotlin, de android por supuesto y nada más...

Se liberó TypeScript 4.0


Bueno una pequeña noticia y que los cambios en Typescript 4.0 no son tan importantes según lo dicho por el amigo Daniel en su post : 

"Con TypeScript 4.0, no hay grandes cambios importantes. De hecho, si es nuevo en el idioma, ahora es el mejor momento para comenzar a usarlo. La comunidad ya está aquí y está creciendo, con un código de trabajo y excelentes recursos nuevos para aprender. Y una cosa a tener en cuenta: a pesar de todas las cosas buenas que traemos en 4.0, ¡realmente solo necesita conocer los conceptos básicos de TypeScript para ser productivo!"

Sin más dejo link de la noticia: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0/?fbclid=IwAR0aL7qtBCxgg7CAUYnq2gQInc8yzpepkJUP0IwHk2l_-Vj0zF4EmKLO0dQ


miércoles, 19 de agosto de 2020

Que es Ownership en Rust ? Parte 2




Ya hemos visto literales de cadena, donde un valor de cadena está codificado en nuestro programa. Los literales de cadena son convenientes, pero no son adecuados para cada situación en la que deseemos usar texto. Una razón es que son inmutables. Otra es que no todos los valores de cadena se pueden conocer cuando escribimos nuestro código: por ejemplo, ¿qué pasa si queremos tomar la entrada del usuario y almacenarla? Para estas situaciones, Rust tiene un segundo tipo de cadena, String. Este tipo se asigna en el Head y, como tal, puede almacenar una cantidad de texto que no conocemos en el momento de la compilación. Puede crear una cadena a partir de un literal de cadena usando la función from, de esta manera:

let s = String::from("hello");

Los dos puntos (::) permiten obtener un string de la palabra. 

Este tipo de cadena se puede mutar:

    let mut s = String::from("hello");

    s.push_str(", world!"); // push_str() appends a literal to a String

    println!("{}", s); // This will print `hello, world!`

Entonces, ¿cuál es la diferencia aquí? ¿Por qué String puede mutar pero los literales no? La diferencia es cómo estos dos tipos manejan la memoria.

En el caso de un literal de cadena, conocemos el contenido en tiempo de compilación, por lo que el texto se codifica directamente en el ejecutable final. Es por eso que los literales de cadena son rápidos y eficientes. Pero estas propiedades solo provienen de la inmutabilidad del literal de cadena. Desafortunadamente, no podemos poner una gota de memoria en el binario para cada fragmento de texto cuyo tamaño se desconoce en el momento de la compilación y cuyo tamaño puede cambiar mientras se ejecuta el programa.

Con el tipo String, para admitir una parte de texto mutable y ampliable, necesitamos asignar una cantidad de memoria en el Head, desconocida en el momento de la compilación, para contener los contenidos. Esto significa:

La memoria debe solicitarse al asignador de memoria en tiempo de ejecución.

Necesitamos una forma de devolver esta memoria al asignador cuando hayamos terminado con nuestra cadena.

Nosotros hacemos la primera parte: cuando llamamos a String :: from, su implementación solicita la memoria que necesita. Esto es bastante universal en los lenguajes de programación.

Sin embargo, la segunda parte es diferente. En lenguajes con un recolector de basura (GC), el GC realiza un seguimiento y limpia la memoria que ya no se usa, y no tenemos que pensarlo. Sin un GC, es nuestra responsabilidad identificar cuándo ya no se usa la memoria y llamar al código para devolverlo explícitamente, tal como lo hicimos para solicitarlo. Hacer esto correctamente ha sido históricamente un problema de programación difícil. Si lo olvidamos, desperdiciaremos memoria. Si lo hacemos demasiado pronto, tendremos una variable no válida. Si lo hacemos dos veces, eso también es un error. Necesitamos emparejar exactamente una asignación con exactamente una libre.

Rust toma un camino diferente: la memoria se devuelve automáticamente una vez que la variable que la posee queda fuera de alcance. Aquí hay una versión de nuestro ejemplo de alcance usando una Cadena en lugar de una cadena literal:

    {
        let s = String::from("hello"); // s is valid from this point forward

        // do stuff with s
    }

Hay un punto natural en el que podemos devolver la memoria que nuestro String necesita al asignador: cuando s sale del alcance. Cuando una variable queda fuera de alcance, Rust llama a una función especial para nosotros. Esta función se llama soltar, y es donde el autor de String puede poner el código para devolver la memoria. Las llamadas de Rust caen automáticamente en el corchete de cierre.

Nota: En C ++, este patrón de asignación de recursos al final de la vida útil de un elemento a veces se denomina Adquisición de recursos es inicialización (RAII). La función de caída en Rust le resultará familiar si ha utilizado patrones RAII.

Este patrón tiene un profundo impacto en la forma en que se escribe el código Rust. Puede parecer simple en este momento, pero el comportamiento del código puede ser inesperado en situaciones más complicadas cuando queremos que múltiples variables usen los datos que hemos asignado en el Head. 

martes, 18 de agosto de 2020

Que es Ownership en Rust ?


Primero aclaro que no quise traducir Ownership a Propiedad o algo así porque normalmente en videos y eventos se habla de Ownership por lo tanto me parece lo más acertado seguir con esto. 

La característica central de Rust es el Ownership. Aunque es la característica es fácil de explicar, tiene profundas implicaciones para el resto del lenguaje.

Ownership es la característica más exclusiva de Rust, y le permite a Rust garantizar la seguridad de la memoria sin necesidad de un recolector de basura. Por lo tanto, es importante comprender cómo funciona el Ownership en Rust.

Todos los programas tienen que administrar la forma en que usan la memoria de una computadora mientras se ejecutan. Algunos lenguajes tienen un recolector de basura que constantemente busca memoria que ya no se usa mientras se ejecuta el programa como java; en otros lenguajes como C, el programador debe asignar explícitamente y liberar la memoria. Rust utiliza un tercer enfoque: la memoria se administra a través de un sistema de propiedad o Ownership con un conjunto de reglas que el compilador verifica en el momento de la compilación. Ninguna de las funciones de Ownership ralentiza su programa mientras se está ejecutando.

En muchos lenguajes de programación, no tiene que pensar en el stack y el heap con mucha frecuencia. Pero en un lenguaje de programación de sistemas como Rust, si un valor está en la stack o en el heap tiene efectos sobre cómo se comporta el lenguaje y por qué tiene que tomar ciertas decisiones. 

Tanto el stack como el heap son partes de la memoria que están disponibles para que su código las use en tiempo de ejecución, pero están estructuradas de diferentes maneras. El stack almacena valores en el orden en que los obtiene y elimina los valores en el orden opuesto. Esto se conoce como último en entrar, primero en salir es una pila. 

Todos los datos almacenados en la pila deben tener un tamaño fijo conocido. Los datos con un tamaño desconocido en el momento de la compilación o un tamaño que podría cambiar deben almacenarse en el heap. El heap está menos organizado: cuando coloca datos, solicita una cierta cantidad de espacio. El sistema operativo encuentra un lugar vacío que sea lo suficientemente grande, lo marca como en uso y devuelve un puntero, que es la dirección de la ubicación. Este proceso se denomina asignación en el heap y a veces se abrevia como asignación. Insertar valores en la pila no se considera asignación. Debido a que el puntero es un tamaño fijo conocido, puede almacenar el puntero en la pila, pero cuando desee los datos reales, se debe seguir el puntero.

Agregar datos a el stack es más rápido que asignar en el heap porque el sistema operativo nunca tiene que buscar un lugar para almacenar nuevos datos; esa ubicación siempre está en la parte superior de la pila. Comparativamente, la asignación de espacio en el heap requiere más trabajo, porque el sistema operativo primero debe encontrar un espacio lo suficientemente grande como para contener los datos y luego realizar la contabilidad para prepararse para la próxima asignación.

Acceder a los datos en el heap es más lento que acceder a los datos en el Stack porque tienes que seguir un puntero para llegar allí. Los procesadores son más rápidos si saltan menos en la memoria. 

Cuando su código llama a una función, los valores pasados ​​a la función (incluidos, potencialmente, punteros a los datos del heap) y las variables locales de la función se insertan en el Stack. Cuando termina la función, esos valores se sacan.

Realizar un seguimiento de qué partes del código están utilizando qué datos en el heap, minimizar la cantidad de datos duplicados en el heap y limpiar los datos no utilizados en el heap para que no se quede sin espacio son todos problemas que el Ownership aborda.

Primero, echemos un vistazo a las reglas de Ownership:
  • Cada valor en Rust tiene una variable que se llama su propietario.
  • Solo puede haber un propietario a la vez.
  • Cuando el propietario sale del alcance, el valor se descartará.
Como primer ejemplo de Ownership, veremos el alcance de algunas variables. Un ámbito es el rango dentro de un programa para el cual un artículo es válido. Digamos que tenemos una variable que se ve así:

let s = "hello";

La variable s se refiere a un literal de cadena, donde el valor de la cadena está codificado en el texto de nuestro programa. La variable es válida desde el punto en el que se declara hasta el final del alcance actual. El listado 4-1 tiene comentarios que indican dónde la variable s es válida.

{                      // s is not valid here, it’s not yet declared
        let s = "hello";   // s is valid from this point forward

        // do stuff with s
 }     

En otras palabras, hay dos puntos importantes en el tiempo aquí:

Cuando s entra en el alcance, es válido.
Sigue siendo válido hasta que se salga del alcance.

En este punto, la relación entre los ámbitos y cuando las variables son válidas es similar a la de otros lenguajes de programación. Ahora construiremos sobre esta comprensión introduciendo el tipo de cadena.

Ya me quedo muy largo seguimos en otro post... 

Dejo link: 
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

domingo, 16 de agosto de 2020

university.mongodb.com


Ya he publicado esto antes pero ha crecido tanto que vale la pena recordarles que si quieren saber de mongodb tienen que ir a su universidad. 

Dejo link: https://university.mongodb.com/

sábado, 15 de agosto de 2020

Micronaut 2.0


Object Computing, Inc. (OCI) ha lanzado formalmente Micronaut 2.0, una versión importante del marco de trabajo basado en JVM que ayuda a crear aplicaciones sin servidor, nativas de la nube y basadas en microservicios que utilizan lenguajes como Java, Groovy y Kotlin.

Esta nueva versión mejora significativamente la experiencia del desarrollador con la disponibilidad de Micronaut Launch, una CLI de Micronaut más rápida y completamente renovada, un nuevo complemento de Maven y una actualización a la versión de Gradle. Ahora es compatible con Java 14, aplicaciones escritas en Groovy 3 y marcos reactivos que incluyen RxJava 3 y Reactor. Las capacidades sin servidor se han ampliado al agregar compatibilidad con Azure Functions y Cloud Functions de Google. También proporciona soporte para HTTP/2 y Servlets y un diseño de seguridad renovado. Finalmente, la nueva versión proporciona un rendimiento mejorado con una integración más profunda con GraalVM, consumo de memoria optimizado y tiempos de inicio mejorados hasta en un 20% en promedio en todo el marco.

Micronaut 2.0 incluye un nuevo servicio de inicio, Micronaut Launch, que ayuda a crear un andamio en las aplicaciones basadas en Micronaut. Disponible tanto como una herramienta basada en navegador como como una API REST, Launch ayuda a construir rápidamente y generar aplicaciones basadas en Micronaut. También ofrece una vista previa de la aplicación generada. La CLI de Micronaut tradicional ha pasado por un rediseño completo con un enfoque en el rendimiento y la eficiencia utilizando imágenes nativas de GraalVM. Micronaut Launch, un wrapper de Micronaut CLI, garantiza la interoperabilidad.

EL soporte de Maven se ha actualizado para traerlo a la paridad de características con el conjunto de características actual de Gradle. Se proporciona un nuevo complemento de Maven (mn: run) que ayuda a ejecutar aplicaciones Micronaut a través de Maven con capacidades de recompilación y reinicio automáticos. Además de esto, los proyectos de Maven heredan de un nuevo POM padre que configura la gestión de dependencias de forma más limpia.

La versión de Gradle se ha actualizado a 6.5, lo que brinda soporte de compilación incremental para proyectos de Micronaut 2.0. Básicamente, esto significa que Micronaut no tiene que ejecutar los procesadores de anotaciones completos para cada compilación.

El soporte sin servidor se ha hecho más sólido con la adición de Google Cloud Functions y Azure Functions, al tiempo que se mejora el conjunto de características para AWS Lambda. Micronaut proporciona dos enfoques para ayudar a crear aplicaciones sin servidor. El primer enfoque define una aplicación Micronaut tradicional y le agrega la característica de función sin servidor correspondiente (por ejemplo, funciones en la nube, funciones de Azure o lambdas). Dependiendo de la plataforma sin servidor elegida, Micronaut proporcionará la infraestructura de plomería necesaria para enrutar las solicitudes de funciones a la aplicación.

El segundo enfoque define un tipo de aplicación de "función sin servidor" que permite a los desarrolladores escribir código de función directo de bajo nivel específico para la función de función sin servidor elegida (p. Ej., Funciones en segundo plano de Google Cloud que se suscriben a mensajes pub-sub).

A continuación se muestra un ejemplo de una función sin servidor de bajo nivel escrita en Micronaut para la plataforma sin servidor de funciones de Google Cloud.

public class Function extends GoogleFunctionInitializer

        implements BackgroundFunction<PubSubMessage> {

    @Inject LoggingService loggingService;

    @Override

    public void accept(PubSubMessage message, Context context) {

        loggingService.logMessage(message);

    }

}

class PubSubMessage {

    String data;

    Map<String, String> attributes;

    String messageId;

    String publishTime;

}

Otras características que han llegado a la nueva versión incluyen la capacidad de probar funciones localmente utilizando los SDK proporcionados por la plataforma sin servidor que Micronaut incluye como dependencia y el soporte de imágenes nativas de GraalVM para AWS SDK 2.

Además de Netty, Micronaut 2.0 ahora agrega soporte para tiempos de ejecución de servlet integrados (Jetty / Tomcat / Undertow). Esto permite a los desarrolladores utilizar funciones tradicionales basadas en servlets en sus aplicaciones Micronaut. La experiencia de desarrollar aplicaciones Micronaut basadas en servlets es la misma que usar Netty para incluir recompilación automática / pruebas más rápidas, etc. Esto también incluye la capacidad de crear imágenes nativas basadas en GraalVM para los archivos uber basados en servlets.

A continuación se muestra un ejemplo de cómo crear una aplicación Micronaut basada en servlets utilizando la CLI y luego ejecutarla. Esto usa la función de servidor de embarcadero.

mn> create-app demo-servlet --features jetty-server

$ cd demo-servlet

$ ./gradlew run

org.eclipse.jetty.server.Server - Started @1219ms

io.micronaut.runtime.Micronaut - Startup completed in 615ms. Server Running: http://localhost:8080/

Micronaut 2.0 agrega soporte para HTTP / 2 y se puede habilitar usando un simple cambio en el archivo application.yml para una aplicación Micronaut. Este soporte está disponible actualmente solo para el servidor HTTP y el cliente basados en Netty.

La configuración del lado del servidor se muestra a continuación.

micronaut:

  ssl:

build-self-signed: true

  application:

name: http2Demo

  server:

http-version: http_2_0


El soporte para imágenes nativas de GraalVM se ha movido del estado experimental y ahora tiene soporte de primera clase y ampliado en todo el marco, lo que solidifica aún más el compromiso con GraalVM. Esto incluye la configuración automática de recursos estáticos, controladores JDBC, Hibernate, Flyway, AWS SDK 2 y otras áreas.

Dejo link : https://www.infoq.com/news/2020/08/micronaut-v2/

viernes, 14 de agosto de 2020

Records y Pattern Matching para instanceof en JDK 16


Todavia no me aprendo java 11 y ya tenemos noticias de java 16. Al parecer viene con registros, cosa que particularmente no me gusta y no entiendo la necesidad. Un ejemplo sería : 

record Name(String firstName, String lastName){}

Los registros se pueden declarar en un archivo separado o como parte de otra clase. 

Cuando se define una clase normal, implícitamente se agrega un constructor predeterminado. Los registros tienen un comportamiento similar y contienen implícitamente varios miembros:

  • Campos privados para todos los componentes del registro.
  • Métodos de acceso público para todos los componentes del registro.
  • Constructor con argumentos para todos los componentes del registro. Este constructor se denomina constructor canónico.
  • equals, toString y hashCode con su implementación.

El registro definido anteriormente no contiene ningún código personalizado, pero es posible definir métodos explícitos. Incluso es posible declarar explícitamente los diversos métodos agregados implícitamente y el constructor canónico. Por ejemplo, es posible crear un método toString personalizado.

En JDK 14, se requería que el constructor canónico fuera público. Desde JDK 15 en adelante, el constructor canónico implícito obtiene el mismo modificador de acceso que la clase de registro. Al definir un constructor canónico explícito, el modificador de acceso debe proporcionar al menos tanto acceso como la clase de registro.

Como parte del cambio, también se modificó la anotación @Override. Ahora se puede utilizar para anotar un método de acceso explícito en un registro.

También vamos a tener pattern matching para el instaceof. Ahora debemos hacer : 

if (person instanceof Customer) {

    Customer customer = (Customer) person;

    customer.pay();

}

y con pattern matching vamos poder hacer : 

if (person instanceof Customer customer) {

    customer.pay();

}

y podemos utilizarlo en el equals por ejemplo: 

@Override

public boolean equals(Object o) {

    return o instanceof Customer other &&

            name.equals(other.name);

}

Dejo link: https://www.infoq.com/news/2020/08/java16-records-instanceof/


Aprende con Google!!


Quiero recomendarles este sitio que encontré donde pueden aprender desde programación hasta vida profesional. Esta en castellano y esta muy bueno. 

No tiene cursos avanzados solo básicos pero para empezar esta bien, sin más dejo link: 

https://learndigital.withgoogle.com/activate/courses

opensource.microsoft.com


Como cambian los tiempos quien diría que Microsoft publicaría un sitio para promocionar sus proyectos open source y aquí lo tenemos! 

Sin más dejo link: https://opensource.microsoft.com/

miércoles, 12 de agosto de 2020

Trait Objects para hacer Dynamic Dispatch en Rust


Seguimos con rust y el polimorfismo. 

Como sabemos el Dynamic Dispatch significa que el compilador llama código que es determinado en tiempo de ejecución.

Cuando usamos objetos de trait, Rust debe usar Dynamic Dispatch. El compilador no conoce todos los tipos que podrían usarse con el código que usa objetos de trait, por lo que no sabe qué método implementado en qué tipo llamar. En cambio, en tiempo de ejecución, Rust usa los punteros dentro del objeto de trait para saber a qué método llamar. Hay un costo de tiempo de ejecución cuando ocurre esta búsqueda que no ocurre con el envío estático. El envío dinámico también evita que el compilador elija insertar el código de un método, lo que a su vez evita algunas optimizaciones. Sin embargo, obtuvimos una flexibilidad adicional propia del polimorfismo.

Algunas reglas complejas gobiernan todas las propiedades que hacen que un objeto de trait sea seguro, pero solo dos reglas son relevantes. Un trait es seguro para objetos si todos los métodos definidos en el trait tienen las siguientes propiedades:

  • El tipo de retorno no es Self.
  • No hay parámetros de tipo genérico.

La palabra clave Self es un alias para el tipo en el que estamos implementando los métodos. Los objetos de trait deben ser seguros para objetos porque una vez que has usado un objeto de rasgo, Rust ya no sabe el tipo concreto que está implementando ese rasgo. Si un método de rasgo devuelve el tipo Self concreto, pero un objeto rasgo olvida el tipo exacto que es Self, no hay forma de que el método pueda usar el tipo concreto original. Lo mismo ocurre con los parámetros de tipo genérico que se completan con parámetros de tipo concreto cuando se utiliza el rasgo: los tipos concretos pasan a formar parte del tipo que implementa el rasgo. Cuando el tipo se olvida mediante el uso de un objeto de rasgo, no hay forma de saber con qué tipos completar los parámetros de tipo genérico.

Un ejemplo de un trait cuyos métodos no son seguros para objetos es el trait Clonar de la biblioteca estándar. La firma para el método de clonación en el rasgo Clonar se ve así:

pub trait Clone {

    fn clone(&self) -> Self;

}

El tipo String implementa el rasgo Clone, y cuando llamamos al método clone en una instancia de String, obtenemos una instancia de String. De manera similar, si llamamos a clonar en una instancia de Vec <T>, obtenemos una instancia de Vec <T>. La firma del clon necesita saber qué tipo sustituirá a Self, porque ese es el tipo de retorno.

El compilador le indicará cuando esté intentando hacer algo que viole las reglas de seguridad de los objetos con respecto a los objetos característicos. Por ejemplo, digamos que intentamos implementar la estructura Screen en el Listado 17-4 para contener los tipos que implementan el rasgo Clonar en lugar del rasgo Dibujar, así:

pub struct Screen {

    pub components: Vec<Box<dyn Clone>>,

}

Obtendríamos este error:

$ cargo build Compiling gui v0.1.0 (file:///projects/gui) error[E0038]: the trait `std::clone::Clone` cannot be made into an object --> src/lib.rs:2:5 | 2 | pub components: Vec<Box<dyn Clone>>, | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` cannot be made into an object | = note: the trait cannot require that `Self : Sized` error: aborting due to previous error For more information about this error, try `rustc --explain E0038`. error: could not compile `gui`. To learn more, run the command again with --verbose.

Este error significa que no puede usar este trait de esta manera. Si está interesado en obtener más detalles sobre la seguridad de los objetos, consulte Rust RFC 255.

Dejo link: https://doc.rust-lang.org/book/ch17-02-trait-objects.html


Scala 3, indentación en vez de llaves ???


Una característica experimental, Scala 3 impone algunas reglas sobre sangría y permite que algunas apariciones de llaves {...} sean opcionales. Se puede desactivar con el indicador del compilador -noindent.

  • Primero, algunos programas mal sangrados van a estar marcados con un error de tipo advertencias.
  • En segundo lugar, algunas apariciones de llaves {...} se hacen opcionales. Generalmente, la regla es que agregar un par de llaves opcionales no cambiará el significado de un programa bien sangrado.
Esta característica seguro los hace pensar en python, pero les recuerdo que en haskell tambien la identación es importante. Y scala, tiene más influencia de haskell que de python.

El compilador impone dos reglas para programas bien sangrados, marcando las violaciones como advertencias.

1.En una región delimitada por llaves, no se permite que ninguna instrucción comience a la izquierda de la primera instrucción después de la llave de apertura que comienza una nueva línea.

Esta regla es útil para encontrar llaves de cierre faltantes. Previene errores como:


if (x < 0) {
  println(1)
  println(2)

println("done")  // error: indented too far to the left

2.Si la sangría significativa está desactivada (es decir, en el modo Scala-2 o en -noindent) y estamos al comienzo de una subparte con sangría de una expresión, y la parte con sangría termina en una nueva línea, la siguiente instrucción debe comenzar en una ancho de sangría menor que la subparte. Esto evita errores en los que se olvidó una llave de apertura, como:

if (x < 0)
  println(1)
  println(2)   // error: missing `{

Estas reglas aún dejan un gran margen de maniobra sobre cómo se deben sangrar los programas. Por ejemplo, no imponen ninguna restricción sobre la sangría dentro de las expresiones, ni requieren que todas las declaraciones de un bloque de sangría se alineen exactamente.

Las reglas generalmente son útiles para identificar la causa raíz de los errores relacionados con la falta de llaves de apertura o cierre. Estos errores suelen ser bastante difíciles de diagnosticar, en particular en programas grandes.

Además, el compilador insertará tokens <indent> o <outdent> en ciertos saltos de línea. Gramaticalmente, los pares de tokens <indent> y <outdent> tienen el mismo efecto que los pares de llaves {y}.

Con estas nuevas reglas, las siguientes construcciones son todas válidas:

trait A:
  def f: Int

class C(x: Int) extends A:
  def f = x

object O:
  def f = 3

enum Color:
  case Red, Green, Blue

type T = A:
  def f: Int

given [T](using Ord[T]) as Ord[List[T]]:
  def compare(x: List[T], y: List[T]) = ???

extension (xs: List[Int])
  def second: Int = xs.tail.head

new A:
  def f = 3

package p:
  def a = 1
package q:
  def b = 2

Ojo que agregá los : 

En fin, me parece un gran cambio y va a generar 2 formas de escribir y no sé si es la mejor idea, ya que un junior no va saber cuando escribir de que forma. 

sábado, 8 de agosto de 2020

Rust by Example

Tal vez este link lo conocen todos y yo recien lo veo, pero bueno quien me quita lo compartido. 

En la docu oficial de Rust hay un apartado Rust by example, que esta muy bueno. Dada que la docu es muy extensa este apartado viene bien para aterrizar algunos conceptos programando. 

Sin más, dejo link: https://doc.rust-lang.org/stable/rust-by-example/

Polimorfismo con traits en Rust

Siguiendo con Rust y su implementación a conceptos de orientación a objetos, veamos como implementa polimorfismo sin el concepto de herencia tradicional, sino con traits. 
 
La documentación oficial de Rust explica el polimorfismo en Rust con un ejemplo. Crea una herramienta de interfaz gráfica de usuario (GUI) de ejemplo que recorre una lista de elementos, llamando a un método de dibujo. Este metodo puede dibujar diferentes tipos como Button o TextField.

No implementaremos una biblioteca GUI completa para este ejemplo, pero mostraremos cómo encajarían las piezas. En el momento de escribir la biblioteca, no podemos conocer ni definir todos los tipos que otros programadores podrían querer crear. Pero sabemos que la interfaz gráfica de usuario necesita realizar un seguimiento de muchos valores de diferentes tipos, y necesita llamar a un método de dibujo en cada uno de estos valores con tipos diferentes. No necesita saber exactamente qué sucederá cuando llamemos al método de dibujo, solo que el valor tendrá ese método disponible para que lo llamemos.

Para hacer esto en un lenguaje con herencia, podríamos definir una clase llamada Componente que tenga un método llamado dibujar. Las otras clases, como Button, Image y SelectBox, heredarían de Component y, por lo tanto, heredarían el método de dibujo. Cada uno podría redefinir el método de dibujo para definir su comportamiento personalizado, y la ventana podría tratar todos los tipos como si fueran instancias de componentes y llamar a dibujar sobre ellos. Pero debido a que Rust no tiene herencia, necesitamos otra forma de estructurar la biblioteca de interfaz gráfica.

Para implementar el comportamiento que queremos que tenga la interfaz gráfica de usuario, definiremos un traits llamado Dibujar que tendrá un método llamado dibujar:

pub trait Draw {
    fn draw(&self);
}

Ahora definimos la ventana que tiene que ser capaz de dibujar diferentes tipos de componentes. Para eso la ventana va tener un vector de componentes. Y definimos un componente como una caja o Box que contiene un tipo dinámico que implementa el trait Draw : 

pub struct Screen {
    pub components: Vec<Box<dyn Draw>>,
}

Recordemos que en Rust la definición de un "objeto" esta dividida en sus datos y sus métodos. Ahora definamos los métodos: 

impl Screen {
    pub fn run(&self) {
        for component in self.components.iter() {
            component.draw();
        }
    }
}

Alguien atento, podria decir porque no utilizamos genericos con ventana de este modo : 

pub struct Screen<T: Draw> {
    pub components: Vec<T>,
}

impl<T> Screen<T>
where
    T: Draw,
{
    pub fn run(&self) {
        for component in self.components.iter() {
            component.draw();
        }
    }
}

Pero el problema aquí es que no se va a poder utilizar Screen con diferentes componentes. Si tipamos a Screen con Button por ejemplo, solo va poder tener Buttons y no es lo que queremos. Hago esta aclaración porque con este contraejemplo se ve la función de la caja o Box, que es permitirnos diferentes componentes que implementan Draw. 

Ahora agregaremos algunos tipos que implementan Draw:

pub struct Button {
    pub width: u32,
    pub height: u32,
    pub label: String,
}

impl Draw for Button {
    fn draw(&self) {
        // code to actually draw a button
    }
}

//------------------------------
struct SelectBox {
    width: u32,
    height: u32,
    options: Vec<String>,
}

impl Draw for SelectBox {
    fn draw(&self) {
        // code to actually draw a select box
    }
}

Y por último ver la magia en acción: 

use gui::{Button, Screen};

fn main() {
    let screen = Screen {
        components: vec![
            Box::new(SelectBox {
                width: 75,
                height: 10,
                options: vec![
                    String::from("Yes"),
                    String::from("Maybe"),
                    String::from("No"),
                ],
            }),
            Box::new(Button {
                width: 50,
                height: 10,
                label: String::from("OK"),
            }),
        ],
    };

    screen.run();
}

Como vemos llamamos a run de screen que llamará a draw. 

Al especificar Box <dyn Draw> como el tipo de valores en el vector de componentes, hemos definido que Screen pueda aceptar diferentes tipos en dibujar pero todos deben implementar Draw sino tirra error en tiempo de compilación: 

use gui::Screen;

fn main() {
    let screen = Screen {
        components: vec![Box::new(String::from("Hi"))],
    };

    screen.run();
}

Esto no compila porque String no es un Draw : 

$ cargo run
   Compiling gui v0.1.0 (file:///projects/gui)
error[E0277]: the trait bound `std::string::String: gui::Draw` is not satisfied
 --> src/main.rs:5:26
  |
5 |         components: vec![Box::new(String::from("Hi"))],
  |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `gui::Draw` is not implemented for `std::string::String`
  |
  = note: required for the cast to the object type `dyn gui::Draw`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `gui`.

To learn more, run the command again with --verbose.


Dejo link: 
https://doc.rust-lang.org/book/ch17-02-trait-objects.html

Programación funcional, pros y contras

Lei un articulo y me gusto mucho, por lo tanto les dejo un resumen, al final esta el articulo original :

Como saben, los programadores son personas creativas, pero al mismo tiempo se adhieren celosamente a ciertas ideas, por ejemplo, la elección de un lenguaje de programación. PHP se considera un "lenguaje vago" y JavaScript es magia "difícil de predecir". Y en medio de la gran abundancia de lenguajes, los lenguajes funcionales están ganando cada vez más seguidores y cada vez más se están abriendo camino en la mayoría de las empresas de todo el mundo. Según la analítica RedMonk. Desde junio de 2017 y la evaluación combinada de la popularidad de los lenguajes en GitHub y Slack Overflow, los lenguajes funcionales (Elm, Elixir) están creciendo lenta pero seguramente. El gran aumento en la popularidad de JavaScript también está impulsando un mayor interés en FP. Además, los desarrolladores con experiencia en programación funcional posteriormente comenzaron a trabajar en frameworks y como resultado, tenemos Redux, React, MobX y otras librerías que usan millones de personas.

Entonces, ¿qué es la programación funcional, por qué hay tanto auge y por qué vale la pena considerar aprenderla? Vamos a resolverlo.

El mundo de JavaScript está hirviendo. Hace unos años, solo unos pocos desarrolladores entendían la programación funcional, pero en los últimos tres años, casi todas las bases de código de grandes aplicaciones han estado utilizando activamente ideas tomadas del mundo de la programación funcional. Y por una buena razón: la programación funcional le permite escribir código más conciso y predecible, y es más fácil de probar (aunque aprender desde cero no es fácil).

Las principales características distintivas del desarrollo de software con FP:
  • funciones puras;
  • evitar el estado compartido, datos mutables y efectos secundarios;
  • La prevalencia de un enfoque declarativo más que imperativo.
La programación funcional se basa inherentemente en los principios fundamentales y definitorios enumerados anteriormente. Y para comenzar a comprenderlos, primero debe cambiar al modo "académico" y cómo debe estudiar las definiciones de términos que lo seguirán implacablemente en FP: funciones puras, composición de funciones, evitar el estado compartido, etc. Esto es más como volver a la escuela. a una lección de matemáticas, pero después de eso verás tanto la funcionalidad como la programación de una manera completamente diferente.

Profundicemos un poco más en los términos de FP y, al menos superficialmente, comprendamos lo que significan.

Las funciones puras  son funciones deterministas sin efectos secundarios. Una función determinista significa que para el mismo conjunto de valores de entrada, devuelve el mismo resultado. Para FP, las propiedades de tales funciones son muy importantes: por ejemplo, las funciones puras tienen transparencia referencial: puede reemplazar una llamada de función con su valor final sin cambiar el valor del programa.

La composición de funciones se refiere al proceso de combinar dos o más funciones para crear una nueva función o realizar cálculos.

El principal problema con los estados compartidos es que para comprender los efectos de una función, debe conocer el historial completo de cada variable compartida que utiliza la función. Por lo tanto, la programación funcional evita estados compartidos, confiando en cambio en estructuras de datos inmutables y computación sin procesar para extraer nuevos datos de los existentes. Otro matiz que surge cuando se trabaja con estados compartidos es que cambiar el orden de las llamadas a funciones puede provocar una avalancha de errores. En consecuencia, al evitar estados compartidos, también evita este problema.

Subyacente a toda la programación funcional está la inmutabilidad (inmutabilidad). Y aquí es importante no confundirse const con la inmutabilidad. const crea un enlace de nombre variable que no se puede reasignar después de la creación, pero no crea objetos inmutables. No podrá cambiar el objeto al que pertenece el enlace, pero aún puede cambiar las propiedades de este objeto const, por lo tanto , los enlaces creados no son inmutables. Los objetos inmutables no se pueden cambiar en absoluto. Esto se logra mediante la congelación profunda de las variables.

Los efectos secundarios significan que, además de devolver un valor, la función también interactúa con el estado mutable externo. ¿Por qué FP los evita? Porque de esta manera los efectos del programa son mucho más fáciles de entender y probar. Haskell, por ejemplo, usa mónadas para aislar los efectos secundarios de las funciones puras.

El punto es que el enfoque imperativo funciona según el principio de control de flujo y responde a la pregunta "cómo hacerlo". El enfoque declarativo describe el flujo de datos y responde a la pregunta "qué hacer". Además, el código imperativo a menudo se basa en instrucciones (operadores), mientras que el código declarativo se basa más en las expresiones.

Entonces, descubrimos qué es la programación funcional y qué necesita saber al respecto. Y, antes de pasar a discutir sus ventajas, propongo pasar primero por las desventajas, más precisamente, para comprender la esencia del estereotipo "la programación funcional no es natural".

A juzgar por lo que escribí anteriormente, los seguidores de la programación funcional ya deberían haber surgido entre los lectores. Sin embargo, a pesar de la gran cantidad de artículos laudatorios, no hay menos artículos titulados "La programación funcional es extraña y no tiene futuro" (por ejemplo). ¿Esto significa que estoy equivocado? No. ¿Hay alguna razón para pensar que la FA es extraña? Por supuesto.

Permíteme darte una cita de Internet que refleja completamente la actitud de muchos desarrolladores hacia FP:

"Escribir código funcional es como escribir al revés y la mayoría de las veces es como resolver un rompecabezas en lugar de explicar el proceso a una computadora".
De hecho, esta es una actitud bastante subjetiva hacia la FP para aquellos que no quieren dedicar suficiente tiempo para comprender los matices de la programación funcional y simplemente intentarlo. Pero, como prometí, veamos las desventajas de FP y luego veamos las ventajas.

Primero, no existe un vocabulario eficiente desordenado y configurado para lenguajes funcionales. Los diccionarios puramente funcionales son más lentos que las tablas hash, y esto puede ser crítico para algunas aplicaciones. En segundo lugar, no hay tablas hash débiles puramente funcionales, aunque para la mayoría de los desarrolladores esta falla puede pasar desapercibida.

Además, FP no es adecuado para algoritmos en gráficos (debido a su funcionamiento lento) y, en general, para aquellas soluciones que se han basado en programación imperativa durante décadas.

De acuerdo, el último punto suena más como una queja: no podemos culpar a FP por lo que no estaba destinado. Por lo tanto, propongo recurrir a lo agradable, es decir, a las ventajas de FP y su uso en proyectos reales por parte de compañías internacionales reales.

Uno de los beneficios más obvios de la programación funcional son las abstracciones de alto nivel que ocultan muchos de los detalles de las operaciones de rutina, como la iteración. Debido a esto, el código es más corto y, como resultado, garantiza menos errores que se pueden cometer.

Además, el FP contiene menos primitivas de lenguaje. Las clases bien conocidas en FP simplemente no se usan: en lugar de crear una descripción única de un objeto con operaciones en forma de métodos, la programación funcional utiliza varias primitivas básicas del lenguaje que están bien optimizadas internamente.

Además, la programación funcional permite al desarrollador acercar el lenguaje al problema, en lugar de viceversa, todo a expensas de las estructuras flexibles y la flexibilidad del lenguaje. Además, FP ofrece a los desarrolladores nuevas herramientas para resolver problemas complejos que los programadores de POO a menudo descuidan.

De hecho, es demasiado largo para enumerar todas las ventajas de la programación funcional; realmente hay muchas de ellas. Puedo decir esto: trabajar con lenguajes funcionales proporciona una escritura de código precisa y rápida, facilita las pruebas y la depuración, los programas son de nivel superior y las firmas de funciones son más informativas.

Por supuesto, uno no puede negar las ventajas de POO, pero vale la pena recordar que los lenguajes funcionales están a la par con muchos otros en términos de conveniencia y merecen su atención.

En el mundo de TI, nada sucede. Una cosa se aferra a la otra, y ahora todas las tendencias más actuales están interconectadas.

Si recordamos las tendencias más sensacionales de 2016-2017, estas, por supuesto, serán AI, IoT, Big Data y Blockchain. Están en boca de todos, todos conocen su potencial y sus características clave. Y son algunas de estas tendencias las que han catalizado la creciente popularidad de la programación funcional entre los desarrolladores.

Actualmente, el problema del procesamiento paralelo y el trabajo con grandes flujos de datos es muy grave, en otras palabras, trabajar con Big Data. Y, paralelizando el procesamiento de estos datos, puede obtener el resultado deseado en una fracción de segundo, lo cual es muy crítico en el mundo real. Además, no se olvide de la informática descentralizada (distribuida): blockchains y otras, que, en esencia, son un mecanismo bastante complejo. Y para tales cálculos, el código funcional es más adecuado debido a todos los principios de la programación funcional (como las funciones puras, por ejemplo). El uso de todas las técnicas básicas de FP facilita la ejecución y el mantenimiento de código paralelo.

Además, si la programación funcional anterior se usaba solo para resolver problemas específicos, ahora incluso se aplica a proyectos clásicos. 

Como probablemente ya haya entendido, no debe temer la programación funcional. Un poco de diligencia y curiosidad, y ahora has dominado la FP. Aquí hay algunos consejos para aquellos que han decidido probarse en un nuevo género y aprender algo radicalmente nuevo:
  • Relájate :) Al principio será muy complicado, teniendo en cuenta que tendrás que dejar atrás lo que sabes y aprender nuevos enfoques y principios. Y eso esta bien. Piense en la primera vez que aprendió a codificar. Nada malo sucederá.
  • Comience con micro tareas para tenerlo en sus manos.
  • Comience a aprender Haskell y luego pase a Scala (o F #) para comenzar a comprender los principios de programación funcional (y al mismo tiempo comenzar a pensar más "funcional").
Dada la prevalencia de la programación funcional, puede estar seguro de su futuro profesional (con la debida diligencia), ya que seguramente puede usar sus habilidades recién adquiridas. ¡No tengas miedo de intentarlo!