Historia

¿Cuál fue el primer computador eléctrico?

¿Cómo se llama
esta arquitectura?

¿Cómo se veía el
código de los
primeros computadores?

¿Cómo se veía el
código en ensamblador?

foo:
movl $OxFF001122, %eax
addl %ecx, %edx
xorl %esi, %esi
push1 %ebx
movl 4{%esp}, %ebx
leal (%eax, %ecx, 2), %esi
cmpl %eax, %ebx
jnae foo
retl

¿Cuáles fueron los primeros lenguajes de alto nivel?

• FORTRAN - 1957 (John Backus)
• ALGOL - 1958
• Copias Isomórficas
  de la arquitectura
  Von Neumann

¿Por qué debían
ser copias isomórficas?

¿Cuál fue el primer lenguaje de programación funcional?

LISP - Un lenguaje que un matemático pudiera amar

¿Cómo se llama el primer lenguaje que usó objetos?

Simula - Permite una abstracción sobre
el hardware.
Bajo desempeño.
Interés académico.

¿Qué lenguaje popularizó
la programación?

C - Creado para diseñar sistemas operativos
"Close to the hardware"

¿Cuál fue el primer lenguaje orientado por objetos?

Modelo de Actores - Modelo matemático
para la computación concurrente
- 1973 (Carl Hewitt)

Influído por Smalltalk

"Can Programming Be Liberated from the von Neumann Style?"

John Backus - 1977

Llamado a no usar copias isomórficas del hardware. Alrededor de ese paper se acuñó el término FP

Dado que no era
"Close to the Hardware"
la industria desestimó
la FP como de puro
interés académico

Características de la
FP que la hacían de
"bajo" desempeño

• Garbage Collector
• Dynamic Typing
• Recursion
• etc

Hoy día todas son características estándar
de lenguajes exitosos

¿Qué lenguaje
popularizó la OOP?

Década de los 90
Backus tenía razón
 Dificultad para Programación de GUI's

C++

• Se volvió un estándar
  de facto por GUI's
• Abstracción sobre el hardware
• "Close to the hardware"
  porque se implementó sobre C

¿Cuál fue el primer lenguaje FP exitoso de la industria?

Erlang - Creado para diseñar el SO para Ericsson. Basado en el
modelo de Actores

¿Cuál es el lenguaje
FP por excelencia?

¿Cuál es el primer lenguaje en abiertamente mezclar
la FP y la OOP?

El catalizador de la FP
fue la programación
en múltiples núcleos

Hoy en día, todos los lenguajes de programación populares, tienen características de FP

La historia nos muestra que usualmente no hay ideas "superiores" a otras. Unas se complementan a otras.

Sacar lo mejor de
las ideas disponibles

Lenguajes de Programación

¿Cuántos?

Expertos coinciden en ~5

¿Cuáles?

• Diferentes Paradigmas
• Diferentes Sintáxis
• Diferentes Audiencias

¿Cuál es el primero?

El que use en su trabajo

Lenguaje Actual

• Pasado
• Presente
• Futuro

LISP

• FP
• Sintaxis extraña
• Activo

C

• Imperativo
• El padre de los lenguajes

C++

• OOP
• Sin Garbage Collector
• Pionero en muchas ideas

Java

• Lenguaje OOP más usado
• Comunidad muy grande
• JVM

C#

• OOP
• Microsoft
• LINQ

JS

• Lenguaje FP más usado
• Comunidad muy grande

Koitlin

• Lenguaje JVM
• OOP + FP
• Android

Go

• Sistemas embedidos
• Imperativo
• Google
• Simplista

Clojure

• Dialecto LISP
• Lenguaje JVM, JS y CLR

Python

• OOP + FP
• Data Science
• Muy usado por Google

Swift

• OOP + FP
• iOS

Groovy

• OOP + FP
• Lenguaje JVM
• Muy cercano a Groovy

Otros

• Scala
• Ruby
• PHP
• etc

¡Aprenda un lenguaje nuevo cada año!

OOP

OOP

• Clases, Objetos, Tipos de Datos
• Encapsulamiento
• Herencia: Interfaces y Clases Abstractas
• Polimorfismo

Frameworks

¡NINGUNO!

Si usted conoce los principios de programación, un FW se aprende rápidamente

Principios de Programación

Principios SOLID

• SRP
• OCP
• LSP
• ICP
• DIP

Single Responsibility

• Una clase debe tener una
  sola razón para cambiar
• Alta Cohesión
• No abusar de static

Open Close

• Una clase debe estar abierta a la
  extensión pero cerrada a la modificación
• Agregar funcionalidad sin
  romper código ya existente
• Patrones de Diseño

Liskov Substitution

• Un método que recibe un parámetro
  de tipo T debería funcionar correctamente
  con cualquier subtipo de T
• No abusar de la herencia
• Preferir substitución
  (delegación) sobre herencia

Interface Segregation

• Una clase que implementa una
  interface no debería estar forzada
  a usar métodos que no necesita
• Las interfaces deberían ser pequeñas
• Cada interface representa una "vista"
  sobre una característica de un objeto

Dependency Inversion

• Los módulos de alto nivel no deberían
  depender de módulos de bajo nivel
• Use interfaces en: valores de retorno,
  parámetros y atributos

Dependency Injection

• Una clase no debería instanciar un "colaborador"
• Esas dependencias deberían ser inyectadas
• Diferencias en: Constructor, setter y atributo
• NO depende de un FW

Don't Repeat Yourself - DRY

• Evitar la repetición del código
• Evita sistemas inconsistentes

You Aren't Gonna Need It - YAGNI

• Implementar solo lo
  que se nos impide
• Optimizar recursos

Patrones de Diseño

Los Patrones de Diseño
NO están obsoletos.
La FP NO los reemplaza

Template

• Representa un algoritmo
  expresado con métodos abstractos
• Implementa un proceso con
  pasos que pueden ser especializados
• Muy útil en el mundo web
  y diferentes usuarios

Factory Method

• Un método que
  construye un objeto
• Esconde la implementación
  de una interface
• Versión lite

Command

• Encapsula una acción
  para ser ejecutada después
• Las expresiones lambda
  muestran su poder,
  pero no lo reemplazan
• Útil para operaciones
  de "deshacer"

Strategy

• Modifica el comportamiento
  de un método en tiempo de ejecución
• Útil para implementar algoritmos resilentes

State

• Modela clases que cambian
  su comportamiento según su "estado"
• Modelan naturalmente "máquinas de estado"

Builder

• Separar el código de construir
  un objeto de sus métodos
• Permite construir un
  objeto de muchas maneras
• Evita listas de parámetros confusas

Decorator

• Agrega funcionalidad a
  un método existente sin modificarlo
• Varios ejemplos en API's muy usados

Observer

• Establece una relación
  1 a muchos entre clases
• Desacopla la clase donde ocurre
  un "evento" y la clase que
  reacciona a este evento
• Base de Programación Reactiva

Visitor

• Separa un algoritmo de las clases sobre las que opera
• Muy parecido a Pattern Matching

Singleton

• Permite asegurar que solo se crea
  una instancia de una clase
• Fácil de abusar...
• ... pero útil en otros casos
• Sepa cuándo usarlo

Pruebas Unitarias

La utilidad de las pruebas unitarias no debería ser discutida ¿por qué no hacemos más de ellas?

Excusas para no usar pruebas unitarias

• No me lo permiten
• Toma el doble del
  tiempo escribirlas
• Es muy difícil

No deberíamos pedir "permiso", ¡es nuestra responsabilidad escribir código que funcione!

Y no, no toma el doble
de tiempo escribir código con pruebas unitarias,
si no las has escrito entonces llevas la mitad
de lo que deberías hacer

¡Las pruebas unitarias
son en primera instancia para la tranquilidad
del programador!

¡Escribir pruebas
unitarias es una habilidad que se debe practicar!

¡Pedir ayuda está bien!

