\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 missile
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"?
\onslide<+->
We are lucky. There is. It's called \textbf{Haskell}.
Haskell is a \textbf{functional}, \textbf{pure}, \textbf{lazy} and \textbf{statically typed} high-level programming language.\\
\onslide<+->
\vspace{\baselineskip}
A few of the following facts will be white lies. But let's not worry about that. It's maybe more about "how to think in terms of haskell?" than "what is haskell?".
In haskell expressions are not evaluated until their results are actually needed. That has a lot of consequences, a few of them being:
\onslide<+->
\begin{itemize}[<+->]
\item infinite data structures are now possible (recursive and non-recursive)
\item defining new control structures by just defining a function (since not everything is evaluated... who needs if-then-else anyway?)
\item important for compositional programming and efficiency
\item laziness causes (memory) overhead, but most of the time the benefits outweigh the costs
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{What does \textbf{statically typed} mean?}
Every haskell expression has a type and types are always checked at \emph{compile-time}. Programs with errors will not compile and definitely not run.\\
\vspace{\baselineskip}
It is possible to simulate dynamic types however. In the end, they are still statically type-checked (as in: the compiler always knows what's going on).
In haskell we often use \textbf{pattern matching}. That means we define a function multiple times, but e.g. for different values of its input arguments. Let's see:
These \verb#|# things above are called \textbf{guards} and are similar to \emph{pattern matching}. They are processed in order. If the condition on the left side of the equation is true, then it returns what stands on the right side of the equation. If it's false, then it processes the next line.\\\code{otherwise} on the last line is just defined as \code{True}, to make these constructs easier to read and catch all other cases of input.
Note: we use \code{(x, y)} notation for both the type and the definition! Those are still two different things. We can also have triples, quadruples etc.
\end{frame}
\begin{frame}[fragile]
\frametitle{Lists}
\setHaskellCodeStyle
The list is probably the most basic data structure in Haskell. Like the array in C. It is a singly-linked list and is very lazy. The compiler has numerous ways to optimize lists, so don't be afraid to use them, even for huge things.
\pause
We build lists by using either the \code{[]} notation:
\begin{lstlisting}
list1 :: [Integer]
list1 = [1, 2]
\end{lstlisting}
\pause
or by using the \emph{cons} operator \code{(:)} which takes an element and a list and produces a new list with the element prepended to the front.
Of course we can also define our own data types in haskell. One very common type is the \emph{enumeration}. For example, we could define a data type for the Week:
This declares the new data type \code{WeekDay} with 7 \emph{constructors}. That means \code{Monday}, \code{Tuesday} etc. are all values of the type \code{WeekDay}.
\pause
\\
We could now define a whole week, by creating a list:
But we can do more than enumerations. How about we do some error handling? Let's say we want a function to return an \code{Int}, but in case something went horribly wrong, we don't just want to return a 0 or some magic number, but a proper error message. Here we go:
\pause
\setHaskellCodeStyle
\begin{lstlisting}
data MaybeInt = NoError Int
| Error String
\end{lstlisting}
\pause
So constructors are just \emph{functions}! And they can have arguments, just like functions. Let's check their types:
Let's define something more complex. How about a tree?
\pause
\setHaskellCodeStyle
\begin{lstlisting}
data Tree = Leaf Char
| Node Tree Int Tree
\end{lstlisting}
Uh... that looks mean. Let's examine this.\\
\pause
We have:
\begin{itemize}[<+->]
\item defined a data type \code{Tree}
\item a constructor \code{Leaf} of type \code{Tree} with one arguments of type \code{Char}
\item a constructor \code{Node} of type \code{Tree} with 3 arguments
\begin{itemize}[<+->]
\item\code{Tree}
\item\code{Int}
\item\code{Tree}
\end{itemize}
\end{itemize}
\onslide<+->
That means: a \code{Tree} can either be a \code{Leaf} or an internal \code{Node} with two sub-trees. If we want to create a \code{Leaf}, we have to pass the constructor a \code{Char}. If we want to create a \code{Node}, we have to pass 3 arguments, in order: another \code{Tree}, an \code{Int} and yet another \code{Tree}.\\
So we can save information in the leafs (\code{Char}) and in the internal nodes (\code{Int}).\\
This is just an example. There are endless more ways of trees.
\end{frame}
\begin{frame}[fragile]
\frametitle{Algebraic Data Types (ctn.)}
Let's build our tree:
\setHaskellCodeStyle
\begin{lstlisting}
tree :: Tree
tree = Node
(Leaf 'x')
1
(Node
(Leaf 'y')
2
(Leaf 'z')
)
\end{lstlisting}
See board...
\end{frame}
\begin{frame}[fragile]
\frametitle{Algebraic Data Types (ctn.)}
So if we want to generalize it, an algebraic data type has one or more \textbf{constructors}, and each of them can have zero or more arguments. E.g.:
Haskell is very powerful and can be used for pretty much anything. However, there are difficulties in any language. Let's name a few for haskell:
\begin{itemize}[<+->]
\item intellectual complexity? New way of thinking?
\item although you rarely need it in haskell, debugging can be difficult at times
\item because the type system is extremely powerful/complex, type error messages can be very confusing and don't always show the error you expected
\item no premium-like IDE with every possible feature (yet)
\item dynamic linking is sort of WIP yet, lots of ABI breakage
\item because most of the world thinks in imperative style languages, it's often difficult to find pseudo-code for functional style languages, so you end up reverse-engineering algorithms
\item some problems that are trivial in imperative languages, can be very difficult to solve in idiomatic haskell and vice versa
\item practical cryptography is possible, but a difficult topic in haskell, see \url{https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118059.html}
\item much content was borrowed or is based on the haskell course from Brent Yorgey:\\\url{https://www.seas.upenn.edu/~cis194/fall14/spring13/lectures.html}
\item a few small pieces from the LYAH book \url{http://learnyouahaskell.com}
\item general information from wikipedia: \\\url{https://en.wikipedia.org}
\item general information from haskell wiki: \\\url{https://wiki.haskell.org}