Programación

¿Por qué (casi) nadie sabe sobre encodings? ¿Por qué (casi) nadie ha leído What Every Programmer Absolutely, Positively Needs To Know About Encodings And Character Sets To Work With Text?

Este tipo de programación se puso de moda en los noventa:

Y yo decía: ¿dónde están mis bucles? ¿Y mis bifurcaciones?

Este tipo de programación está de moda últimamente:

hourly_delay <- flights %>%
  filter(!is.na(dep_delay)) %>%
  group_by(date, hour) %>%
  summarise(
    delay = mean(dep_delay),
    n = n() ) %>%
  filter(n > 10)

Y todo bien, sí, pero sigo sin tener bucles o bifurcaciones.

Tal vez no hagan falta. Al menos, para cosas de andar por casa. Pero, lo confieso, el código de verdad que escribo está lleno de casos especiales, comprobaciones de todo tipo de contingencias, reglas que aplican a unas columnas sí y otras no, objetos complejos (p.e., listas), que se van rellenando de una u otra manera dependiendo de las opciones del usuario y otras enojosas coyunturas muy reñidas con la elegancia.

Tengo delante Los cerebros ‘hackeados’ votan de Harari, autor de cierta y reciente fama. Elabora sobre un argumento simple y manido: el cerebro funciona como un ordenador y los seres humanos somos no solo perfectamente predecibles sino también perfectamente manipulables. De lo que se derivan muchas funestas consecuencias en lo político y en lo social.

El artículo me ha sido recomendado por dos personas cuyo criterio tengo en muy alta estima. Pero otra lo ha criticado con saña aquí.

De vez en cuando pruebo paquetes promisorios. No es infrecuente que cosas que he intentado hace años, algún ejemplo más o menos sencillo que he publicado aquí, acabe convirtiéndose en la piedra angular de algo facturable. Incluso de algo facturable por mí.

geozoning podía haber sido uno de esos. La promesa del paquete es que puede ayudarte a segmentar regiones del espacio de acuerdo con alguna variable, una especie de clústering para información de tipo espacial.

El otro tropezamos con el siguiente artefacto:

a <- list(aa = 12, bb = 14)
is.null(a$a)
#[1] FALSE
a$a
#[1] 12

No es un bug de R, por que la documentación reza:

x$name is equivalent to x[[“name”, exact = FALSE]]

Y se pueden constrastar:

a[["a", exact = FALSE]]
a[["a", exact = TRUE]]

Comentarios:

• Odio muchísimo los bugs que no son bugs porque están documentados en el la nota ‡2.a.(c), párrafo §23.3 de la sección 14 de un manual oscuro.
• Odio mucho al os gilipollas que se complacen en mandarte a leer manuales.
• Odio mucho las violaciones del principio de mínima sorpresa.
• Soy consciente de que R es, fundamentalmente, una plataforma de análisis interactivo y no (o solo subsidiariamente) un lenguaje de programación.
• Soy consciente de que muchos de los defaults de R se decidieron antes de que se popularizasen los completadores de comandos.

Una función no debería cambiar nada de cuanto la rodea. Debería devolver algo y ya. Se acepta barco como animal acuático cuando hay funciones que escriben en logs, guardan datos en disco o crean gráficos.

R deja que los usuarios se disparen en el pie permitiendo hacer cosas tan peligrosas como:

a <- new.env()

a$1     # error

foo <- function(){
  a$a <- 1
}

foo()
a$a
# [1] 1

De la misma manera, si le enseñas un cuchillo a una vieja, es posible que te dé su bolso con todo lo que contiene. Pero eso no significa que debas usar los cuchillos para tales fines.

Echadle un vistazo a Syberia (y me contáis qué tal os va). Tiene muy buena pinta y puede ser útil para produccionalizar código.

[Esto es casi todo; lo que sigue es omitible.]

Sin embargo y sin que necesariamente haga desmerecer a Syberia como tal, en la página arriba enlazada se lee:

