Refactor articles

Rants/Lua over Ruby.md

@@ -11,7 +11,7 @@ Today I'd like to point out some reasons that have shaped my opinion on the two
 
 I will risk sounding like a hater, but I'd like to point out that I don't particularly dislike Ruby. There's many positive things about it, but since I do prefer Lua, I just chose to point out some of its problems today.
 
-# Speed
+## Speed
 
 It'd be easy to just say "Lua fast, Lua good" and be done with it. In reality though, things aren't always that easy.
 
@@ -37,8 +37,6 @@ sys 	0m0.001s
 
 This only makes a difference when you're calling the executable many times in a row, but the difference does add up over time.
 
-----------------------
-
 ### Functions vs. Methods
 
 The next thing to consider is that, in Lua, functions are stored in variables, and are therefore easy to look up.
@@ -56,8 +54,6 @@ Even the main object every ruby script runs in inherits from 3 ancestors.
 
 It should be noted that Lua isn't immune to this problem. When writing object-oriented code, this also ends up happening. The difference is that in Lua the programmer must do this explicitly, while in Ruby it happens all the time.
 
-----------------------
-
 ### Strings / Symbols
 
 ~~This may surprise some people, but Lua actually has a huge disadvantage to Ruby in terms of speed: It has no Strings in the way Ruby has them. All strings in Lua are automatically interned. Ruby has interned strings as well; it calls them *Symbols*.~~
@@ -74,8 +70,6 @@ However, the downside that Lua strings are immutable remains, and modifying a st
 
 `</edit>`
 
-----------------------
-
 ### Vararg functions
 
 If I was asked which of the two languages had the powerful implementation of variadic functions, I'd 100% say Ruby. You can mix and match many kinds of syntactic constructs that capture additional arguments into both arrays and hashes.
@@ -105,8 +99,6 @@ Here, there's no array involved. The function can just leave bar on the stack, c
 
 This means writing functions like this is way more viable even when your code needs to run as fast as possible.
 
-----------------------
-
 ### Mentality
 
 One difference that probably makes a way larger difference than most people would assume is the difference in mentality between the two communities.
@@ -115,17 +107,13 @@ When asked why Ruby is so great, the general response from its community will be
 
 My experience with the Lua community has been vastly different. A simple google search brings up way more relevant and detailed information on how to improve performance in Lua than in Ruby, even though the latter has a much larger community that also seems to write way more about it.
 
