\item an experienced programmer will find it easier to manage side-effects in Java, because you can e.g. have every impure functions throw an IO exception
\item have clouded the program flow... it's now about object-interaction with their explicit and implicit states and because of the increase of indirection, it might get even harder to do actual abstraction
\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"?
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
\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.\\
It is possible to simulate dynamic types however, i.e. types which may be converted to the type you need them in, following rigid rules. In the end, they are still statically type-checked (as in: the compiler always knows what's going on).
\item "develop a solution space, rather than an individual solution" -- Ralf Hinze
\item "imagine a graph, rather than a single path" -- Ralf Hinze
\item "first solve a more general problem, then extract the interesting bits and pieces by transforming the general program into more specialised ones" -- Ralf Hinze
\end{itemize}
\item solve atomic parts of general problems and combine them into greater solution
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}