docs/introduction: move CUE history to separate page

This moves the history-of-CUE content from the first page of the
introduction to its own page.

This reflects its non-critical place in the newcomer's critical path of
deciding if CUE is worth evaluating further - specifically their
tactical "is reading this specific page a prerequisite to trying out
CUE?" decision making; whilst recognising the importance of
communicating how CUE came to be, and from where, which will be
of particular interest to the language-design-folks audience.

Preview-Path: /docs/introduction/
Preview-Path: /docs/introduction/history/
Signed-off-by: Jonathan Matthews <github@hello.jonathanmatthews.com>
Change-Id: I6d868c9ed61a5856d8bb4c267830b65694ced47a
Dispatch-Trailer: {"type":"trybot","CL":1196380,"patchset":3,"ref":"refs/changes/80/1196380/3","targetBranch":"master"}

content/docs/introduction/_en.md

@@ -57,43 +57,6 @@ one schema is also an instance of another (is it backwards compatible?),
 or compute a new schema that represents all instances that match
 two other schema.
 
-
-## History
-
-Although it is a very different language, the roots of CUE lie in GCL,
-the dominant configuration language in use at Google as of this writing.
-It was originally designed to configure Borg, the predecessor of Kubernetes.
-In fact, the original idea was to use graph unification as used in CUE for GCL.
-One of the authors of GCL had extensive experience with such systems and
-experienced the benefit of being able to compute and reason with types for the
-creation of powerful tooling.
-
-The graph unification model CUE is based on
-was in common use in computational linguistics at that time and was
-successfully used to manage grammars and lexicons of over 100k lines of
-declarative definitions.
-These were effectively very large
-configurations of something as irregular and complex as a human language.
-A property of these systems were that the types, or constraints, one
-defines validate the data while simultaneously reducing boilerplate.
-Overall, this approach seemed to be extremely well-suited
-for cloud configuration.
-
-However, the early design of GCL went for something simpler that coincidentally
-was also incompatible with the notion of graph unification.
-This simpler approach proved insufficient, but it was already too late to
-move to the earlier foreseen approach.
-Instead, an inheritance-based override model was adopted.
-Its complexity made the earlier foreseen tooling intractable
-and they never materialized.
-The same holds for the GCL offsprings that copied its model.
-
-CUE goes back to the original idea of using a constraint-based approach and
-also makes an effort to incorporate lessons learned from 15 years of GCL usage.
-This also includes lessons learned from offsprings and different approaches to
-configuration altogether.
-
-
 ## Philosophy and principles
 
 ### Types are Values

content/docs/introduction/history/en.md

@@ -0,0 +1,37 @@
+---
+title: History
+weight: 40
+---
+
+Although it is a very different language, the roots of CUE lie in GCL,
+the dominant configuration language in use at Google as of this writing.
+It was originally designed to configure Borg, the predecessor of Kubernetes.
+In fact, the original idea was to use graph unification as used in CUE for GCL.
+One of the authors of GCL had extensive experience with such systems and
+experienced the benefit of being able to compute and reason with types for the
+creation of powerful tooling.
+
+The graph unification model CUE is based on
+was in common use in computational linguistics at that time and was
+successfully used to manage grammars and lexicons of over 100k lines of
+declarative definitions.
+These were effectively very large
+configurations of something as irregular and complex as a human language.
+A property of these systems were that the types, or constraints, one
+defines validate the data while simultaneously reducing boilerplate.
+Overall, this approach seemed to be extremely well-suited
+for cloud configuration.
+
+However, the early design of GCL went for something simpler that coincidentally
+was also incompatible with the notion of graph unification.
+This simpler approach proved insufficient, but it was already too late to
+move to the earlier foreseen approach.
+Instead, an inheritance-based override model was adopted.
+Its complexity made the earlier foreseen tooling intractable
+and they never materialized.
+The same holds for the GCL offsprings that copied its model.
+
+CUE goes back to the original idea of using a constraint-based approach and
+also makes an effort to incorporate lessons learned from 15 years of GCL usage.
+This also includes lessons learned from offsprings and different approaches to
+configuration altogether.

content/docs/introduction/history/page.cue

@@ -0,0 +1,3 @@
+package site
+
+content: docs: introduction: history: page: _

hugo/content/en/docs/introduction/_index.md

@@ -57,43 +57,6 @@ one schema is also an instance of another (is it backwards compatible?),
 or compute a new schema that represents all instances that match
 two other schema.
 
-
-## History
-
-Although it is a very different language, the roots of CUE lie in GCL,
-the dominant configuration language in use at Google as of this writing.
-It was originally designed to configure Borg, the predecessor of Kubernetes.
-In fact, the original idea was to use graph unification as used in CUE for GCL.
-One of the authors of GCL had extensive experience with such systems and
-experienced the benefit of being able to compute and reason with types for the
-creation of powerful tooling.
-
-The graph unification model CUE is based on
-was in common use in computational linguistics at that time and was
-successfully used to manage grammars and lexicons of over 100k lines of
-declarative definitions.
-These were effectively very large
-configurations of something as irregular and complex as a human language.
-A property of these systems were that the types, or constraints, one
-defines validate the data while simultaneously reducing boilerplate.
-Overall, this approach seemed to be extremely well-suited
-for cloud configuration.
-
-However, the early design of GCL went for something simpler that coincidentally
-was also incompatible with the notion of graph unification.
-This simpler approach proved insufficient, but it was already too late to
-move to the earlier foreseen approach.
-Instead, an inheritance-based override model was adopted.
-Its complexity made the earlier foreseen tooling intractable
-and they never materialized.
-The same holds for the GCL offsprings that copied its model.
-
-CUE goes back to the original idea of using a constraint-based approach and
-also makes an effort to incorporate lessons learned from 15 years of GCL usage.
-This also includes lessons learned from offsprings and different approaches to
-configuration altogether.
-
-
 ## Philosophy and principles
 
 ### Types are Values

hugo/content/en/docs/introduction/history/index.md

@@ -0,0 +1,37 @@
+---
+title: History
+weight: 40
+---
+
+Although it is a very different language, the roots of CUE lie in GCL,
+the dominant configuration language in use at Google as of this writing.
+It was originally designed to configure Borg, the predecessor of Kubernetes.
+In fact, the original idea was to use graph unification as used in CUE for GCL.
+One of the authors of GCL had extensive experience with such systems and
+experienced the benefit of being able to compute and reason with types for the
+creation of powerful tooling.
+
+The graph unification model CUE is based on
+was in common use in computational linguistics at that time and was
+successfully used to manage grammars and lexicons of over 100k lines of
+declarative definitions.
+These were effectively very large
+configurations of something as irregular and complex as a human language.
+A property of these systems were that the types, or constraints, one
+defines validate the data while simultaneously reducing boilerplate.
+Overall, this approach seemed to be extremely well-suited
+for cloud configuration.
+
+However, the early design of GCL went for something simpler that coincidentally
+was also incompatible with the notion of graph unification.
+This simpler approach proved insufficient, but it was already too late to
+move to the earlier foreseen approach.
+Instead, an inheritance-based override model was adopted.
+Its complexity made the earlier foreseen tooling intractable
+and they never materialized.
+The same holds for the GCL offsprings that copied its model.
+
+CUE goes back to the original idea of using a constraint-based approach and
+also makes an effort to incorporate lessons learned from 15 years of GCL usage.
+This also includes lessons learned from offsprings and different approaches to
+configuration altogether.