removed a trash article

Rules

@@ -56,6 +56,7 @@ compile '/html/*' do
     	filter :description
     	filter :falacy
     	filter :blogimage
+        filter :erb # I should try to remove all erb code inside markdown
         filter :kramdown
         filter :fix_img
     else

content/css/main2.sass

@@ -41,6 +41,20 @@ a
 a:visited
   color: $base00
 
+
+#blackpage, #nojsredirect
+  top: 0
+  left: 0
+  width: 100%
+  min-height: 100%
+  margin-left: 0
+  margin-right: 0
+  margin-top: 0
+  margin-bottom: 0
+  position: absolute
+  text-align: center
+  background: $base3
+
 #content
   width: 37*$unit + 2*$hmargin
   margin: 0 auto
@@ -78,12 +92,12 @@ a:visited
     content: "- "
   ul
     padding-left: 0
-    margin-left: $hmargin
+    margin: $unit $hmargin
     // width of '-'
     text-indent: -($unit/2)
   ol
     padding-left: 0
-    margin-left: $hmargin
+    margin: $unit $hmargin
   .toc
     ol li, ul li
       margin: ($unit/2) 0
@@ -95,6 +109,12 @@ a:visited
     margin: 0
     padding: 0
 
+#entete > #choix > #choixrss
+  margin: 0
+  padding: 0
+#entete > #choix > #choixlang
+  float: left
+
 #choix
   font-size: (3*$unit / 4)
   padding: 0 $unit
@@ -113,6 +133,110 @@ p code, li code
   padding: 1px 2px
   background: $base3
   border: solid 1px $base2
+blockquote
+  border: solid 1px $base2
+  background: $base3
+  code
+    background: $base2
+    border: solid 1px rgba(0,0,0,0.1)
 
-#social
+// Specific elements
+#social,#choixrss,#comment
   margin: $unit $hmargin
+#social
+  float: left
+  opacity: 0.3
+  &:hover
+    opacity: 1
+#choixrss
+  float: right
+  opacity: 0.3
+  &:hover
+    opacity: 1
+#comment
+  img
+    width: auto
+    max-width: 100%
+.intro
+  font-size: 14px
+  line-height: 21px
+  color: $base02
+.left
+  float: left
+.right
+  float: right
+.flush
+  clear: both
+
+#bottom
+  padding: $unit 0
+  background: $base2
+  text-align: center
+  font-size: 14px
+  line-height: 21px
+#entete
+  padding: $unit 0
+  background: $base2
+  text-align: center
+  ul
+    text-indent: 0
+  ul li:before
+    content: ""
+  ul li
+    display: inline-block
+    span.active
+      color: $yellow
+  ul li > *
+    padding: 2px $unit
+    border: solid
+#previous_articles
+  float: left
+  text-align: left
+#next_articles
+  float: right
+  text-align: right
+.corps
+  padding-bottom: 2*$unit
+
+#tagcloud
+  margin: $unit $hmargin
+  font-size: 14px
+  line-height: 21px
+#sousliens.archive > ul
+  display: none
+#sousliens.archive > h4:hover
+  cursor: pointer
+#hiddenDivs > div
+  display: none
+.list
+  margin: $unit $hmargin
+#content img#mainlogo
+  width: auto
+  margin: 0 auto
+  display: block
+  max-width: 100%
+.date, .day, .month, .year
+  display: inline-block
+  padding-left: 10px
+  text-align: right
+.day
+  width: 10px
+.month
+  width: 20px
+.year
+  width: 30px
+.date
+  margin-right: 10px
+
+.popularblock
+  display: block
+  float: left
+  margin: 1.5%
+  width: 30%
+  figure
+    width: 100%
+    height: 120px
+    overflow: hidden
+    figcaption
+      display: none
+

content/html/en/blog/Category-Theory-Programming.md

