Browse Source

Small improvements

Julian Ospald 4 years ago
parent
commit
56aa6c1d71
No account linked to committer's email address
1 changed files with 7 additions and 5 deletions
  1. 7
    5
      VL1.tex

+ 7
- 5
VL1.tex View File

@@ -70,7 +70,7 @@ Regular C functions in real-world (omitting examples on purpose):
70 70
 \begin{itemize}
71 71
 \item 100+ LOC
72 72
 \item at least 7 ifs, 4 whiles, 12 variables, 1 goto
73
-\item access both static and global variables
73
+\item accesses both static and global variables
74 74
 \item indenting level of 5 or more
75 75
 \item a lot of memory management and custom-made error handling
76 76
 \end{itemize}
@@ -85,9 +85,11 @@ You need to change only one single line in such a C function. You have to know:
85 85
 \item does it change the state of static or global variables?
86 86
 \item does it implicitly change the state of out-parameters?
87 87
 \item if it changes any of those states, is the function still correct?
88
-\item does the program flow break? Do we have unreachable codepaths now?
88
+\item what happens if the program flow reaches this codepath with variable X in that particular state, while variable Z is NULL, and...
89 89
 \item did you just nuke a small former Soviet state?
90 90
 \end{itemize}
91
+\vspace{\baselineskip}
92
+Conclusion: you really need to understand the complete environment of that line/function.
91 93
 \end{frame}
92 94
 
93 95
 \begin{frame}
@@ -95,13 +97,13 @@ You need to change only one single line in such a C function. You have to know:
95 97
 But java helps! Does it?
96 98
 Sort of, because:
97 99
 \begin{itemize}
98
-\item it improves APIs compared to C, since you can hide information in the state of an object (but... it's hidden now)
99
-\item it has a garbage collector, so you don't need to worry too much about memory... unless it doesn't work OOTB anymore
100
+\item it improves APIs compared to C, since you can hide or encapsulate information in the state of an object
101
+\item it has a garbage collector, so you don't need to worry too much about memory
100 102
 \end{itemize}
101 103
 Unfortunately, we:
102 104
 \begin{itemize}
103 105
 \item now got even more states to keep track of (intellectual complexity?)
104
-\item have clouded the program flow... it's now about object-interaction with their implicit states
106
+\item have clouded the program flow... it's now about object-interaction with their explicit and implicit states
105 107
 \item still have \textbf{side effects} everywhere: one object changes the state of another and vice versa, may arbitrarily write to the hard drive, do kernel calls or launch a missle
106 108
 \end{itemize}
107 109
 Some parts of the implicit state machine have been made explicit by modelling classes, but it's still there and we have to deal with it, because we are modelling everything around states. Wouldn't it be nice if we could just forget about the global state machine? Maybe there is even a way to remove side effects and have more "predictability"? We are lucky. There is. It's called \textbf{Haskell}.