diff --git a/Rules b/Rules index 3778cec1a..8566eb092 100644 --- a/Rules +++ b/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 diff --git a/content/css/main2.sass b/content/css/main2.sass index 6ebdeb967..f1007dc7d 100644 --- a/content/css/main2.sass +++ b/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 + diff --git a/content/html/en/blog/Category-Theory-Programming.md b/content/html/en/blog/Category-Theory-Programming.md deleted file mode 100644 index 2f91185e3..000000000 --- a/content/html/en/blog/Category-Theory-Programming.md +++ /dev/null @@ -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. - ->
Table of Content
-> -> * 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. - -
-\\( \newcommand{\hom}{\mathrm{hom}} \\) -
- - > **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: - - - -A -> B [label="f"] -B -> C [label="g"] -A -> C [label="h"] - -A -> A [label="idA"] -B -> B [label="idB"] -C -> C [label="idC"] - - - -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. - - - -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 - - - -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. - - - -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 - - - -In fact we could have made something equivalent and far easier to read. -But the ∘ relation will be more hidden. - - - -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'"] - - diff --git a/content/html/fr/blog/Category-Theory-Programming.md b/content/html/fr/blog/Category-Theory-Programming.md deleted file mode 100644 index 7e78a005c..000000000 --- a/content/html/fr/blog/Category-Theory-Programming.md +++ /dev/null @@ -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. - ->
Table of Content
-> -> * 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. - -
-\\( \newcommand{\hom}{\mathrm{hom}} \\) -
- - > **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: - - - -A -> B [label="f"] -B -> C [label="g"] -A -> C [label="h"] - -A -> A [label="idA"] -B -> B [label="idB"] -C -> C [label="idC"] - - - -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. - - - -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 - - - -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. - - - -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 - - - -In fact we could have made something equivalent and far easier to read. -But the ∘ relation will be more hidden. - - - -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'"] - - diff --git a/multi/blog/Category-Theory-Programming.md b/multi/blog/Category-Theory-Programming.md deleted file mode 100644 index e4d6a8e7f..000000000 --- a/multi/blog/Category-Theory-Programming.md +++ /dev/null @@ -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. - ->
Table of Content
-> -> * 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. - -
-\\( \newcommand{\hom}{\mathrm{hom}} \\) -
- - > **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: - - - -A -> B [label="f"] -B -> C [label="g"] -A -> C [label="h"] - -A -> A [label="idA"] -B -> B [label="idB"] -C -> C [label="idC"] - - - -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. - - - -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 - - - -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. - - - -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 - - - -In fact we could have made something equivalent and far easier to read. -But the ∘ relation will be more hidden. - - - -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'"] - - diff --git a/output/Scratch/en/blog/Category-Theory-Programming/code/00_Introduction.lhs b/output/Scratch/en/blog/Category-Theory-Programming/code/00_Introduction.lhs deleted file mode 100644 index 6ba05bc9e..000000000 --- a/output/Scratch/en/blog/Category-Theory-Programming/code/00_Introduction.lhs +++ /dev/null @@ -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. - -
-\\( \newcommand{\hom}{\mathrm{hom}} \\) -
- - > **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: - - - -A -> B [label="f"] -B -> C [label="g"] -A -> C [label="h"] - -A -> A [label="idA"] -B -> B [label="idB"] -C -> C [label="idC"] - - - -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. - - - -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 - - - - -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. - - - -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 - - - - -In fact we could have made something equivalent and far easier to read. -But the ∘ relation will be more hidden. - - - -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'"] - - diff --git a/output/Scratch/en/blog/Category-Theory-Programming/graph/First_Na__ve_Category_Representation.png b/output/Scratch/en/blog/Category-Theory-Programming/graph/First_Na__ve_Category_Representation.png deleted file mode 100644 index a2fd3531b..000000000 Binary files a/output/Scratch/en/blog/Category-Theory-Programming/graph/First_Na__ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/en/blog/Category-Theory-Programming/graph/First_Na_ve_Category_Representation.png b/output/Scratch/en/blog/Category-Theory-Programming/graph/First_Na_ve_Category_Representation.png deleted file mode 100644 index 706f58242..000000000 Binary files a/output/Scratch/en/blog/Category-Theory-Programming/graph/First_Na_ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation.png b/output/Scratch/en/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation.png deleted file mode 100644 index 05a743ad6..000000000 Binary files a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation_Mess.png b/output/Scratch/en/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation_Mess.png deleted file mode 100644 index 6d06918c1..000000000 Binary files a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation_Mess.png and /dev/null differ diff --git a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation.png b/output/Scratch/en/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation.png deleted file mode 100644 index e8a54997f..000000000 Binary files a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation_Mess.png b/output/Scratch/en/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation_Mess.png deleted file mode 100644 index 78a5a27f5..000000000 Binary files a/output/Scratch/en/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation_Mess.png and /dev/null differ diff --git a/output/Scratch/fr/blog/Category-Theory-Programming/code/00_Introduction.lhs b/output/Scratch/fr/blog/Category-Theory-Programming/code/00_Introduction.lhs deleted file mode 100644 index 6ba05bc9e..000000000 --- a/output/Scratch/fr/blog/Category-Theory-Programming/code/00_Introduction.lhs +++ /dev/null @@ -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. - -
-\\( \newcommand{\hom}{\mathrm{hom}} \\) -
- - > **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: - - - -A -> B [label="f"] -B -> C [label="g"] -A -> C [label="h"] - -A -> A [label="idA"] -B -> B [label="idB"] -C -> C [label="idC"] - - - -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. - - - -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 - - - - -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. - - - -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 - - - - -In fact we could have made something equivalent and far easier to read. -But the ∘ relation will be more hidden. - - - -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'"] - - diff --git a/output/Scratch/fr/blog/Category-Theory-Programming/graph/First_Na__ve_Category_Representation.png b/output/Scratch/fr/blog/Category-Theory-Programming/graph/First_Na__ve_Category_Representation.png deleted file mode 100644 index a2fd3531b..000000000 Binary files a/output/Scratch/fr/blog/Category-Theory-Programming/graph/First_Na__ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/fr/blog/Category-Theory-Programming/graph/First_Na_ve_Category_Representation.png b/output/Scratch/fr/blog/Category-Theory-Programming/graph/First_Na_ve_Category_Representation.png deleted file mode 100644 index 706f58242..000000000 Binary files a/output/Scratch/fr/blog/Category-Theory-Programming/graph/First_Na_ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation.png b/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation.png deleted file mode 100644 index 05a743ad6..000000000 Binary files a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation_Mess.png b/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation_Mess.png deleted file mode 100644 index 6d06918c1..000000000 Binary files a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na__ve_Category_Representation_Mess.png and /dev/null differ diff --git a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation.png b/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation.png deleted file mode 100644 index e8a54997f..000000000 Binary files a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation.png and /dev/null differ diff --git a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation_Mess.png b/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation_Mess.png deleted file mode 100644 index 78a5a27f5..000000000 Binary files a/output/Scratch/fr/blog/Category-Theory-Programming/graph/Na_ve_Category_Representation_Mess.png and /dev/null differ