Titles
This commit is contained in:
parent
a1a9c88d5c
commit
81460fbffc
|
|
@ -1 +1 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><link rel="stylesheet" href="/styles/katex.min.css"><script defer src="/scripts/katex.min.js" onload="renderMathInElement(document.body)"></script><title>xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Equality</h1><figure class="quote"><blockquote>In <a href="/wiki/Mathematics" title="Mathematics">mathematics</a>, an <dfn>equivalence relation</dfn> is a <a href="/wiki/Binary_relation" title="Binary relation">binary relation</a> that is <a href="/wiki/Reflexive_relation" title="Reflexive relation">reflexive</a>, <a href="/wiki/Symmetric_relation" title="Symmetric relation">symmetric</a> and <a href="/wiki/Transitive_relation" title="Transitive relation">transitive</a>.</blockquote><figcaption>— <a href="https://en.wikipedia.org/wiki/Equivalence_relation">Wikipedia</a></figcaption></figure><p>Who doesn't want equal rights? Gender equality, racial equality, you name it. However, there seems to be a general disagreement on what “equality” should look like. I'd like to present my viewpoint using the mathematical definition of an <dfn>equivalence relation</dfn>, which is basically a generalized idea of equality.</p><h2>Reflexivity</h2><p><dfn>Reflexivity</dfn> simply means that everything is equal to itself. This is not really relevant when discussing human rights, since the rights of a given group are equal to themselves by nature.</p><h2>Symmetry</h2><p><dfn>Symmetry</dfn> says that if \(x = y\), then \(y = x\). In other words, two equal things are interchangeable. Now this gets more interesting. My interpretation is that if switching the roles of two people/groups wouldn't change their situation regarding what they can do, only then can we say that they have equal rights. Surprisingly, this already seems to be a very controversial opinion. I'll get to concrete examples later.</p><h2>Transitivity</h2><p><dfn>Transitivity</dfn> says that if \(x = y\) and \(y = z\), then also \(x = z\). It's hard to imagine a scenario where this would come relevant in human rights. After all, it involves three variables, but discussions about human rights usually compare the rights of two groups. We'll see if this becomes useful later.</p></body></html>
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><link rel="stylesheet" href="/styles/katex.min.css"><script defer src="/scripts/katex.min.js" onload="renderMathInElement(document.body)"></script><title>Equality | xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Equality</h1><figure class="quote"><blockquote>In <a href="/wiki/Mathematics" title="Mathematics">mathematics</a>, an <dfn>equivalence relation</dfn> is a <a href="/wiki/Binary_relation" title="Binary relation">binary relation</a> that is <a href="/wiki/Reflexive_relation" title="Reflexive relation">reflexive</a>, <a href="/wiki/Symmetric_relation" title="Symmetric relation">symmetric</a> and <a href="/wiki/Transitive_relation" title="Transitive relation">transitive</a>.</blockquote><figcaption>— <a href="https://en.wikipedia.org/wiki/Equivalence_relation">Wikipedia</a></figcaption></figure><p>Who doesn't want equal rights? Gender equality, racial equality, you name it. However, there seems to be a general disagreement on what “equality” should look like. I'd like to present my viewpoint using the mathematical definition of an <dfn>equivalence relation</dfn>, which is basically a generalized idea of equality.</p><h2>Reflexivity</h2><p><dfn>Reflexivity</dfn> simply means that everything is equal to itself. This is not really relevant when discussing human rights, since the rights of a given group are equal to themselves by nature.</p><h2>Symmetry</h2><p><dfn>Symmetry</dfn> says that if \(x = y\), then \(y = x\). In other words, two equal things are interchangeable. Now this gets more interesting. My interpretation is that if switching the roles of two people/groups wouldn't change their situation regarding what they can do, only then can we say that they have equal rights. Surprisingly, this already seems to be a very controversial opinion. I'll get to concrete examples later.</p><h2>Transitivity</h2><p><dfn>Transitivity</dfn> says that if \(x = y\) and \(y = z\), then also \(x = z\). It's hard to imagine a scenario where this would come relevant in human rights. After all, it involves three variables, but discussions about human rights usually compare the rights of two groups. We'll see if this becomes useful later.</p></body></html>
|
||||
|
|
@ -3,6 +3,9 @@ extends templates/main.jade
|
|||
block head
|
||||
include templates/katex.jade
|
||||
|
||||
block title
|
||||
| Equality | xigoi
|
||||
|
||||
block content
|
||||
h1 Equality
|
||||
figure.quote
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Braces Criticism</h1><p>There are, in general, three common ways to delimit code blocks: braces, end-keywords and indentation. When we write pseudocode on paper, we tend to almost always use indentation — it provides an easy visual cue and takes the least effort to write. So why do so many programmers insist on using braces for this purpose, which make code much harder to visually parse? Here are some commonly given reasons with my responses:</p><ul class="qa"><li>Pasting code from the internet messes up the indentation and it's tedious to fix it.</li><li>Are you coding in Windows Notepad?</li><li>A changed indent can cause the code to behave differently.</li><li>When this happens, you'll clearly see it. On the other hand, a misplaced brace might go unnoticed and the indentation will give you a false sense of the code being correct.</li><li>I have auto-indent, so the indentation will always match the braces.</li><li>That's cool. You'll still get slowed down by having to visually process them.</li><li>I don't think invisible characters should change the meaning of code.</li><li>Firstly, indentation is followed by visible characters, which makes you able to clearly see it. Secondly, by this argument, you could also argue that <code>publicstaticvoidmain</code> should be equivalent to <code>public static void main</code> — we're just ignoring “invisible” characters, no?</li><li>Mixing spaces and tabs is going to create a mess.</li><li>See the answer to the first question.</li></ul><h1>Semicolons Criticism</h1><p>A very popular feature in programming languages, especially those derived from <a href="c.html">C</a>, is requiring a semicolon after every statement. Why is this necessary if you're already separating statements by newlines? It just adds one more character you need to type; and more importantly, a lot more characters that you have to visually process, but that don't contribute in any way to the logic of the code (the term for this is <dfn>syntactic noise</dfn>). There's a lot of languages that do completely fine without them: Python, Ruby, Lua, Nim, Go, Haskell, etc. And JavaScript shows that even in a language that uses semicolons, they can be inferred pretty well. Also note that Lua doesn't actually care about newlines, its syntax is made in a way that a statement always ends unambiguously.</p></body></html>
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>Braces & Semicolons | Language Criticism | xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Braces Criticism</h1><p>There are, in general, three common ways to delimit code blocks: braces, end-keywords and indentation. When we write pseudocode on paper, we tend to almost always use indentation — it provides an easy visual cue and takes the least effort to write. So why do so many programmers insist on using braces for this purpose, which make code much harder to visually parse? Here are some commonly given reasons with my responses:</p><ul class="qa"><li>Pasting code from the internet messes up the indentation and it's tedious to fix it.</li><li>Are you coding in Windows Notepad?</li><li>A changed indent can cause the code to behave differently.</li><li>When this happens, you'll clearly see it. On the other hand, a misplaced brace might go unnoticed and the indentation will give you a false sense of the code being correct.</li><li>I have auto-indent, so the indentation will always match the braces.</li><li>That's cool. You'll still get slowed down by having to visually process them.</li><li>I don't think invisible characters should change the meaning of code.</li><li>Firstly, indentation is followed by visible characters, which makes you able to clearly see it. Secondly, by this argument, you could also argue that <code>publicstaticvoidmain</code> should be equivalent to <code>public static void main</code> — we're just ignoring “invisible” characters, no?</li><li>Mixing spaces and tabs is going to create a mess.</li><li>See the answer to the first question.</li></ul><h1>Semicolons Criticism</h1><p>A very popular feature in programming languages, especially those derived from <a href="c.html">C</a>, is requiring a semicolon after every statement. Why is this necessary if you're already separating statements by newlines? It just adds one more character you need to type; and more importantly, a lot more characters that you have to visually process, but that don't contribute in any way to the logic of the code (the term for this is <dfn>syntactic noise</dfn>). There's a lot of languages that do completely fine without them: Python, Ruby, Lua, Nim, Go, Haskell, etc. And JavaScript shows that even in a language that uses semicolons, they can be inferred pretty well. Also note that Lua doesn't actually care about newlines, its syntax is made in a way that a statement always ends unambiguously.</p></body></html>
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
extends ../templates/main.jade
|
||||
|
||||
block title
|
||||
| Braces & Semicolons | Language Criticism | xigoi
|
||||
|
||||
block content
|
||||
h1 Braces Criticism
|
||||
p There are, in general, three common ways to delimit code blocks: braces, end-keywords and indentation. When we write pseudocode on paper, we tend to almost always use indentation — it provides an easy visual cue and takes the least effort to write. So why do so many programmers insist on using braces for this purpose, which make code much harder to visually parse? Here are some commonly given reasons with my responses:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>C Language Criticism</h1><p class="disclaimer">I know that C was designed a long time ago when there wasn't much knowledge about language design. I'm not trying to berate its original creators, I just think it's time to move on to more modern systems programming languages like Nim, Rust or Zig. That's why this criticism is from a modern perspective.</p><p class="notice">I found <a href="https://eev.ee/blog/2016/12/01/lets-stop-copying-c/">this article</a> which explains everything much better than I, so please check it out. I'm leaving my original rant here because why not.</p><h2>Preprocessor</h2><p>What's a better way of doing imports and macros than embedding another language with completely different syntax, which does naive text substitution, into your language? In order to avoid dangers which are not present in any sane import/macro systems, you have to do ugly hacks such as:</p><ul><li><p>Include guards</p><pre>#ifndef YOU_NEED_TO_MANUALLY_MAKE_SURE_THAT_YOUR_FILE_ISNT_INCLUDED_MULTIPLE_TIMES
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>C | Language Criticism | xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>C Language Criticism</h1><p class="disclaimer">I know that C was designed a long time ago when there wasn't much knowledge about language design. I'm not trying to berate its original creators, I just think it's time to move on to more modern systems programming languages like Nim, Rust or Zig. That's why this criticism is from a modern perspective.</p><p class="notice">I found <a href="https://eev.ee/blog/2016/12/01/lets-stop-copying-c/">this article</a> which explains everything much better than I, so please check it out. I'm leaving my original rant here because why not.</p><h2>Preprocessor</h2><p>What's a better way of doing imports and macros than embedding another language with completely different syntax, which does naive text substitution, into your language? In order to avoid dangers which are not present in any sane import/macro systems, you have to do ugly hacks such as:</p><ul><li><p>Include guards</p><pre>#ifndef YOU_NEED_TO_MANUALLY_MAKE_SURE_THAT_YOUR_FILE_ISNT_INCLUDED_MULTIPLE_TIMES
|
||||
#define YOU_NEED_TO_MANUALLY_MAKE_SURE_THAT_YOUR_FILE_ISNT_INCLUDED_MULTIPLE_TIMES
|
||||
// your code here
|
||||
#endif</pre></li><li><p>The <code>do { ... } while (0)</code> thing to make sure that a macro can be used as a normal function</p></li><li><p>Wrapping everything in parentheses to make a macro work like a normal function</p><pre>#define MAX(a, b) ((a) > (b) ? (a) : (b))</pre><p>If any parentheses are left out, it results in counter-intuitive behavior. Actually, even with them it doesn't work like a normal function: the arguments will be evaluated as many times as they're in the macro body!</p></li></ul><h2>Braces & Semicolons</h2><p>See <a href="braces-semicolons.html">Braces & Semicolons</a></p><h2>Syntax inconsistencies & warts</h2><p>Since many other languages (Java, C#, JavaScript, ...) have mindlessly copied most syntax from C, these mistakes have a profound effect on a whole family of languages.</p><ul><li>All control structures that take a statement (if, while, for, switch) have the form of <code>KEYWORD (SOMETHING) STATEMENT</code>. Except for the do-while loop, which for some reason has the form <code>KEYWORD STATEMENT KEYWORD (SOMETHING);</code>. Totally different and including an extra semicolon.<ul class="qa"><li>But it visually indicates that the condition is first checked after the statement!</li><li>Then why is a for loop written as <code>for (INIT; CONDITION; STEP) STATEMENT</code> rather than <code>for (INIT; CONDITION) STATEMENT (STEP);</code>? By the same logic, we should visually indicate that the step (usually increment) is first executed after the statement.</li></ul></li><li>The choice to require an if/while condition to be wrapped in parentheses, rather than requiring the body to be wrapped in braces (as in Rust). Not only does this introduce syntactic noise, but it leads to subtle bugs if you mess up indentation:<pre>if (launch_button_pressed)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
extends ../templates/main.jade
|
||||
|
||||
block title
|
||||
| C | Language Criticism | xigoi
|
||||
|
||||
block content
|
||||
h1 C Language Criticism
|
||||
p.disclaimer
|
||||
|
|
|
|||
|
|
@ -1,2 +1,2 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>C++ Language Criticism</h1><p>Everything that applies to <a href="c.html">C</a> also applies to C++. This article contains only things that don't apply to C.</p><p>The <a href="http://yosefk.com/c++fqa/index.html">C++ FQA</a> has a lot of great points, so go read it too.</p><h2>Syntax</h2><p>C++ took the horrible syntax of C and somehow managed to make it even worse.</p><ul><li>The <a href="https://en.wikipedia.org/wiki/Most_vexing_parse">most vexing parse</a> (and similar rules). I can't fathom what could possibly cause someone to think this is a good idea.</li><li><a href="https://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html">Parsing C++ is literally undecidable.</a></li><li>Using less-than and greater-than signs as brackets, which hinders auto-pairing and complicates parsing while also looking ugly.</li><li>
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>C++ | Language Criticism | xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>C++ Language Criticism</h1><p>Everything that applies to <a href="c.html">C</a> also applies to C++. This article contains only things that don't apply to C.</p><p>The <a href="http://yosefk.com/c++fqa/index.html">C++ FQA</a> has a lot of great points, so go read it too.</p><h2>Syntax</h2><p>C++ took the horrible syntax of C and somehow managed to make it even worse.</p><ul><li>The <a href="https://en.wikipedia.org/wiki/Most_vexing_parse">most vexing parse</a> (and similar rules). I can't fathom what could possibly cause someone to think this is a good idea.</li><li><a href="https://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html">Parsing C++ is literally undecidable.</a></li><li>Using less-than and greater-than signs as brackets, which hinders auto-pairing and complicates parsing while also looking ugly.</li><li>
|
||||
Who decided that <code>::</code> is a good path separator?</li></ul></body></html>
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
extends ../templates/main.jade
|
||||
|
||||
block title
|
||||
| C++ | Language Criticism | xigoi
|
||||
|
||||
block content
|
||||
h1 C++ Language Criticism
|
||||
p
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Language Criticism</h1><p>Here I'm going to criticize all kinds of languages: spoken languages, programming languages, markup languages, etc. Prepare your pitchforks.</p><h2>Programming language constructs</h2><ul><li><a href="braces-semicolons.html">Braces & Semicolons</a></li></ul><h2>Programming languages</h2><ul><li><a href="c.html">C</a></li><li class="wip"><a href="cpp.html">C++</a></li></ul></body></html>
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>Language Criticism | xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Language Criticism</h1><p>Here I'm going to criticize all kinds of languages: spoken languages, programming languages, markup languages, etc. Prepare your pitchforks.</p><h2>Programming language constructs</h2><ul><li><a href="braces-semicolons.html">Braces & Semicolons</a></li></ul><h2>Programming languages</h2><ul><li><a href="c.html">C</a></li><li class="wip"><a href="cpp.html">C++</a></li></ul></body></html>
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
extends ../templates/main.jade
|
||||
|
||||
block title
|
||||
| Language Criticism | xigoi
|
||||
|
||||
block content
|
||||
h1 Language Criticism
|
||||
p Here I'm going to criticize all kinds of languages: spoken languages, programming languages, markup languages, etc. Prepare your pitchforks.
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><p>Sorry, this page doesn't exist on my website. Would you like to go to the <a href="/">main page</a>?</p></body></html>
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>Not Found | xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>404 Not Found</h1><p>Sorry, this page doesn't exist on my website. Would you like to go to the <a href="/">main page</a>?</p></body></html>
|
||||
|
|
@ -1,6 +1,10 @@
|
|||
extends templates/main.jade
|
||||
|
||||
block title
|
||||
| Not Found | xigoi
|
||||
|
||||
block content
|
||||
h1 404 Not Found
|
||||
p
|
||||
| Sorry, this page doesn't exist on my website. Would you like to go to the
|
||||
a(href="/") main page
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Opinions</h1><p>Here are some of my opinions that could be considered controversial. Fell free to argue about them with me.</p><h2>Casual</h2><ul><li>Pineapple pizza is the best pizza.</li><li>Teeth should be brushed after breakfast, not before.</li></ul><h2>Mathematics</h2><ul><li>0 is a Natural number.</li><li>The Axiom of Choice is intuitively false.</li></ul><h2>Programming</h2><ul><li>C is a badly designed programming language with ugly syntax.</li><li>Semicolons and braces are syntactic noise and should not be necessary in modern languages.</li><li>Indexing from 0 is <a href="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html">objectively better</a> than indexing from 1 even if we disregard how it internally works.</li></ul></body></html>
|
||||
<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><link rel="icon" href="/images/xigoi-thicc.svg"><link rel="stylesheet" href="/styles/main.css"><script async src="/scripts/counter.js"></script><title>Opinions | xigoi</title></head><body><a href="/"><header><svg id="xigoi-logo" width="20" height="20" viewBox="-7 -2 24 24" xmlns="http://www.w3.org/2000/svg"><path d="M 0 20 L 9 8 A 5 5 0 1 0 1 8 L 4 12 A 5 5 0 0 0 8 14 A 2 2 0 0 1 10 16 A 4 4 0 0 1 2 16 A 5 5 0 0 1 3 13 A 10 10 0 0 0 5 7" stroke="#0ff" stroke-width="1"></path><circle cx="5" cy="5" r="1" fill="#f80"></circle></svg><div class="xigoi">xigoi</div></header></a><h1>Opinions</h1><p>Here are some of my opinions that could be considered controversial. Fell free to argue about them with me.</p><h2>Casual</h2><ul><li>Pineapple pizza is the best pizza.</li><li>Teeth should be brushed after breakfast, not before.</li></ul><h2>Mathematics</h2><ul><li>0 is a Natural number.</li><li>The Axiom of Choice is intuitively false.</li></ul><h2>Programming</h2><ul><li>C is a badly designed programming language with ugly syntax.</li><li>Semicolons and braces are syntactic noise and should not be necessary in modern languages.</li><li>Indexing from 0 is <a href="https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html">objectively better</a> than indexing from 1 even if we disregard how it internally works.</li></ul></body></html>
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
extends templates/main.jade
|
||||
|
||||
block title
|
||||
| Opinions | xigoi
|
||||
|
||||
block content
|
||||
h1 Opinions
|
||||
p Here are some of my opinions that could be considered controversial. Fell free to argue about them with me.
|
||||
|
|
|
|||
Loading…
Reference in New Issue