-----------------------
-
 ### LuaJIT
 
 Lua is already very fast on its own. LuaJIT though, that's a completely different level. There have been examples where JITed Lua code can even run faster than equivalent C code, because the compiler sometimes has more awareness of the code it's optimizing (After all, it keeps track of the code as it's being executed)
 
 Ruby has made a huge step in the right direction with its own JIT Compiler, but that's still nowhere near the performance improvements of LuaJIT when compared to PUC Lua, the "reference" Lua implementation.
 
--------------------------------------
-
-# Simplicity
+## Simplicity
 
 Leaving performance aside now, there's another reason why I consider simplicity a very positive feature of Lua: It's not only easy to learn, but also easy to master.
 
@@ -149,8 +137,6 @@ local someclass = require 'someclass'
 local foo = someclass.new()
 ```
 
-----------------------
-
 ### Side effects
 
 Ruby tries to be as comfortable as possible for the developer. I often find myself wishing it didn't
@@ -173,8 +159,6 @@ Even worse, maybe some developer thought if we wanted to know about the last mis
 
 This kind of thing happens often in Ruby. The lines between what is a value and what is code that gets executed are blurred.
 
-----------------------
-
 ### (in)Consistencies
 
 Try the following code in `irb`:

Rants/Rant on Change.md

@@ -6,15 +6,15 @@ tags: rant, programming, community
 date: 2020-11-25
 ---
 
-# Preamble
+## Preamble
 
 Over the last decade or so, I've had a peek into quite a few developer communities. I do most of my private programming in Lua, and interact with that community almost daily. At work I use Ruby, and often get a good glimpse of that community as well. Through Hacker News, Reddit and a bunch of other sites I get a good impression of many different "general" programming communities. I am only human, so my opinions will of course be biased, but for what it's worth, I do believe that I have at least some degree of objective perspective on this topic.
 
-# The Problem
+## The Problem
 
 Lately, I've noticed a bit of a trend within the world of software development. Put bluntly, it seems to me like the field of programming is slowly but surely drifting down the hillside, spearheaded but not exclusively caused by the web community in particular.
 
-# The Symptomatology
+## The Symptomatology
 
 What do I mean by this though? Well, starting with the a parallel, but mostly positive process: Programming is becoming more and more inclusive and easy to get into. Elitism is slowly becoming more of a meme than an honest feeling of superiority, and more and more people are picking up programming or closely related skills.
 
@@ -34,7 +34,7 @@ Why does this matter? Consider the public image of programming. Currently, most
 
 So from that perspective, constantly reiterating the idea that programmers are just code-monkeys that only google things is, to put it bluntly, strategically stupid.
 
-# The Mythology
+## The Mythology
 
 The idea that programmers just copy together all of their code is far from the only harmful idea out there though. Parallel to it, a much more harmful myth is that "everyone can code [on the same level]". Now, just as with drawing, music and many others, I do believe that everyone, without exceptions, is capable of learning the basics of programming. 
 
@@ -44,7 +44,7 @@ So how does that persistent myth do any real harm? In the same way the Google an
 
 On the other side, it sometimes seems that employers still haven't given up on the mythical plug-n-play developer that can be employed today and start being 100% effective tomorrow. It used to be that OOP promised developers who could be interchanged without any effort, and instead of just disappearing, this supersticion seems to just have shifted to the ridiculous belief that a developer can specialise in a specific tech stack to the degree where they can just be sat down before a project and they'll instantly know how to make the product better.
 
-# The End Game
+## The End Game
 
 Is all of this coincidence? Well, it probably is. I don't believe there's any mastermind about us programmers shooting our own leg and devaluing our own skills. However, there is someone who profits from it, and certainly has good enough reasons to help the process along occasionally.
 
@@ -60,7 +60,7 @@ The strategy seems obvious: gasslighting us all into believing we're of very low
 
 While everybody can estimate how much skill and effort goes into, say, building furniture, it is very hard if not impossible to the uninitiated to get a feeling for how difficult it is to build a software product. It seems almost like black magic to the outsider, and this is another thing that people often joke about (sadly, the punchline is often that ultimately, we're not doing anything at all difficult).
 
-# The Remedy
+## The Remedy
 
 It is hard to say what could be done to push programming back up the hill. There seems to be a strong culture of self-deprecation (probably adopted from broader nerd-culture), and a tendency to unironically under-value ones own skills in this community. The amount of posts I find about impostor syndrome every week on its own already indicates that we have a serious problem that needs to be addressed.
 
@@ -70,6 +70,6 @@ As for the focus on finding employment, I really think that needs to be toned do
 
 And please, don't sell yourselves under value. Programming is hard. Everyone can learn it, but few can master it. We're not just code-monkeys copying from google. And if you're learning: Try having fun and don't worry too much about maximising your employability.
 
-# In Conclusion
+## In Conclusion
 
 It's not like I think the world will end. Programming won't stop being my hobby, nor do I fear I some day won't find a job (at least not before someone develops an AI that does all the programming for us and understands human language). I want the world of programming to stay this quirky place, where people build cool stuff, share what they've built and discuss it with others. Ultimately I hope we can all have fun programming 🧡

Rants/Tabs over Spaces.md

@@ -6,23 +6,23 @@ tags: indentation, tabs, spaces
 date: 2021-02-15
 ---
 
-# The Debate
+## The Debate
 
 This is probably one of the longest ongoing bikeshedding debates in the programming community: Should we indent our code with **Tabs** or with **Spaces**?
 
 In this post, I will do my best to explain why **tabs** are the right choice, not only in my personal opinion, but objectively.
 
-# Indentation
+## Indentation
 
 First of all, I want to define the scope of my argumentation: I am referring to **indentation**, not **alignment**.
 
 The former depends on semantics, the latter on word lengths. For obvious reasons, using tabs for alignment is not possible; whether alignment should be a thing at all (hint: it shouldn't) or how it should be achieved is a different debate and irrelevant for this post.
 
-# Semantics
+## Semantics
 
 The most puritan argument for tabs is probably the semantic information they add to the code. I have never seen a real-world example where this matters, but as programmers we often like to obsess over using the right "thing", be it a HTML element or an ASCII character.
 
-# Consistency
+## Consistency
 
 The main argument I've heard defending spaces is that code looks "consistent" everywhere. Whether you post your code on Stack-Overflow, GitHub Gists, or on your blog; it will always be indented by the same width.
 
@@ -30,7 +30,7 @@ Code is not visual art. The indentation width doesn't alter the codes meaning in
 
 **There is no reason whatsoever why someone else reading my code should experience it with the same indentation width that I wrote it in.**
 
-# Customizability
+## Customizability
 
 I personally prefer a tab-width of three spaces. Two is just barely too short to follow through deeper nested blocks of code. Four is one more space-width than I need.
 
@@ -40,7 +40,7 @@ The answer is, of course, you shouldn't. You should be able to read *my* code th
 
 **Everyone should be able to read code with their own preferred settings.**
 
-# Accessibility
+## Accessibility
 
 So far I've looked at customizability as a convenience feature. I *like* 3-space indentation more, so I *want* to read code that way.
 
@@ -48,7 +48,7 @@ But for some people it goes beyond just preference.
 
 I've seen posts and comments of quite a few developers with poor eyesight. For some, 2 spaces is just not enough indentation, making it unnecessarily hard to read code, others might need to use very large font sizes, and prefer shorter indentations to save screen space.
 
-# Consistency (again, but differently)
+## Consistency (again, but differently)
 
 This is by far the most ridiculous reason, or group of reasons people make to argue for spaces:
 
@@ -58,6 +58,6 @@ Needless to say, this argument works exactly the same both ways, and if anything
 
 Regardless of preference, in the age of linting tools and CI pipelines, this is just not an issue any more. We can automate the process of checking indentation, or even have it fixed automatically.
 
-# Conclusion
+## Conclusion
 
 There is not a single good reason to prefer spaces over tabs. The whole space-indentation mythology is nothing but ridiculous non sequiturs and false claims.