--- a/handouts/pep-ho.tex Sat Jun 16 00:07:32 2018 +0100
+++ b/handouts/pep-ho.tex Sat Jun 16 15:13:48 2018 +0100
@@ -16,7 +16,7 @@
\mbox{}\hfill\textit{``Scala --- \underline{S}lowly \underline{c}ompiled
\underline{a}cademic \underline{la}nguage''}\smallskip\\
-\mbox{}\hfill\textit{ --- a joke read on Twitter}\bigskip
+\mbox{}\hfill\textit{ --- a joke on Twitter}\bigskip
\noindent
Scala is a programming language that combines functional and
@@ -26,8 +26,8 @@
Virtual Machine (JVM) and therefore Scala programs can run under MacOSX,
Linux and Windows.\footnote{There are also experimental backends of
Scala for producing code under Android (\url{http://scala-android.org});
-and also for generating JavaScript code to build browser applications
-\url{(https://www.scala-js.org)}. Moreover there is work under way to
+for generating JavaScript code to build browser applications
+\url{(https://www.scala-js.org)}; and there is work under way to
have a native Scala compiler generating X86-code
(\url{http://www.scala-native.org}).} Because of this it has also access to
the myriads of Java libraries. Unlike Java, however, Scala often allows
@@ -36,7 +36,7 @@
\url{https://www.slideshare.net/maximnovak/joy-of-scala}} A number
of companies---the Guardian, Twitter, Coursera, FourSquare, LinkedIn,
Netflix to name a few---either use Scala exclusively in production code,
-or at least to some substantial degree. Scala seems useful as well in
+or at least to some substantial degree. Scala seems also useful in
job-interviews (especially in Data Science) according to this anecdotal
report
@@ -93,7 +93,7 @@
\end{quote}
-Scala can be used with the heavy-duty IDEs Eclipse and IntelliJ too.
+Scala can be used with the heavy-duty IDEs Eclipse and IntelliJ.
A ready-made Scala bundle for Eclipse is available from
\begin{quote}
@@ -121,14 +121,15 @@
\textit{functional programming}. Scala is just the vehicle for that.
Very likely writing programs in a functional programming language is
-quite different from what you are used to in your study so far. It might
-even be totally alien to you. The reason is that functional programming
-seems to go against the core principles of \textit{imperative
-programming} (which is what you do in Java and C++ for example). The
-main idea of imperative programming is that you have some form of
-``state'' in your program and you continuously change this state by
-issuing some commands. The classic example for this style of programming
-is a \texttt{for}-loop, say
+quite different from what you are used to in your study so far. It
+might even be totally alien to you. The reason is that functional
+programming seems to go against the core principles of
+\textit{imperative programming} (which is what you do in Java and C++
+for example). The main idea of imperative programming is that you have
+some form of ``state'' in your program and you continuously change this
+state by issuing some commands (e.g.~updating a field in an array,
+adding one to a variable and so on). The classic example for this style
+of programming is a \texttt{for}-loop, say
\begin{lstlisting}[language=C,numbers=none]
for (int i = 10; i < 20; i++) {
@@ -138,72 +139,80 @@
\noindent Here the variable \texttt{i} embodies the state, which is
first set to \texttt{10} and then increased by one in each
-loop-iteration until it reaches \texttt{20} when the loop is exited, and
-something else happens in the program. When this code actually runs
-there will be some memory cell reserved containing the value of
-\texttt{i}, say \texttt{10} at the beginning, and the content is then
-updated, or replaced, by some new content in every iteration. The main
-point is that this kind of updating memory cells is \textbf{PURE EVIL}!!
+loop-iteration until it reaches \texttt{20} when the loop is exited.
+When this code is compiled and actually runs, there will be some
+dedicated space reserved in memory which contains the value of
+\texttt{i}\ldots\texttt{10} at the beginning, and then the content will
+be updated, or replaced, by some new content in every iteration. The
+main point here is that this kind of updating, or manipulating, memory
+is \textbf{PURE EVIL}!!
\noindent
\ldots{}Well, it is perfectly benign if you have a sequential program
that gets run instruction by instruction...nicely one after another.
This kind of running code uses a single core of your CPU and goes as
fast as your CPU frequency (or clock-speed) allows. Unfortunately, this
-clock-speed has not much increased in the past few years and no dramatic
-increases are predicted any time soon. So you are a bit stuck, unlike
-previous generations of developers who could rely upon the fact that
-every 2 years or so their code run twice as fast (in ideal
-circumstances) because the clock-speed their CPUs got twice as fast.
-This does not happen any more unfortunately. To get you out of this
-embarrassing situation, CPU producers pile more and more cores into CPUs
-in order to make them more powerful and potentially make software
+clock-speed has not much increased over the past few years and no
+dramatic increases are predicted any time soon. So you are a bit stuck,
+unlike previous generations of developers who could rely upon the fact
+that every 2 years or so their code run twice as fast (in ideal
+circumstances) because the clock-speed of their CPUs got twice as fast.
+This unfortunately does not happen any more nowadays. To get you out of
+this embarrassing situation, CPU producers pile more and more cores into
+CPUs in order to make them more powerful and potentially make software
faster. The task for you as developer is to take somehow advantage of
these cores by running as much of your code as possible in parallel on
as many core you have available (typically 4 in modern laptops and
-sometimes much more on high-end machines). In this situation variables
-like \texttt{i} are evil, or at least a major nuisance. Because if you
-want to distribute some of the loop-iterations from the for-loop above
-over some of the cores that are currently idle in your system, you need
-to be extremely careful about who can read and write (update) the
-variable \texttt{i}.\footnote{If you are of the belief that nothing
-nasty can happen to \texttt{i} inside the loop, then you need to go back
-over the C++ material.} Especially the writing operation is critical
-because you do not want that it gets unintentionally overwritten. Untold
-number of problems have arisen from this problem. The catch is that if
-you try to be as defensive as possible about reads and writes to
-\texttt{i}, then you synchronise access to it and as a result your
-program waits more than it runs, thereby defeating the point of trying
-to run the program in parallel in the first place. If you are less
-defensive, then usually all hell breaks loose by seemingly obtaining
-random results.
+sometimes much more on high-end machines). In this situation,
+\textit{mutable} variables like \texttt{i} above are evil, or at least a
+major nuisance. Because if you want to distribute some of the
+loop-iterations over the cores that are currently idle in your system,
+you need to be extremely careful about who can read and write (update)
+the variable \texttt{i}.\footnote{If you are of the belief that nothing
+nasty can happen to \texttt{i} inside the \texttt{for}-loop, then you
+need to go back over the C++ material.} Especially the writing operation
+is critical because you do not want that conflicting writes mess about
+with \texttt{i}. An untold amount of misery has arisen from this
+problem. The catch is that if you try to solve this problem in C++ or
+Java, and be as defensive as possible about reads and writes to
+\texttt{i}, then you need to synchronise access to it and as a result
+your program more often than not waits more than it runs, thereby
+defeating the point of trying to run the program in parallel in the
+first place. If you are less defensive, then usually all hell breaks
+loose by seemingly obtaining random results. And forget the idea of
+being able to debug such code.
The idea of functional programming is to eliminate any state from
-programs. Because of this it is easy to parallelize your program,
-because if you do not have any state, then once created all
-memory content stays unchanged and reads (and writes) to memory are
-safe without the need of any synchronisations. An example is given
-in Figure~\ref{mand} where Scala makes it easy to calculate the
-Mandelbrot set on as many cores of your CPU as possible. Why is it
-so easy? Because each pixel in the Mandelbrot set can be calculated
-independently. Going from the sequential version of the
-program to the parallel version takes exactly the addition of 8
-characters. What is not to be liked about that?
+programs. Because then it is easy to parallelize the resulting programs:
+if you do not have any state, then once created all memory content stays
+unchanged and reads to such memory are absolutely safe without the need
+of any synchronisations. An example is given in Figure~\ref{mand} where
+in the absence of annoying state, Scala makes it easy to calculate the
+Mandelbrot set on as many cores of your CPU as possible. Why is it so
+easy in this example? Because each pixel in the Mandelbrot set can be
+calculated independently and the calculation does not need to update any
+variable. It is so easy in fact, that going from the sequential version
+of the program to the parallel version can be done by adding just eight
+characters. What is not to be liked about that (try the same in C++)?
\begin{figure}[p]
+ \includegraphics[scale=0.15]{../pics/mand1.png}
-\caption{\label{Bla}}
+ \includegraphics[scale=0.15]{../pics/mand4.png}
+ \includegraphics[scale=0.15]{../pics/mand3.png}
+\caption{\label{mand}}
\end{figure}
-But remember that this easy parallelisation requires that we have no
-state in our program\ldots{} no counters like\texttt{i} seen in the
-\texttt{for}-loop. You might then ask, how do I write loops without such
-counters? Well, teaching you that this is possible is the point of the
-functional programming language Scala in PEP. I can assure you it is
-possible and actually fun to have no state in your programs (a side
-product is that it makes it easier to debug them; and the memory
-we might waste by not allowing in-place updates is taken care of by the
-memory garbage collector of Java and Scala).
+But remember that this easy parallelisation of code requires that we
+have no state in our program\ldots{} that is no counters like\texttt{i}
+in \texttt{for}-loops. You might then ask, how do I write loops without
+such counters? Well, teaching you that this is possible is the main
+point of the Scala-part in PEP. I can assure you it is possible, but you
+have to get your head around it. Once you mastered this, it will be fun
+to have no state in your programs (a side product is that it much easier
+to debug state-less code; and the memory we might waste by not allowing
+in-place updates is taken care of by the memory garbage collector of
+Java and Scala).