19 \mbox{}\hfill\textit{ --- a joke read on Twitter}\bigskip

    19 \mbox{}\hfill\textit{ --- a joke on Twitter}\bigskip

    29 and also for generating JavaScript code to build browser applications

    29 for generating JavaScript code to build browser applications

    30 \url{(https://www.scala-js.org)}. Moreover there is work under way to

    30 \url{(https://www.scala-js.org)}; and there is work under way to

    39 or at least to some substantial degree. Scala seems useful as well in

    39 or at least to some substantial degree. Scala seems also useful in

    96 Scala can be used with the heavy-duty IDEs Eclipse and IntelliJ too.

    96 Scala can be used with the heavy-duty IDEs Eclipse and IntelliJ.

   124 quite different from what you are  used to in your study so far. It might

   124 quite different from what you are  used to in your study so far. It

   125 even be totally alien to you. The reason is that functional programming

   125 might even be totally alien to you. The reason is that functional

   126 seems to go against the core principles of \textit{imperative

   126 programming seems to go against the core principles of

   127 programming} (which is what you do in Java and C++ for example). The

   127 \textit{imperative programming} (which is what you do in Java and C++

   128 main idea of imperative programming  is that you have some form of

   128 for example). The main idea of imperative programming  is that you have

   129 ``state'' in your program and you continuously change this state by

   129 some form of ``state'' in your program and you continuously change this

   130 issuing some commands. The classic example for this style of programming

   130 state by issuing some commands (e.g.~updating a field in an array,

   131 is a \texttt{for}-loop, say

   131 adding one to a variable and so on). The classic example for this style

   132 of programming is a \texttt{for}-loop, say

   141 loop-iteration until it reaches \texttt{20} when the loop is exited, and

   142 loop-iteration until it reaches \texttt{20} when the loop is exited.

   142 something else happens in the program. When this code actually runs

   143 When this code is compiled and actually runs, there will be some

   143 there will be some memory cell reserved containing the value of

   144 dedicated space reserved in memory which contains the value of

   144 \texttt{i}, say \texttt{10} at the beginning, and the content is then

   145 \texttt{i}\ldots\texttt{10} at the beginning, and then the content will

   145 updated, or replaced, by some new content in every iteration.  The main

   146 be updated, or replaced, by some new content in every iteration.  The

   146 point is that this kind of updating memory cells is \textbf{PURE EVIL}!!

   147 main point here is that this kind of updating, or manipulating, memory 

   148 is \textbf{PURE EVIL}!!

   153 clock-speed has not much increased in the past few years and no dramatic

   155 clock-speed has not much increased over the past few years and no

   154 increases are predicted any time soon. So you are a bit stuck, unlike

   156 dramatic increases are predicted any time soon. So you are a bit stuck,

   155 previous generations of developers who could rely upon the fact that

   157 unlike previous generations of developers who could rely upon the fact

   156 every 2 years or so their code run twice as fast (in ideal

   158 that every 2 years or so their code run twice as fast (in ideal

   157 circumstances) because the clock-speed their CPUs got twice as fast.

   159 circumstances) because the clock-speed of their CPUs got twice as fast.

   158 This does not happen any more unfortunately. To get you out of this

   160 This unfortunately does not happen any more nowadays. To get you out of

   159 embarrassing situation, CPU producers pile more and more cores into CPUs

   161 this embarrassing situation, CPU producers pile more and more cores into

   160 in order to make them more powerful and potentially make software

   162 CPUs in order to make them more powerful and potentially make software

   164 sometimes much more on high-end machines). In this situation variables

   166 sometimes much more on high-end machines). In this situation,

   165 like \texttt{i} are evil, or at least a major nuisance. Because if you

   167 \textit{mutable} variables like \texttt{i} above are evil, or at least a

   166 want to distribute some of the loop-iterations from the for-loop above

   168 major nuisance. Because if you want to distribute some of the

   167 over some of the cores that are currently idle in your system, you need

   169 loop-iterations over the cores that are currently idle in your system,

   168 to be extremely careful about who can read and write (update) the

   170 you need to be extremely careful about who can read and write (update)

   169 variable \texttt{i}.\footnote{If you are of the belief that nothing

   171 the variable \texttt{i}.\footnote{If you are of the belief that nothing

   170 nasty can happen to \texttt{i} inside the loop, then you need to go back

   172 nasty can happen to \texttt{i} inside the \texttt{for}-loop, then you

   171 over the C++ material.} Especially the writing operation is critical

   173 need to go back over the C++ material.} Especially the writing operation

   172 because you do not want that it gets unintentionally overwritten. Untold

   174 is critical because you do not want that conflicting writes mess about

   173 number of problems have arisen from this problem. The catch is that if

   175 with \texttt{i}. An untold amount of misery has arisen from this

   174 you try to be as defensive as possible about reads and writes to

   176 problem. The catch is that if you try to solve this problem in C++ or

   175 \texttt{i}, then you synchronise access to it and as a result your

   177 Java, and be as defensive as possible about reads and writes to

   176 program waits more than it runs, thereby  defeating the point of trying

   178 \texttt{i}, then you need to synchronise access to it and as a result

   177 to run the program in parallel in the first place. If you are less

   179 your program more often than not waits more than it runs, thereby

   178 defensive, then usually all hell breaks loose by seemingly obtaining

   180 defeating the point of trying to run the program in parallel in the

   179 random results.

   181 first place. If you are less defensive, then usually all hell breaks

   182 loose by seemingly obtaining random results. And forget the idea of

   183 being able to debug such code.

   182 programs. Because of this it is easy to parallelize your program,

   186 programs. Because then it is easy to parallelize the resulting programs:

   183 because if you do not have any state, then once created all

   187 if you do not have any state, then once created all memory content stays

   184 memory content stays unchanged and reads (and writes) to memory are 

   188 unchanged and reads to such memory are absolutely safe without the need

   185 safe without the need of any synchronisations. An example is given 

   189 of any synchronisations. An example is given in Figure~\ref{mand} where

   186 in Figure~\ref{mand} where Scala makes it easy to calculate the 

   190 in the absence of annoying state, Scala makes it easy to calculate the

   187 Mandelbrot set on as many cores of your CPU as possible. Why is it

   191 Mandelbrot set on as many cores of your CPU as possible. Why is it so

   188 so easy? Because each pixel in the Mandelbrot set can be calculated

   192 easy in this example? Because each pixel in the Mandelbrot set can be

   189 independently. Going from the sequential version of the 

   193 calculated independently and the calculation does not need to update any

   190 program to the parallel version takes exactly the addition of 8 

   194 variable. It is so easy in fact, that going from the sequential version

   191 characters. What is not to be liked about that?

   195 of the program to the parallel version can be done by adding just eight

   196 characters. What is not to be liked about that (try the same in C++)?

   194 

   199   \includegraphics[scale=0.15]{../pics/mand1.png}

   195 \caption{\label{Bla}}

   200 

   201   \includegraphics[scale=0.15]{../pics/mand4.png}

   202   \includegraphics[scale=0.15]{../pics/mand3.png}

   203 \caption{\label{mand}}

   198 But remember that this easy parallelisation requires that we have no

   206 But remember that this easy parallelisation of code requires that we

   199 state in our program\ldots{} no counters like\texttt{i} seen in the

   207 have no state in our program\ldots{} that is no counters like\texttt{i}

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

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

   201 counters? Well, teaching you that this is possible is the point of the

   209 such counters? Well, teaching you that this is possible is the main

   202 functional programming language Scala in PEP. I can assure you it is

   210 point of the Scala-part in PEP. I can assure you it is possible, but you

   203 possible and actually fun to have no state in your programs (a side

   211 have to get your head around it. Once you mastered this, it will be fun

   204 product is that it makes it easier to debug them; and the memory

   212 to have no state in your programs (a side product is that it much easier

   205 we might waste by not allowing in-place updates is taken care of by the

   213 to debug state-less code; and the memory we might waste by not allowing

   206 memory garbage collector of Java and Scala).

   214 in-place updates is taken care of by the memory garbage collector of

   215 Java and Scala).