340 But remember this easy parallelisation of code requires that we

   340 But remember this easy parallelisation of code requires that we have no

   341 have no state in our programs\ldots{}that is no counters like

   341 state in our programs\ldots{}that is no counters like \texttt{i} in

   342 \texttt{i} in \texttt{for}-loops. You might then ask, how do I write

   342 \texttt{for}-loops. You might then ask, how do I write loops without

   343 loops without such counters? Well, teaching you that this is possible is

   343 such counters? Well, teaching you that this is possible is one of the

   344 one of the main points of the Scala-part in PEP. I can assure you it is

   344 main points of the Scala-part in PEP. I can assure you it is possible,

   345 possible, but you have to get your head around it. Once you have

   345 but you have to get your head around it. Once you have mastered this, it

   346 mastered this, it will be fun to have no state in your programs (a side

   346 will be fun to have no state in your programs (a side product is that it

   347 product is that it much easier to debug state-less code and also more

   347 much easier to debug state-less code and also more often than not easier

   348 often than not easier to understand). So have fun with

   348 to understand). So have fun with Scala!\footnote{If you are still not

   349 Scala!\footnote{If you are still not convinced about the function

   349 convinced about the function programming ``thing'', there are a few more

   350 programming ``thing'', there are a few more arguments: a lot of research

   350 arguments: a lot of research in programming languages happens to take

   351 in programming languages happens to take place in functional programming

   351 place in functional programming languages. This has resulted in

   352 languages. This has resulted in ultra-useful features such as

   352 ultra-useful features such as pattern-matching, strong type-systems,

   353 pattern-matching, strong type-systems, laziness, implicits, algebraic

   353 laziness, implicits, algebraic datatypes  to name a few. Imperative

   354 datatypes  to name a few. Imperative languages seem to often lag behind

   354 languages seem to often lag behind in adopting them: I know, for

   355 in adopting them: I know, for example, that Java will at some point in

   355 example, that Java will at some point in the future support

   356 the future support pattern-matching, which has been used for example 

   356 pattern-matching, which has been used for example in SML for at least

   357 in SML for at

   357 40(!) years. See

   358 least 40(!) years. See

   360 Also Rust, a C-like programming language that has been developed since

   359 Automatic garbage collection was included in Java in 1995; the

   361 2010 and is gaining quite some interest, borrows many ideas from

   360 functional language LISP had this already in 1958. Generics were added

   362 functional programming from yesteryear.}

   361 to Java 5 in 2004; the functional language SML had it since 1990.

   362 Higher-order functions were added to C$\sharp$ in 2007, to Java 8 in

   363 2014; again LISP had them since 1958. Also Rust, a C-like programming

   364 language that has been developed since 2010 and is gaining quite some

   365 interest, borrows many ideas from functional programming from

   366 yesteryear.}