@@ -1,227 +0,0 @@
------
-isHidden:       false
-menupriority:   1
-kind:           article
-created_at:     2012-10-01T19:16:43+02:00
-title: Category Theory Programming
-author_name: Yann Esposito
-author_uri: yannesposito.com
-tags:
-  - Haskell
-  - programming
-  - functional
-  - category theory
------
-
-begindiv(intro)
-
-%tldr How to program using category theory.
-
-> <center><hr style="width:30%;float:left;border-color:#CCCCD0;margin-top:1em"/><span class="sc"><b>Table of Content</b></span><hr style="width:30%;float:right;border-color:#CCCCD0;margin-top:1em"/></center>
-> 
-> * This will be replaced by the ToC
-> {:toc}
->
-
-enddiv
-
-## Introduction
-
-%TODO{Do everything after the end}
-
-Now, it is time to talk about Categories.
-How this notion could help you and how it is easy to use with Haskell.
-
-- What are categories?
-- How to use them?
-
-### Programming Paradigms
-
-When you program, you resolve problems.
-There are a lot of different means to resolve a problem.
-Many different "school of thought"[^school] exists.
-
-[^school]: Écoles de pensées
-
-**Imperative paradigm**:
-In programming, most people use the imperative paradigm.
-You have an infinite number of cell and you can write things on them.
-Of course, it is more complex with modern architecture, but the paradigm is the same.
-Hidden somewhere, there is the model of the Turing machine.
-
-**Functional paradigm**:
-Another paradigm, is the functional paradigm.
-This time, you don't write on cells, but instead you have a flow of data.
-And you transform the flows in another flows... Mostly it looks like pipes.
-I am a bit restrictive here. But generally this is how functional programming is perceived.
-The main theory behind this paradigm is the Set theory.
-You have a set and you go from one set to another set by using a function.
-
-**Category paradigm**:
-I believe there is another paradigm arising from Category theory.
-Category theory feels both more general and powerful to help solve problems.
-
-First, you must realize there are categories everywhere.
-With the category theory you can find relationships between quantum physics,
-topology, logic (both predicate and first order), programming.
-Most of the time, the object your are programming with will form a category.
-
-This is the promise from the Category Theory.
-Another even better paradigm.
-A paradigm with gates between many different domains.
-
-## Get some intuition
-
-We write down the definition first.
-And will discuss about some categories.
-
-<div style="display:none">
-\\( \newcommand{\hom}{\mathrm{hom}} \\)
-</div>
-
- > **Definition**:
- >
- > A category \\(C\\) consist of:
- >
- > - A collection of _objects_ \\(ob(C)\\)
- > - For every pair of objects \\((A,B)\\) a set \\(\hom(A,B)\\)
- >   of _morphisms_ \\(f:A→B\\) (Another notation for \\(f\in \hom(A,B)\\))
- > - A composition operator \\(∘\\)
- >   which associate to each couple \\(g:A→B\\), \\(f:B→C\\) another morphism \\(f∘g:A→C\\).
- >
- > With the following properties
- >
- > - for each object \\(x\\) there is an identity morphism  
- >   \\(id_x:x→x\\)  
- >   s.t. for any morphism \\(f:A->B\\),  
- >   \\(id_A∘f = f = f∘id_B\\)
- > - for all triplet of morphisms \\(h:A->B\\), \\(g:B->C\\) and \\(f:C->D\\)  
- >   \\( (f∘g)∘h = f∘(g∘h) \\)
-
-### Representation of Category
-
-Representing Category is not just a game.
-It will be _very_ important.
-But in the same time, it will help you to gain intuition about categories.
-
-A naïve representation (which can work in many cases) is to represent
-a specific category as a directed graph.
-Here is a first example of the representation of a category:
-
-<graph title="First Naïve Category Representation">
-
-A -> B [label="f"]
-B -> C [label="g"]
-A -> C [label="h"]
-
-A -> A [label="idA"]
-B -> B [label="idB"]
-C -> C [label="idC"]
-
-</graph>
-
-From this graph we can conclude without any ambiguity that:
-
-\\[ob(C)=\\{A,B,C\\}\\]
-and
-\\[\hom(C)=\\{f,g,h,idA,idB,idC\\}\\]
-
-Instantaneously, we understand that we can get rid of all \\(idX\\) arrows.
-
-But in reality, we lack an important information.
-What is \\(∘\\)?
-
-Now, we can add informations to our previous representation.
-We simply add a relation between 3 arrows that represent the composition.
-
-<graph title="Naïve Category Representation">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-fg      [label="", fixedsize="false", width=0,height=0,shape=none];
-AC      [label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [label="h=g∘f",fontcolor="#b58900",color="#b58900",style=bold]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-</graph>
-
-Now we have a complete representation.
-We don't have to represent \\(idX\\), we know there are there.
-And we also don't have to represent composition implying \\(idX\\) morphisms.
-But, even this little graph look complex.
-To show just how complex things can be;
-we just double the number morphisms between different objects.
-
-<graph title="Naïve Category Representation Mess">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-fp[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> fp[label="f'", arrowhead=None]
-fp -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-gp[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> gp[label="g'", arrowhead=None]
-gp -> C
-
-fg[label="", fixedsize="false", width=0,height=0,shape=none];
-fpg[label="", fixedsize="false", width=0,height=0,shape=none];
-fgp[label="", fixedsize="false", width=0,height=0,shape=none];
-fpgp[label="", fixedsize="false", width=0,height=0,shape=none];
-AC[label="", fixedsize="false", width=0,height=0,shape=none];
-ApCp[label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [color="#b58900",style=bold,fontcolor="#b58900",label="h=g∘f"]
-
-fp -> fpgp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> gp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> AC [color="#d33682",style=bold,fontcolor="#d33682",label="h=g'∘f'"]
-
-fp -> fpg   [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> g    [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> ApCp [color="#dc322f",style=bold,fontcolor="#dc322f",label="h'=g∘f'"]
-
-f -> fgp    [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> gp   [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> ApCp [color="#268bd2",style=bold,fontcolor="#268bd2",label="h'=g'∘f"]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-A -> ApCp [label="h'",arrowhead=None]
-ApCp -> C
-
-</graph>
-
-In fact we could have made something equivalent and far easier to read.
-But the ∘ relation will be more hidden.
-
-<graph title="Less Graphic Category Representation">
-
-A -> B[label="f"]
-A -> B[label="f'"]
-B -> C[label="g"]
-B -> C[label="g'"]
-A -> C [label="h\n=g∘f\n=g'∘f'"]
-A -> C [label="h'\n=g'∘f\n=g∘f'"]
-
-</graph>

content/html/fr/blog/Category-Theory-Programming.md

@@ -1,227 +0,0 @@
------
-isHidden:       false
-menupriority:   1
-kind:           article
-created_at:     2012-10-01T19:16:43+02:00
-title: Programmation en Théorie des Catégories
-author_name: Yann Esposito
-author_uri: yannesposito.com
-tags:
-  - Haskell
-  - programming
-  - functional
-  - category theory
------
-
-begindiv(intro)
-
-%tlal Comment programmer en utilisant la théorie des catégories.
-
-> <center><hr style="width:30%;float:left;border-color:#CCCCD0;margin-top:1em"/><span class="sc"><b>Table of Content</b></span><hr style="width:30%;float:right;border-color:#CCCCD0;margin-top:1em"/></center>
-> 
-> * This will be replaced by the ToC
-> {:toc}
->
-
-enddiv
-
-## Introduction
-
-%TODO{Do everything after the end}
-
-Now, it is time to talk about Categories.
-How this notion could help you and how it is easy to use with Haskell.
-
-- What are categories?
-- How to use them?
-
-### Programming Paradigms
-
-When you program, you resolve problems.
-There are a lot of different means to resolve a problem.
-Many different "school of thought"[^school] exists.
-
-[^school]: Écoles de pensées
-
-**Imperative paradigm**:
-In programming, most people use the imperative paradigm.
-You have an infinite number of cell and you can write things on them.
-Of course, it is more complex with modern architecture, but the paradigm is the same.
-Hidden somewhere, there is the model of the Turing machine.
-
-**Functional paradigm**:
-Another paradigm, is the functional paradigm.
-This time, you don't write on cells, but instead you have a flow of data.
-And you transform the flows in another flows... Mostly it looks like pipes.
-I am a bit restrictive here. But generally this is how functional programming is perceived.
-The main theory behind this paradigm is the Set theory.
-You have a set and you go from one set to another set by using a function.
-
-**Category paradigm**:
-I believe there is another paradigm arising from Category theory.
-Category theory feels both more general and powerful to help solve problems.
-
-First, you must realize there are categories everywhere.
-With the category theory you can find relationships between quantum physics,
-topology, logic (both predicate and first order), programming.
-Most of the time, the object your are programming with will form a category.
-
-This is the promise from the Category Theory.
-Another even better paradigm.
-A paradigm with gates between many different domains.
-
-## Get some intuition
-
-We write down the definition first.
-And will discuss about some categories.
-
-<div style="display:none">
-\\( \newcommand{\hom}{\mathrm{hom}} \\)
-</div>
-
- > **Definition**:
- >
- > A category \\(C\\) consist of:
- >
- > - A collection of _objects_ \\(ob(C)\\)
- > - For every pair of objects \\((A,B)\\) a set \\(\hom(A,B)\\)
- >   of _morphisms_ \\(f:A→B\\) (Another notation for \\(f\in \hom(A,B)\\))
- > - A composition operator \\(∘\\)
- >   which associate to each couple \\(g:A→B\\), \\(f:B→C\\) another morphism \\(f∘g:A→C\\).
- >
- > With the following properties
- >
- > - for each object \\(x\\) there is an identity morphism  
- >   \\(id_x:x→x\\)  
- >   s.t. for any morphism \\(f:A->B\\),  
- >   \\(id_A∘f = f = f∘id_B\\)
- > - for all triplet of morphisms \\(h:A->B\\), \\(g:B->C\\) and \\(f:C->D\\)  
- >   \\( (f∘g)∘h = f∘(g∘h) \\)
-
-### Representation of Category
-
-Representing Category is not just a game.
-It will be _very_ important.
-But in the same time, it will help you to gain intuition about categories.
-
-A naïve representation (which can work in many cases) is to represent
-a specific category as a directed graph.
-Here is a first example of the representation of a category:
-
-<graph title="First Naïve Category Representation">
-
-A -> B [label="f"]
-B -> C [label="g"]
-A -> C [label="h"]
-
-A -> A [label="idA"]
-B -> B [label="idB"]
-C -> C [label="idC"]
-
-</graph>
-
-From this graph we can conclude without any ambiguity that:
-
-\\[ob(C)=\\{A,B,C\\}\\]
-and
-\\[\hom(C)=\\{f,g,h,idA,idB,idC\\}\\]
-
-Instantaneously, we understand that we can get rid of all \\(idX\\) arrows.
-
-But in reality, we lack an important information.
-What is \\(∘\\)?
-
-Now, we can add informations to our previous representation.
-We simply add a relation between 3 arrows that represent the composition.
-
-<graph title="Naïve Category Representation">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-fg      [label="", fixedsize="false", width=0,height=0,shape=none];
-AC      [label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [label="h=g∘f",fontcolor="#b58900",color="#b58900",style=bold]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-</graph>
-
-Now we have a complete representation.
-We don't have to represent \\(idX\\), we know there are there.
-And we also don't have to represent composition implying \\(idX\\) morphisms.
-But, even this little graph look complex.
-To show just how complex things can be;
-we just double the number morphisms between different objects.
-
-<graph title="Naïve Category Representation Mess">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-fp[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> fp[label="f'", arrowhead=None]
-fp -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-gp[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> gp[label="g'", arrowhead=None]
-gp -> C
-
-fg[label="", fixedsize="false", width=0,height=0,shape=none];
-fpg[label="", fixedsize="false", width=0,height=0,shape=none];
-fgp[label="", fixedsize="false", width=0,height=0,shape=none];
-fpgp[label="", fixedsize="false", width=0,height=0,shape=none];
-AC[label="", fixedsize="false", width=0,height=0,shape=none];
-ApCp[label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [color="#b58900",style=bold,fontcolor="#b58900",label="h=g∘f"]
-
-fp -> fpgp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> gp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> AC [color="#d33682",style=bold,fontcolor="#d33682",label="h=g'∘f'"]
-
-fp -> fpg   [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> g    [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> ApCp [color="#dc322f",style=bold,fontcolor="#dc322f",label="h'=g∘f'"]
-
-f -> fgp    [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> gp   [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> ApCp [color="#268bd2",style=bold,fontcolor="#268bd2",label="h'=g'∘f"]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-A -> ApCp [label="h'",arrowhead=None]
-ApCp -> C
-
-</graph>
-
-In fact we could have made something equivalent and far easier to read.
-But the ∘ relation will be more hidden.
-
-<graph title="Less Graphic Category Representation">
-
-A -> B[label="f"]
-A -> B[label="f'"]
-B -> C[label="g"]
-B -> C[label="g'"]
-A -> C [label="h\n=g∘f\n=g'∘f'"]
-A -> C [label="h'\n=g'∘f\n=g∘f'"]
-
-</graph>

multi/blog/Category-Theory-Programming.md

@@ -1,229 +0,0 @@
------
-isHidden:       false
-menupriority:   1
-kind:           article
-created_at:     2012-10-01T19:16:43+02:00
-en: title: Category Theory Programming
-fr: title: Programmation en Théorie des Catégories
-author_name: Yann Esposito
-author_uri: yannesposito.com
-tags:
-  - Haskell
-  - programming
-  - functional
-  - category theory
------
-
-begindiv(intro)
-
-en: %tldr How to program using category theory.
-fr: %tlal Comment programmer en utilisant la théorie des catégories.
-
-> <center><hr style="width:30%;float:left;border-color:#CCCCD0;margin-top:1em"/><span class="sc"><b>Table of Content</b></span><hr style="width:30%;float:right;border-color:#CCCCD0;margin-top:1em"/></center>
-> 
-> * This will be replaced by the ToC
-> {:toc}
->
-
-enddiv
-
-## Introduction
-
-%TODO{Do everything after the end}
-
-Now, it is time to talk about Categories.
-How this notion could help you and how it is easy to use with Haskell.
-
-- What are categories?
-- How to use them?
-
-### Programming Paradigms
-
-When you program, you resolve problems.
-There are a lot of different means to resolve a problem.
-Many different "school of thought"[^school] exists.
-
-[^school]: Écoles de pensées
-
-**Imperative paradigm**:
-In programming, most people use the imperative paradigm.
-You have an infinite number of cell and you can write things on them.
-Of course, it is more complex with modern architecture, but the paradigm is the same.
-Hidden somewhere, there is the model of the Turing machine.
-
-**Functional paradigm**:
-Another paradigm, is the functional paradigm.
-This time, you don't write on cells, but instead you have a flow of data.
-And you transform the flows in another flows... Mostly it looks like pipes.
-I am a bit restrictive here. But generally this is how functional programming is perceived.
-The main theory behind this paradigm is the Set theory.
-You have a set and you go from one set to another set by using a function.
-
-**Category paradigm**:
-I believe there is another paradigm arising from Category theory.
-Category theory feels both more general and powerful to help solve problems.
-
-First, you must realize there are categories everywhere.
-With the category theory you can find relationships between quantum physics,
-topology, logic (both predicate and first order), programming.
-Most of the time, the object your are programming with will form a category.
-
-This is the promise from the Category Theory.
-Another even better paradigm.
-A paradigm with gates between many different domains.
-
-## Get some intuition
-
-We write down the definition first.
-And will discuss about some categories.
-
-<div style="display:none">
-\\( \newcommand{\hom}{\mathrm{hom}} \\)
-</div>
-
- > **Definition**:
- >
- > A category \\(C\\) consist of:
- >
- > - A collection of _objects_ \\(ob(C)\\)
- > - For every pair of objects \\((A,B)\\) a set \\(\hom(A,B)\\)
- >   of _morphisms_ \\(f:A→B\\) (Another notation for \\(f\in \hom(A,B)\\))
- > - A composition operator \\(∘\\)
- >   which associate to each couple \\(g:A→B\\), \\(f:B→C\\) another morphism \\(f∘g:A→C\\).
- >
- > With the following properties
- >
- > - for each object \\(x\\) there is an identity morphism  
- >   \\(id_x:x→x\\)  
- >   s.t. for any morphism \\(f:A->B\\),  
- >   \\(id_A∘f = f = f∘id_B\\)
- > - for all triplet of morphisms \\(h:A->B\\), \\(g:B->C\\) and \\(f:C->D\\)  
- >   \\( (f∘g)∘h = f∘(g∘h) \\)
-
-### Representation of Category
-
-Representing Category is not just a game.
-It will be _very_ important.
-But in the same time, it will help you to gain intuition about categories.
-
-A naïve representation (which can work in many cases) is to represent
-a specific category as a directed graph.
-Here is a first example of the representation of a category:
-
-<graph title="First Naïve Category Representation">
-
-A -> B [label="f"]
-B -> C [label="g"]
-A -> C [label="h"]
-
-A -> A [label="idA"]
-B -> B [label="idB"]
-C -> C [label="idC"]
-
-</graph>
-
-From this graph we can conclude without any ambiguity that:
-
-\\[ob(C)=\\{A,B,C\\}\\]
-and
-\\[\hom(C)=\\{f,g,h,idA,idB,idC\\}\\]
-
-Instantaneously, we understand that we can get rid of all \\(idX\\) arrows.
-
-But in reality, we lack an important information.
-What is \\(∘\\)?
-
-Now, we can add informations to our previous representation.
-We simply add a relation between 3 arrows that represent the composition.
-
-<graph title="Naïve Category Representation">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-fg      [label="", fixedsize="false", width=0,height=0,shape=none];
-AC      [label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [label="h=g∘f",fontcolor="#b58900",color="#b58900",style=bold]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-</graph>
-
-Now we have a complete representation.
-We don't have to represent \\(idX\\), we know there are there.
-And we also don't have to represent composition implying \\(idX\\) morphisms.
-But, even this little graph look complex.
-To show just how complex things can be;
-we just double the number morphisms between different objects.
-
-<graph title="Naïve Category Representation Mess">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-fp[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> fp[label="f'", arrowhead=None]
-fp -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-gp[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> gp[label="g'", arrowhead=None]
-gp -> C
-
-fg[label="", fixedsize="false", width=0,height=0,shape=none];
-fpg[label="", fixedsize="false", width=0,height=0,shape=none];
-fgp[label="", fixedsize="false", width=0,height=0,shape=none];
-fpgp[label="", fixedsize="false", width=0,height=0,shape=none];
-AC[label="", fixedsize="false", width=0,height=0,shape=none];
-ApCp[label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [color="#b58900",style=bold,fontcolor="#b58900",label="h=g∘f"]
-
-fp -> fpgp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> gp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> AC [color="#d33682",style=bold,fontcolor="#d33682",label="h=g'∘f'"]
-
-fp -> fpg   [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> g    [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> ApCp [color="#dc322f",style=bold,fontcolor="#dc322f",label="h'=g∘f'"]
-
-f -> fgp    [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> gp   [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> ApCp [color="#268bd2",style=bold,fontcolor="#268bd2",label="h'=g'∘f"]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-A -> ApCp [label="h'",arrowhead=None]
-ApCp -> C
-
-</graph>
-
-In fact we could have made something equivalent and far easier to read.
-But the ∘ relation will be more hidden.
-
-<graph title="Less Graphic Category Representation">
-
-A -> B[label="f"]
-A -> B[label="f'"]
-B -> C[label="g"]
-B -> C[label="g'"]
-A -> C [label="h\n=g∘f\n=g'∘f'"]
-A -> C [label="h'\n=g'∘f\n=g∘f'"]
-
-</graph>

output/Scratch/en/blog/Category-Theory-Programming/code/00_Introduction.lhs

@@ -1,203 +0,0 @@
- ## Introduction
-
-%TODO{Do everything after the end}
-
-Now, it is time to talk about Categories.
-How this notion could help you and how it is easy to use with Haskell.
-
-- What are categories?
-- How to use them?
-
- ### Programming Paradigms
-
-When you program, you resolve problems.
-There are a lot of different means to resolve a problem.
-Many different "school of thought"[^school] exists.
-
-[^school]: Écoles de pensées
-
-**Imperative paradigm**:
-In programming, most people use the imperative paradigm.
-You have an infinite number of cell and you can write things on them.
-Of course, it is more complex with modern architecture, but the paradigm is the same.
-Hidden somewhere, there is the model of the Turing machine.
-
-**Functional paradigm**:
-Another paradigm, is the functional paradigm.
-This time, you don't write on cells, but instead you have a flow of data.
-And you transform the flows in another flows... Mostly it looks like pipes.
-I am a bit restrictive here. But generally this is how functional programming is perceived.
-The main theory behind this paradigm is the Set theory.
-You have a set and you go from one set to another set by using a function.
-
-**Category paradigm**:
-I believe there is another paradigm arising from Category theory.
-Category theory feels both more general and powerful to help solve problems.
-
-First, you must realize there are categories everywhere.
-With the category theory you can find relationships between quantum physics,
-topology, logic (both predicate and first order), programming.
-Most of the time, the object your are programming with will form a category.
-
-This is the promise from the Category Theory.
-Another even better paradigm.
-A paradigm with gates between many different domains.
-
- ## Get some intuition
-
-We write down the definition first.
-And will discuss about some categories.
-
-<div style="display:none">
-\\( \newcommand{\hom}{\mathrm{hom}} \\)
-</div>
-
- > **Definition**:
- >
- > A category \\(C\\) consist of:
- >
- > - A collection of _objects_ \\(ob(C)\\)
- > - For every pair of objects \\((A,B)\\) a set \\(\hom(A,B)\\)
- >   of _morphisms_ \\(f:A→B\\) (Another notation for \\(f\in \hom(A,B)\\))
- > - A composition operator \\(∘\\)
- >   which associate to each couple \\(g:A→B\\), \\(f:B→C\\) another morphism \\(f∘g:A→C\\).
- >
- > With the following properties
- >
- > - for each object \\(x\\) there is an identity morphism  
- >   \\(id_x:x→x\\)  
- >   s.t. for any morphism \\(f:A->B\\),  
- >   \\(id_A∘f = f = f∘id_B\\)
- > - for all triplet of morphisms \\(h:A->B\\), \\(g:B->C\\) and \\(f:C->D\\)  
- >   \\( (f∘g)∘h = f∘(g∘h) \\)
-
- ### Representation of Category
-
-Representing Category is not just a game.
-It will be _very_ important.
-But in the same time, it will help you to gain intuition about categories.
-
-A naïve representation (which can work in many cases) is to represent
-a specific category as a directed graph.
-Here is a first example of the representation of a category:
-
-<graph title="First Naïve Category Representation">
-
-A -> B [label="f"]
-B -> C [label="g"]
-A -> C [label="h"]
-
-A -> A [label="idA"]
-B -> B [label="idB"]
-C -> C [label="idC"]
-
-</graph>
-
-From this graph we can conclude without any ambiguity that:
-
-\\[ob(C)=\\{A,B,C\\}\\]
-and
-\\[\hom(C)=\\{f,g,h,idA,idB,idC\\}\\]
-
-Instantaneously, we understand that we can get rid of all \\(idX\\) arrows.
-
-But in reality, we lack an important information.
-What is \\(∘\\)?
-
-Now, we can add informations to our previous representation.
-We simply add a relation between 3 arrows that represent the composition.
-
-<graph title="Naïve Category Representation">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-
-fg      [label="", fixedsize="false", width=0,height=0,shape=none];
-AC      [label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [label="h=g∘f",fontcolor="#b58900",color="#b58900",style=bold]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-
-</graph>
-
-Now we have a complete representation.
-We don't have to represent \\(idX\\), we know there are there.
-And we also don't have to represent composition implying \\(idX\\) morphisms.
-But, even this little graph look complex.
-To show just how complex things can be;
-we just double the number morphisms between different objects.
-
-<graph title="Naïve Category Representation Mess">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-fp[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> fp[label="f'", arrowhead=None]
-fp -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-gp[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> gp[label="g'", arrowhead=None]
-gp -> C
-
-fg[label="", fixedsize="false", width=0,height=0,shape=none];
-fpg[label="", fixedsize="false", width=0,height=0,shape=none];
-fgp[label="", fixedsize="false", width=0,height=0,shape=none];
-fpgp[label="", fixedsize="false", width=0,height=0,shape=none];
-AC[label="", fixedsize="false", width=0,height=0,shape=none];
-ApCp[label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [color="#b58900",style=bold,fontcolor="#b58900",label="h=g∘f"]
-
-fp -> fpgp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> gp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> AC [color="#d33682",style=bold,fontcolor="#d33682",label="h=g'∘f'"]
-
-fp -> fpg   [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> g    [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> ApCp [color="#dc322f",style=bold,fontcolor="#dc322f",label="h'=g∘f'"]
-
-f -> fgp    [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> gp   [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> ApCp [color="#268bd2",style=bold,fontcolor="#268bd2",label="h'=g'∘f"]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-A -> ApCp [label="h'",arrowhead=None]
-ApCp -> C
-
-
-</graph>
-
-In fact we could have made something equivalent and far easier to read.
-But the ∘ relation will be more hidden.
-
-<graph title="Less Graphic Category Representation">
-
-A -> B[label="f"]
-A -> B[label="f'"]
-B -> C[label="g"]
-B -> C[label="g'"]
-A -> C [label="h\n=g∘f\n=g'∘f'"]
-A -> C [label="h'\n=g'∘f\n=g∘f'"]
-
-</graph>

output/Scratch/fr/blog/Category-Theory-Programming/code/00_Introduction.lhs

@@ -1,203 +0,0 @@
- ## Introduction
-
-%TODO{Do everything after the end}
-
-Now, it is time to talk about Categories.
-How this notion could help you and how it is easy to use with Haskell.
-
-- What are categories?
-- How to use them?
-
- ### Programming Paradigms
-
-When you program, you resolve problems.
-There are a lot of different means to resolve a problem.
-Many different "school of thought"[^school] exists.
-
-[^school]: Écoles de pensées
-
-**Imperative paradigm**:
-In programming, most people use the imperative paradigm.
-You have an infinite number of cell and you can write things on them.
-Of course, it is more complex with modern architecture, but the paradigm is the same.
-Hidden somewhere, there is the model of the Turing machine.
-
-**Functional paradigm**:
-Another paradigm, is the functional paradigm.
-This time, you don't write on cells, but instead you have a flow of data.
-And you transform the flows in another flows... Mostly it looks like pipes.
-I am a bit restrictive here. But generally this is how functional programming is perceived.
-The main theory behind this paradigm is the Set theory.
-You have a set and you go from one set to another set by using a function.
-
-**Category paradigm**:
-I believe there is another paradigm arising from Category theory.
-Category theory feels both more general and powerful to help solve problems.
-
-First, you must realize there are categories everywhere.
-With the category theory you can find relationships between quantum physics,
-topology, logic (both predicate and first order), programming.
-Most of the time, the object your are programming with will form a category.
-
-This is the promise from the Category Theory.
-Another even better paradigm.
-A paradigm with gates between many different domains.
-
- ## Get some intuition
-
-We write down the definition first.
-And will discuss about some categories.
-
-<div style="display:none">
-\\( \newcommand{\hom}{\mathrm{hom}} \\)
-</div>
-
- > **Definition**:
- >
- > A category \\(C\\) consist of:
- >
- > - A collection of _objects_ \\(ob(C)\\)
- > - For every pair of objects \\((A,B)\\) a set \\(\hom(A,B)\\)
- >   of _morphisms_ \\(f:A→B\\) (Another notation for \\(f\in \hom(A,B)\\))
- > - A composition operator \\(∘\\)
- >   which associate to each couple \\(g:A→B\\), \\(f:B→C\\) another morphism \\(f∘g:A→C\\).
- >
- > With the following properties
- >
- > - for each object \\(x\\) there is an identity morphism  
- >   \\(id_x:x→x\\)  
- >   s.t. for any morphism \\(f:A->B\\),  
- >   \\(id_A∘f = f = f∘id_B\\)
- > - for all triplet of morphisms \\(h:A->B\\), \\(g:B->C\\) and \\(f:C->D\\)  
- >   \\( (f∘g)∘h = f∘(g∘h) \\)
-
- ### Representation of Category
-
-Representing Category is not just a game.
-It will be _very_ important.
-But in the same time, it will help you to gain intuition about categories.
-
-A naïve representation (which can work in many cases) is to represent
-a specific category as a directed graph.
-Here is a first example of the representation of a category:
-
-<graph title="First Naïve Category Representation">
-
-A -> B [label="f"]
-B -> C [label="g"]
-A -> C [label="h"]
-
-A -> A [label="idA"]
-B -> B [label="idB"]
-C -> C [label="idC"]
-
-</graph>
-
-From this graph we can conclude without any ambiguity that:
-
-\\[ob(C)=\\{A,B,C\\}\\]
-and
-\\[\hom(C)=\\{f,g,h,idA,idB,idC\\}\\]
-
-Instantaneously, we understand that we can get rid of all \\(idX\\) arrows.
-
-But in reality, we lack an important information.
-What is \\(∘\\)?
-
-Now, we can add informations to our previous representation.
-We simply add a relation between 3 arrows that represent the composition.
-
-<graph title="Naïve Category Representation">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-
-fg      [label="", fixedsize="false", width=0,height=0,shape=none];
-AC      [label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [label="h=g∘f",fontcolor="#b58900",color="#b58900",style=bold]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-
-</graph>
-
-Now we have a complete representation.
-We don't have to represent \\(idX\\), we know there are there.
-And we also don't have to represent composition implying \\(idX\\) morphisms.
-But, even this little graph look complex.
-To show just how complex things can be;
-we just double the number morphisms between different objects.
-
-<graph title="Naïve Category Representation Mess">
-
-f[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> f[label="f", arrowhead=None]
-f -> B
-
-fp[label="", fixedsize="false", width=0,height=0,shape=none];
-A -> fp[label="f'", arrowhead=None]
-fp -> B
-
-g[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> g[label="g", arrowhead=None]
-g -> C
-
-gp[label="", fixedsize="false", width=0,height=0,shape=none];
-B -> gp[label="g'", arrowhead=None]
-gp -> C
-
-fg[label="", fixedsize="false", width=0,height=0,shape=none];
-fpg[label="", fixedsize="false", width=0,height=0,shape=none];
-fgp[label="", fixedsize="false", width=0,height=0,shape=none];
-fpgp[label="", fixedsize="false", width=0,height=0,shape=none];
-AC[label="", fixedsize="false", width=0,height=0,shape=none];
-ApCp[label="", fixedsize="false", width=0,height=0,shape=none];
-
-f -> fg  [color="#b58900",style=dashed,arrowhead=None]
-fg -> g  [color="#b58900",style=dashed,arrowhead=None]
-fg -> AC [color="#b58900",style=bold,fontcolor="#b58900",label="h=g∘f"]
-
-fp -> fpgp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> gp [color="#d33682",style=dashed,arrowhead=None]
-fpgp -> AC [color="#d33682",style=bold,fontcolor="#d33682",label="h=g'∘f'"]
-
-fp -> fpg   [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> g    [color="#dc322f",style=dashed,arrowhead=None]
-fpg -> ApCp [color="#dc322f",style=bold,fontcolor="#dc322f",label="h'=g∘f'"]
-
-f -> fgp    [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> gp   [color="#268bd2",style=dashed,arrowhead=None]
-fgp -> ApCp [color="#268bd2",style=bold,fontcolor="#268bd2",label="h'=g'∘f"]
-
-A -> AC [label="h",arrowhead=None]
-AC -> C
-
-A -> ApCp [label="h'",arrowhead=None]
-ApCp -> C
-
-
-</graph>
-
-In fact we could have made something equivalent and far easier to read.
-But the ∘ relation will be more hidden.
-
-<graph title="Less Graphic Category Representation">
-
-A -> B[label="f"]
-A -> B[label="f'"]
-B -> C[label="g"]
-B -> C[label="g'"]
-A -> C [label="h\n=g∘f\n=g'∘f'"]
-A -> C [label="h'\n=g'∘f\n=g∘f'"]
-
-</graph>