138 lines
4.5 KiB
TeX
138 lines
4.5 KiB
TeX
\documentclass[10pt,a5paper,mathserif,serif,usenames,dvipsnames]{beamer}
|
|
|
|
% packages
|
|
\usepackage{xcolor}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{amsmath}
|
|
\usepackage{amsfonts}
|
|
\usepackage{amssymb}
|
|
\usepackage{graphicx}
|
|
\usepackage{listings}
|
|
|
|
% package configuration
|
|
\DeclareGraphicsExtensions{.pdf,.png,.jpg}
|
|
|
|
% title page information
|
|
\author{Julian Ospald}
|
|
\institute{FH Bielefeld}
|
|
\title{Haskell: introduction}
|
|
|
|
% color definition
|
|
\definecolor{solarized}{HTML}{002B36}
|
|
|
|
\begin{document}
|
|
|
|
% page 0
|
|
\frame{\titlepage}
|
|
|
|
% page 1
|
|
\begin{frame}
|
|
\frametitle{Why haskell?}
|
|
A Haskeller might claim: haskell...
|
|
\begin{itemize}
|
|
\item eliminates certain classes of bugs
|
|
\item makes it easy to reason about code
|
|
\item decreases the bus-factor
|
|
\item makes it possible to apply huge changes to large programs without worrying about the implicit state machine
|
|
\item makes it easier to program complex problems
|
|
\item allows for clean APIs, even without any OOP
|
|
\item a haskell program of 10K LOC isn't that much different to maintain as a 100K LOC
|
|
\end{itemize}
|
|
\vspace{\baselineskip}
|
|
We'll have to see if this holds true.
|
|
\end{frame}
|
|
|
|
% page 1
|
|
\begin{frame}[fragile]
|
|
\frametitle{Why haskell? (ctn.)}
|
|
From C++ std:
|
|
\lstset{
|
|
language=C++,
|
|
backgroundcolor=\color{White},
|
|
frame=single,
|
|
keepspaces=true
|
|
}
|
|
\begin{lstlisting}
|
|
void pop();
|
|
\end{lstlisting}
|
|
\lstset{
|
|
language=C,
|
|
}
|
|
From the C FLINT library:
|
|
\begin{lstlisting}
|
|
void fmpz_mod_poly_add(
|
|
fmpz_mod_poly_t res,
|
|
const fmpz_mod_poly_t poly1,
|
|
const fmpz_mod_poly_t poly2);
|
|
\end{lstlisting}
|
|
\vspace{\baselineskip}
|
|
Regular C functions in real-world (omitting examples on purpose):
|
|
\begin{itemize}
|
|
\item 100+ LOC
|
|
\item at least 7 ifs, 4 whiles, 12 variables, 1 goto
|
|
\item access both static and global variables
|
|
\item indenting level of 5 or more
|
|
\item a lot of memory management and custom-made error handling
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Why haskell? (ctn.)}
|
|
You need to change only one single line in such a C function. You have to know:
|
|
\begin{itemize}
|
|
\item does the order of function calls matter?
|
|
\item how does the change effect the memory management? Do we have memory leaks? Do we access invalid memory?
|
|
\item does it change the state of static or global variables?
|
|
\item does it implicitly change the state of out-parameters?
|
|
\item if it changes any of those states, is the function still correct?
|
|
\item does the program flow break? Do we have unreachable codepaths now?
|
|
\item did you just nuke a small former Soviet state?
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{Why haskell? (ctn.)}
|
|
But java helps! Does it?
|
|
Sort of, because:
|
|
\begin{itemize}
|
|
\item it improves APIs compared to C, since you can hide information in the state of an object (but... it's hidden now)
|
|
\item it has a garbage collector, so you don't need to worry too much about memory... unless it doesn't work OOTB anymore
|
|
\end{itemize}
|
|
Unfortunately, we:
|
|
\begin{itemize}
|
|
\item now got even more states to keep track of (intellectual complexity?)
|
|
\item have clouded the program flow... it's now about object-interaction with their implicit states
|
|
\item still have \textbf{side effects} everywhere: one object changes the state of another and vice versa, may arbitrarily write to the hard drive, do kernel calls or launch a missle
|
|
\end{itemize}
|
|
Some parts of the implicit state machine have been made explicit by modelling classes, but it's still there and we have to deal with it, because we are modelling everything around states. Wouldn't it be nice if we could just forget about the global state machine? Maybe there is even a way to remove side effects and have more "predictability"? We are lucky. There is. It's called \textbf{Haskell}.
|
|
\end{frame}
|
|
|
|
% page 2
|
|
\begin{frame}
|
|
\frametitle{What is haskell?}
|
|
Haskell is a \textbf{functional}, \textbf{pure}, \textbf{lazy} and \textbf{statically typed} high-level programming language.
|
|
\end{frame}
|
|
|
|
% page3
|
|
\begin{frame}
|
|
\frametitle{What does \textbf{functional} mean?}
|
|
Think of haskell functions as regular \emph{mathematical} functions.
|
|
\vspace{\baselineskip}
|
|
\includegraphics*[scale=0.4]{function-machine.png}
|
|
\begin{itemize}
|
|
\item does this function write to the hard drive?
|
|
\item does the output depend on anything else except the input (e.g. time, environment, ...)?
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
% page4
|
|
\begin{frame}
|
|
\frametitle{What does \textbf{functional} mean? (ctn.)}
|
|
\begin{itemize}
|
|
\item \emph{first-class} citizens: functions are values
|
|
\item a haskell program is what happens when \emph{expressions are evaluated}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\end{document} |