Finish first version of the introduction

doc/userdoc.org

@@ -342,24 +342,56 @@ made for that.
 
 Finally, python is ugly.
 
-*** TODO A high-level language
-
-Defining a suitable language
-
-**** Keep it simple
-
-**** Performances and parallelism
-
-- The language *does not allow* low-level manipulations of high-level
-  type variables. This means that for instance, one cannot access or
-  modify specific cell or node value. A consequence of such a choice
-  is that this *constrained framework* allows to write algorithms
-  (within the pugs language) that can be executed in parallel
-  naturally. To achieve that, there should *never* be parallel
-  instructions or instructions that require *explicit parallel* actions
-  in the ~pugs~ language.
-- Not providing low-level instruction simplifies the code and reduces
-  the risks of errors
+*** A high-level language
+
+Following the previous discussion, the reader should now understand
+the motivations that drive the design choices which made of ~pugs~ some
+kind of a ~C++~ toolbox driven by a user friendly language.
+
+#+begin_verse
+Keep it simple and relevant!
+#+end_verse
+
+In the development process of an application, the easy step is
+generally the implementation itself. It is even more true when the
+developer feels that the changes to code are natural and that the
+modifications themselves look easy. Obviously, any experienced
+programmer knows that writing the code is only the first step of a
+much longer process which requires rigorous tests and validations, the
+enrichment of a non-regression database. Generally one also desires to
+*ensure that the development is used within the correct bounds which
+requires to implement some checking. In a perfect world, an up-to-date
+documentation of the functionality and its domain of validity.
+
+This is even more true when defining a language (or a DSL). Enriching
+a language syntax (or grammar) is not something that must be done to
+answer a specific need. It must not be done /because it is possible to
+do it/!
+
+#+begin_verse
+When designing a language, the difficulty is not to offer new functionalities,\\
+it is generally to decide not to offer them.\\
+--- Bjarne Stroustrup, C++ conference 2021.
+#+end_verse
+
+If the grammar of ~pugs~ is still likely to be extended, it should *never*
+integrate low-level instructions. Low-level instructions give too much
+freedom and thus are a source of errors. Several things are already
+done to forbid this kind of evolution. The constness of high-level
+data for instance is a good illustration. In practice for instance
+meshes or discrete functions *cannot* be modified. This is not only a
+security that protects the user from doing "dangerous" manipulations,
+but that also permits to define high-level optimizations.
+- Since meshes are constant objects, one can for instance compute
+  geometric data on demand. These data are kept into memory as long as
+  the mesh lives.
+- Forbidding the modification of values of a discrete function ensures
+  that parallel communication instructions should never appear in a
+  ~pugs~ script.
+
+Another benefit of not providing low-level instructions is that the
+scripts are more easy to write and read, and it is more difficult to
+write errors.
 
 * TODO Language