In the viewpoint of the author, R is syntactic sugar around LISP, which enables arbitrary computation; Syberia is an attempt to support this conjecture by allowing the construction of arbitrary software projects within the R programming language, thereby finally outgrowing its long-overdue misconception as a statistical tool.

Tuve ocasión el pasado jueves, en Barcelona y gracias a la invitación de KSchool, de lo que llamo el stack analítico. Es decir, de aquellas herramientas tecnológicas necesarias para poder hacer ciencia de datos hoy en día.

Las diapositivas de la charla están aquí.

El tema es viejo pero no por ello menos urgente: existen herramientas (y, desgraciadamente, me he visto a incluir el saber leer documentación técnica en inglés) cuyo conocimiento es imperativo para poder trabajar de manera efectiva en ciencia de datos. Incluidos están sistemas operativos (dencentes), editores de texto (decentes) e IDEs y, como poco, un lenguaje de programación.

En serio, es así. ¿También if? Pues también. De hecho,

`if`(1 == 3, print("a"), print("b"))

Y eso permite, por ejemplo, que funcionen expresiones tales como

a <- if (1 == 3) 4 else 5

tan útiles como poco empleadas en general. También son funciones (, { y otras que aparecen en la sección .Internal vs .Primitive del documento R Internals.

Nunca me he visto en la tesitura de tener que usar callbacks porque no son mi guerra. Pero por lo que he oído de la gente que sabe mucho más que yo, son uno de esos infiernos de los que hay que huir con el mismo pavor que de los fors, los ifs, los elses (¡argggg! ¡he escrito else!) y los whiles.

Una pequeña maravilla teórica que me ha hecho replantearme la absoluta inutilidad de aquello que estudié en Álgebra III (funtores y demás) son las mónadas.

Estuve el otro día en una charla de José Luis Cañadas en el grupo de usuarios de R de Madrid sobre sparklyr. Hoy en otra de Juan Luis Rivero sobre, esencialmente, lo mismo, pero esta vez con Python. Y podría escribir “etc.”.

Me centraré en la de José Luis, aunque podría decir lo mismo de cualquiera de las otras. No había trabajado con sparklyr. No soy siquiera fan de dplyr (aunque no es que no se lo recomiende a otros; es simplemente, como tantas cosas, que soluciona problemas que no tengo). Pero la seguí sin mayores problemas. Lo que tenía de nuevo era una fina, somera capa de sintaxis que enlazaba fundamentos con fundamentos.

Es:

• Nivel 1: Realizan la mayor parte de su trabajo con herramientas ofimáticas (fundamentalmente Excel), aunque pueden utilizar puntualmente Eviews, Stata, R o Matlab.
• Nivel 2: Los que realizan la mayor parte de su trabajo con R, Python, SAS o SQL pero cuyo sistema de control de versiones es el de ficheros con determinadas convenciones de nombres.
• Nivel 3: Como el anterior, pero usando control de versiones, estilos de código, y revisión por pares (peer review).
• Nivel 4: Como el anterior, pero incorporando métodos propios de la ingeniería de software como el unit testing, documentación integrada, release cycles, etc.

Lo anterior está traducido de Why you need version control, que habla de eso y más. Léelo.

Si creo la función

foo <- function(a,b) a*a + b

y la llamo mediante

foo(1 + 1,3)

pueden ocurrir dos cosas: o bien que R precalcule 1+1 y la función ejecute 2 * 2 + 3 o bien que la función ejecute directamente (1+1)*(1+1)+3. Pero, ¿qué es lo que hace realmente? Si escribimos

f1 <- function(x){
    print("Soy f1")
    x
}

f2 <- function(x){
    print("Soy f2")
    x
}

foo(f1(2), f2(3))

obtenemos

> foo(f1(2), f2(3))
[1] "Soy f1"
[1] "Soy f2"
[1] 7

lo que significa que f1 ha sido llamada una única vez. Es decir, R resuelve sus argumentos antes de aplicar la función. Pero hay más: