Por qué estudiar distintos lenguajes de programación?
Los lenguajes de programación están en todos lados!
Usos clásicos
- táreas de sistema y bajo nivel
- C, C++, Assembler, Rust, Go …
- alto nivel/generalistas
- Java, C#, OCaml, Haskell, Lisp, Python, Ruby …
- Desarrollo Web y aplicaciones móviles
- Javascript, Swift, Dart, Objective-C …
- Script
- Bash, Perl, Awk, Sed …
No tan estándar
- queries de bases de datos
- red y sistemas distribuidos
- formateo de documentos
- sistemas de compilación y configuración
- demostración de teoremas
- gráficos, GPUs, hardware y FPGAs
- cálculo numérico y científico
- análisis sintáctico y lexical (parsing y lexing)
- blockchain y smart contracts
Cómo les decimos a las computadoras qué hacer
- desde el pensamiento humano hasta las instrucciones precisas
- los compiladores nos ayudan a programar
- encuentran errores, optimizan …
Los lenguajes de programación influencian nuestra forma de penasr
- programadores piensan en términos de abstracciones de lenguajes
- clases, objetos, funciones, tipos…
- permiten que las mentes humanas manejen sistemas complejos
Para qué sirven los lenguajes de programación
Escribir programas
- scripts descartables
- para automatizar alguna tarea aburrida
- aplicaciones útiles
- aplicación de toma de notas, servidor web…
- productos empresariales serios ($$$)
- Google, Facebook, Amazon, Apple…
- Infraestructura crítica
- Hospitales, plantas eléctricas, red eléctrica…
Reutilizar código existente
- compartir código dentro de un mismo equipo
- utilizar librerías estándar
- comunidad del software libre, Github…
Evitar errores
- en el momento de compilar
- descartar programas sin sentido
- atajar errores comunes automáticamente
- chequear vulnerabilidades
- o gracias a un mejor diseño de lenguaje
- hacer que algunos errores sean imposibles
- asegurarse que el programador se ocupa de todos los casos
“Billion-dollar mistake”
I call it my billion-dollar mistake […] This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage.
- Tony Hoare, sobre el invento de los punteros nulos
Organizar el software
- Software: la cosa más compleja diseñada por el humano, lejos
- No limitado por las leyes de la física
- Si hacés un edificio de 1000 pisos, va a colapsar
- Limitado por la complejidad
- Si producís demasiado código, nunca habrá suficiente programadores para arreglar los errores
- Lenguajes: la primera línea de defensa para manejar la complejidad
Hay mucho código
Una teoría de los lenguajes de programación?
Es solo un montón de lenguajes?
- Muchos lenguajes parecen ser “lo mismo”
- Todos los lenguajes reales tienen muchas peculiaridades
- Accidentes históricos
- Restricciones específicas
- Las características esenciales de los lenguajes, a veces, es difícil de ver
¿”Paradigmas” de programación?
- Es una manera popular de categorizar los lenguajes:
- Orientado objeto (OO)
- Funcionales
- Imperativos
- Declarativos
- Difícil de especificar qué significa cada paradigma
- La mayoría de los lenguajes tiene un poco de todo
- No es más bien un estilo de programación, que un lenguaje?
Sí: características comunes de lenguajes de programación
- Muchos lenguajes llegaron a las mismas ideas
- Ej: variables, funciones, bucles…
- Analizar la esencia de cada particularidad
- Entender cómo esas particularidades interactúan
Sí: formalizar lenguajes
- Estudiar modelos “de juguete” de lenguajes de programación
- muy simplificados (imprácticos)
- enfocados en solo unas funcionalidades básicas
- Definiciones formales usando matemática
- La manera más clara de pensar los lenguajes de programación
- Permite demostrar propiedades
- Provee fundaciones sólidas
Qué hace que un lenguaje sea popular?
“Facilidad de uso/ergonomía”
- Depende de cosas como…
- lo que ya conoce el programador
- el modelo mental del programador acerca de los lenguajes
- qué tan “legible” los programas son
- detalles específicos (llaves, parentesis …)
- díficil de analizar científicamente
Herramientas de soporte
- Herramientas de desarrollo
- IDE, debugger, linter, formateador de código, diseño de interfaces
- Librerías estándar y documentación
- Matemáticas, estructuras de datos, red, bases de datos, gráficos…
- “Cadena de desarrollo”: compilador, gestor de paquetes, runtime
- Requiere mucho esfuerzo de desarrollo ($$$)
Factores sociales
- Nicho específico
- apps de iOS, computación científica
- Comunidad
- Stack Overflow, Reddit, paquetes en Github
- Influencia de la industria
- “Lenguaje para los GPUs de NVIDIA”
- Reputación y estereotipos
- “Los verdaderos hackers usan C”
- Publicidad y marketing
- Charlas, conferencias, líderes carismáticos
Qué hace que un lenguaje sea “bueno”?
Especifica programas bien formados
- Un lenguaje debe describir
- Qué programas son bien formados
- Qué programas son mal formados
Define a qué se parecen los programas.
Describe el comportamiento de los programas
- Un lenguaje debe describir
- Cómo los programas bien formados deben comportarse
- Qué salidas son aceptables, qué otras no
- Qué programas son equivalentes, qué otros no
Define lo que los programas deben hacer.
Facilita la combinación de programas
- Debería ser posible:
- Entender un programa mirando sus partes
- Juntar programas sin causar bugs
- Esencial para manejar la complejidad
- Hace que un lenguaje se sienta elegante y bien diseñado
Dificulta escribir programas malos
- Hace que algunos errores sean imposibles
- Punteros nulos, buffer overflow, casos omitidos…
- Ataja errores temprano, durante la compilación
- Mejor que no se caiga el sistema mientras lanzamos un cohete
- Advertir al programador que está haciendo algo peligroso
Plan de la materia y formato
Experiencia teórica y práctica
- Empezando con la parte más teórica:
- cálculo lambda
- un “lenguaje” de los años 1930 más viejo que las máquinas de Turing!
- Usaremos un lenguaje de programación moderno: Haskell
- Programación funcional
- Sistema de tipos avanzado
- Mucho control sobre los efectos laterales
- Terminaremos con lo más práctico
- Desarrollo real de proyectos
- Uso de librerías
Detalles
- Parciales
- un primero más teórico
- un segundo más práctico
- Examen Final: dos opciones
- proyecto en Haskell presentado con anticipación
- o, por defecto, examen escrito “clásico”
- comunicación: Teams o mail guillaume.hoffmann@conicet.gov.ar
Lecturas
- ¡Aprende Haskell por el bien de todos!
- Escrito en el 2011
- Haskell cambió mucho esde entonces
- Consecuencia interesante: arreglar los ejemplos
- Documentación de librerias
- casi todo en inglés, sorry
Fin
Fuente: https://pages.cs.wisc.edu/~justhsu/teaching/current/cs538/
Lección siguiente, cálculo lambda.