--- a/handouts/pep-ho.tex	Wed Feb 05 12:24:27 2020 +0000
+++ b/handouts/pep-ho.tex	Fri Apr 10 12:12:48 2020 +0100
@@ -41,6 +41,9 @@
 % nice example for map and reduce using Harry potter characters
 % https://www.matthewgerstman.com/map-filter-reduce/
 
+% interesting talk about differences in Java and Scala
+% Goto'19 conference ; about differences in type-system
+% https://www.youtube.com/watch?v=e6n-Ci8V2CM
 
 % Timing
 %
@@ -207,19 +210,19 @@
 
 Before we go on, let me explain a bit more why we want to inflict upon
 you another programming language. You hopefully have mastered Java and
-C++\ldots{}the world should be your oyster, no? Well, this is not as
-simple as one might wish. We do require Scala in PEP, but actually we
-do not religiously care whether you learn Scala---after all it is just
-a programming language (albeit a nifty one IMHO). What we do care
-about is that you learn about \textit{functional programming}. Scala
-is just the vehicle for that. Still, you need to learn Scala well
-enough to get good marks in PEP, but functional programming could
-equally be taught with Haskell, F\#, SML, Ocaml, Kotlin, Clojure,
-Scheme, Elm and many other functional programming languages.
-%Your
-%friendly lecturer just happens to like Scala
-%and the Department agreed that it is a good idea to inflict Scala upon
-%you.
+C++\ldots{}the world should be your oyster, no? Well, matters are not as
+simple as one might wish. We do require Scala in PEP, but actually we do
+not religiously care whether you learn Scala---after all it is just a
+programming language (albeit a nifty one IMHO). What we do care about is
+that you learn about \textit{functional programming}. Scala is just the
+vehicle for that. Still, you need to learn Scala well enough to get good
+marks in PEP, but functional programming could perhaps equally be taught
+with Haskell, F\#, SML, Ocaml, Kotlin, Clojure, Scheme, Elm and many
+other functional programming languages. 
+
+%Your friendly lecturer just
+%happens to like Scala and the Department agreed that it is a good idea
+%to inflict Scala upon you.
 
 Very likely writing programs in a functional programming language is
 quite different from what you are  used to in your study so far. It
@@ -265,30 +268,31 @@
 stuck. This is unlike previous generations of developers who could rely
 upon the fact that approximately every 2 years their code would run
 twice as fast  because the clock-speed of their CPUs got twice as fast.
+
 Unfortunately this does not happen any more nowadays. To get you out of
 this dreadful 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 cores you have available (typically 4 in modern laptops and
-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 overwrite the
-variable \texttt{i}.\footnote{If you are of the mistaken 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}. Take my word: an untold amount of misery has
-arisen from this problem. The catch is that if you try to solve this
-problem in C/C++ or Java, and be as defensive as possible about reads
-and writes to \texttt{i}, then you need to synchronise access to it. The
-result is that very often 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. And forget the idea of
-being able to debug such code.
+as many cores you have available (typically 4 or more in modern laptops
+and sometimes much more on high-end machines). In this situation
+\textit{mutable} variables like \texttt{i} in the C-code above are evil,
+or at least a major nuisance: Because if you want to distribute some of
+the loop-iterations over several cores that are currently idle in your
+system, you need to be extremely careful about who can read and
+overwrite the variable \texttt{i}.\footnote{If you are of the mistaken
+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}. Take my word: an
+untold amount of misery has arisen from this problem. The catch is that
+if you try to solve this problem in C/C++ or Java, and be as defensive
+as possible about reads and writes to \texttt{i}, then you need to
+synchronise access to it. The result is that very often 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. And forget the idea of being able to debug such code.
 
 The central idea of functional programming is to eliminate any state
 from programs---or at least from the ``interesting bits'' of the
@@ -1632,6 +1636,10 @@
 features of Scala and other languages, and it seems even it introduces
 new features on its own.
 
+
+Scala is deep: After many years, I still continue to learn new technique
+for writing more elegant code.
+
 %So all in all, Scala might not be a great teaching language,
 %but I hope this is mitigated by the fact that I never require
 %you to write any Scala code. You only need to be able to read