¿Cómo debe verse la prueba unitaria perfecta?

Prueba Unitaria

• Simple
• Expresiva
• Ofrecer un buen
  mensaje si falla

Las pruebas unitarias son igual de importantes, o más, que el código que se ejecuta en producción

¡Las pruebas unitarias también son documentación!

TDD

Es un proceso de codificación en que escribimos pruebas unitarias que son ayuden
a "descubrir" el diseño
de nuestra solución

3 pasos para TDD

• Red - Se escribe una prueba unitaria que falle 

• Green - Se escribe apenas lo necesario

  para que la prueba unitaria pase

• Blue - Se refactoriza el código

  para hacerlo limpio
  
  Las pruebas se escriben de
  menor a mayor complejidad

Ventajas

• El código suele ser más simple
• El diseño del código es mejor
  porque se puede probar
• Las pruebas ofrecen amplias cobertura
  y son excelentes como documentación

¿Todo debería ser TDD?

TDD es una herramienta, úsela a su discreción

Effective Programming

Kill Null

• Nunca use Null para indicar la ausencia de un valor, use otras opciones como Optional
• Nunca inicialice una variable con Null, sólo inicialícela cuando sepa el valor que deba tener. Siempre hay una opción (usualmente involucra crear un método)
• Si es definitivamente imposible, trate de encapsular null detrás de una clase / librería

¿Cuándo está
bien usar null?

• En OOP como un detalle de implementación,
  pero este no puede salir del objeto,
  p.j. retornarlo en un método

Inmutabilidad

• Un objeto cuyo estado no puede
  modificarse una vez creado, es inmutable
• Un objeto inmutable se puede compartir tranquilamente entre métodos / hilos
• Así como los miembros deberían
• "Mutability in the inside": la mutabilidad no
  es mala per se, pero lo es cuando la compartimos

La suma del costo de
bugs producidos por null
y por compartir objetos mutables debe ser del orden del billón de dólares

Todos los lenguajes populares, tienen
partes peligrosas

Ser un buen programador implica conocer este sub conjunto del lenguaje que permite escribir código seguro y expresivo

Effective <lenguaje/>

• Effective Java
• JavaScript: The Good Parts
• C# in Depth
• etc.

Clean Code

Conjunto de buenas prácticas; la más importante: los métodos deben tener un solo
nivel de abstracción

Hábitos

Hábitos

• Usar Twitter
• Suscribirse a blogs
• Leer un libro cada mes
• Ver conferencias
• Hacer cursos en MOOC's

"No hay ningún problema que sea de alguien más"

"La regla del Boy Scout: has push de código que esté más limpio que como estaba cuando hiciste pull"

Contexto

Hoy en día hay, probablemente, cien millones de
programadores
en el mundo

Y las vacantes de trabajo sobrepasan los programadores disponibles

Y las vacantes de trabajo sobrepasan los programadores disponibles

Por eso, la cantidad de programadores se duplica cada 5 años(*)

La industria está perpetuamente en
estado de "inmadurez" (personas con menos
de 5 años de experiencia)

¿Cuántas personas
han muerto por culpa
de software?

¡Cuando el CEO de Volkswagen testificó por el escándolo de las emisiones, culpó a los desarrolladores!

No está bien que un programador diga "... es que mi jefe me dijo que tenía que hacerlo rápido"

Tenemos que aprender
a decir "NO", que no es
lo mismo que implicar
que siempre esta
bien decir "NO"

El Juramento del Programador

1. No escribiré código maligno
2. El código que escriba siempre
   será el producto de mi mejor esfuerzo
3. Haré pequeños incrementos frecuentes,
   no impediré el progreso de los demás
4. De manera implacable mejoraré el código
   a cada oportunidad, nunca haré el código peor
5. Constantemente me aseguraré de alguien
   pueda reemplazarme y que yo pueda
   reemplazar a alguien más
6. Haré estimados que son honestos en magnitud
   y precisión. No haré promesas sin certeza.
7. Nunca dejaré de aprender
   y mejorando mis habilidades