Small fixes.

diff --git a/Report/Main/Conclusions.tex b/Report/Main/Conclusions.tex
index 845d7b2e96d4fc07f0eabeaa7c400d593446e2ef..53f5ba45148057b522a8be8f5e8f8b282f17e9f5 100644 (file)
--- a/Report/Main/Conclusions.tex
+++ b/Report/Main/Conclusions.tex
@@ -4,12 +4,12 @@ these lessons are very practical in nature (from how working in a company works
 to how to solve specific coding problems), there are also a number of higher
 level observations to be made.
 
-For example, I have found that the main challenge in solving a problem, is
+For example, I have found that the main challenge in creating solutions, is
 defining the actual problem you want to solve. This is clearly visible in the
 specification of MontiumC: If you don't know what the goals are, you can't
-really work towards them. But, on a smaller scale, this also holds on a smaller
-scale. When, during coding you encounter a problem, it's often easy to try to
-solve that problem. However, after stacking a few small solutions on top of each
+really work towards them. But this also holds on a smaller
+scale. When, during coding you encounter a problem, it's often easy to
+solve just that problem. However, after stacking a few small solutions on top of each
 other, things get complicated real fast. Then, it helps to take a step back and
 try to find the bigger problem you are trying to solve, and evaluate
 subsolutions in that perspective.
@@ -25,7 +25,7 @@ be overly complex.
 
 These limitations are also visible when working with the old hardware: The
 hardware poses a lot of limitations on its input, which makes it quite hard to
-build a proper compiler, that can reliably compile anything that it is supposed
+build a proper compiler that can reliably compile anything that it is supposed
 to. Again, adapting the hardware to support the compiler, has the potential to
 make the compiler considerably less complex and more reliable, at the cost of
 larger hardware complexity, area and power consumption.