--- a/handouts/pep-ho.tex	Sun Aug 11 21:01:49 2019 +0100
+++ b/handouts/pep-ho.tex	Tue Aug 13 10:23:20 2019 +0100
@@ -337,29 +337,33 @@
 \end{boxedminipage}
 \end{figure}  
 
-But remember this easy parallelisation of code requires that we
-have no state in our programs\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
-one of the main points of the Scala-part in PEP. I can assure you it is
-possible, but you have to get your head around it. Once you have
-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 also more
-often than not easier to understand). So have fun with
-Scala!\footnote{If you are still not convinced about the function
-programming ``thing'', there are a few more arguments: a lot of research
-in programming languages happens to take place in functional programming
-languages. This has resulted in ultra-useful features such as
-pattern-matching, strong type-systems, laziness, implicits, algebraic
-datatypes  to name a few. Imperative languages seem to often lag behind
-in adopting them: I know, for example, that Java will at some point in
-the future support pattern-matching, which has been used for example 
-in SML for at
-least 40(!) years. See
+But remember this easy parallelisation of code requires that we have no
+state in our programs\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 one of the
+main points of the Scala-part in PEP. I can assure you it is possible,
+but you have to get your head around it. Once you have 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 also more often than not easier
+to understand). So have fun with Scala!\footnote{If you are still not
+convinced about the function programming ``thing'', there are a few more
+arguments: a lot of research in programming languages happens to take
+place in functional programming languages. This has resulted in
+ultra-useful features such as pattern-matching, strong type-systems,
+laziness, implicits, algebraic datatypes  to name a few. Imperative
+languages seem to often lag behind in adopting them: I know, for
+example, that Java will at some point in the future support
+pattern-matching, which has been used for example in SML for at least
+40(!) years. See
 \url{http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html}.
-Also Rust, a C-like programming language that has been developed since
-2010 and is gaining quite some interest, borrows many ideas from
-functional programming from yesteryear.}
+Automatic garbage collection was included in Java in 1995; the
+functional language LISP had this already in 1958. Generics were added
+to Java 5 in 2004; the functional language SML had it since 1990.
+Higher-order functions were added to C$\sharp$ in 2007, to Java 8 in
+2014; again LISP had them since 1958. Also Rust, a C-like programming
+language that has been developed since 2010 and is gaining quite some
+interest, borrows many ideas from functional programming from
+yesteryear.}
 
 
 \subsection*{The Very Basics}