commit a2bace66e6eadbade52d62c2887fb91dddf3dd73
parent 811df3ce7bb216b83fe20caab81f44b507ae1789
Author: Jake Bauer <jbauer@paritybit.ca>
Date: Fri, 10 Mar 2023 22:22:38 -0500
*
Diffstat:
3 files changed, 156 insertions(+), 166 deletions(-)
diff --git a/content/blog/why-email-is-the-best-discussion-platform.md b/content/blog/why-email-is-the-best-discussion-platform.md
@@ -8,43 +8,48 @@ Summary: In an age where everything seems to be going to the web and people are
**Author:** [%author] | **Published:** [%date]
Lots of very vocal people online advocate moving discussion platforms for free
-and open source projects from email to other platforms such as Discourse or
-Slack citing that these platforms are "more modern" or "easier to use". For the
-most part, I understand where they're coming from. Email as a text-only medium
-(ignoring attachments) might feel limiting to someone used to the multimedia,
-JavaScript-filled landscape of most contemporary collaboration platforms.
-
-I get it. These platforms are perhaps more inviting because of a friendly UI,
-inline image, link preview, and emoji support, and it all runs in the browser
-which is where everything else is seemingly done nowadays. The problem is that
-these features really aren't necessary and they rarely improve discussions which
-could otherwise happen, and work just fine, over email.
-
-Historically, and still to this day, many free and open source software projects
-(Debian, git, the Linux kernel, etc) use a combination of email and IRC for
-their communications. Email is the asynchronous platform where decisions can be
-announced, questions can be asked no matter who is online, and there can be an
-open, infinite public record of discussions and questions which can be freely
-searched by anybody by consulting the archives of that mailing list or the
-various mailing list archiving sites. IRC is the synchronous, ephemeral platform
-where developers and users can go to hash out quick discussions, get answers to
-their support questions quickly, and generally hang out like one would in a
-Slack or Mattermost channel. IRC is a topic for another day, so I'll just be
-focusing on why email is better in this post.
-
-The biggest problem with contemporary platforms is that they're functionally a
-regression from what already exists. Platforms such as Slack and Discord are
-walled gardens requiring account creation, Discourse and Mattermost are better,
-yet you still have to access them through a web browser and those who wish to
-use their own clients are treated as second-class citizens. This is especially a
-problem for disabled users who find text-based interfaces (of which there are
-plenty for email) far easier to use.
-
-When using services such as Slack and others which use analytics, users have to
-be conscious that they are effectively being monitored by that software all the
-time. It's entirely possible for platforms like Discord and Slack to be sharing
-the information they collect with third party companies who then go on to sell
-it (if they don't already sell it themselves).
+and open source projects from email to other platforms such as Discourse,
+Slack, or Discord citing that these platforms are "more modern" or "easier to
+use". For the most part, I understand where they're coming from. Email as
+a text-only medium (ignoring attachments) can be limiting to someone used to
+the multimedia, resource-heavy landscape of most contemporary collaboration
+platforms.
+
+I get it. These platforms are more inviting because of a friendly UI, inline
+image, link preview, and emoji support, and they run in the browser which is
+where everything else is seemingly done nowadays. The problem is that open
+source projects typically give up the advantages that come with using open and
+light platforms for features that are more flashy than they are useful and
+which rarely improve discussions which could otherwise happen and work just
+fine over email.
+
+Historically, and still to this day, many free and open source software
+projects (Debian, git, the Linux kernel, etc) use a combination of email and
+IRC for their communications. Email is the asynchronous platform where
+decisions can be announced, questions can be asked no matter who is online, and
+there can be an open, public record of discussions and questions which can be
+freely searched by anybody by consulting the published archives of that mailing
+list, and IRC is the synchronous, ephemeral platform where developers and users
+can go to hash out quick discussions, get answers to their support questions
+quickly, and generally hang out like one would in a Slack or Mattermost
+channel.
+
+The biggest problem with contemporary platforms is that they're functionally
+a regression from what already exists. Platforms such as Slack and Discord are
+closed-source, walled gardens. Discourse and Mattermost are slightly better,
+but have poor support for third-party clients which is especially a problem for
+users with disabilities who find text-based interfaces far easier to use.
+
+All of these platforms take a long time to load on a slow connection, download
+and run many megabytes of JavaScript, and must be run in a browser which is
+a very resource-hungry piece of software that can be difficult for those with
+fewer computing resources (such as those using second-hand equipment in poorer
+countries) to run.
+
+Not to mention that services which use analytics, such as Discord, are
+monitoring their users all the time. It's entirely possible for platforms like
+Discord and Slack to be sharing the information they collect with third party
+companies who then go on to sell it (if they don't already sell it themselves).
<figure>
<a href="/img/slack-tracking.png"><img src="/img/slack-tracking.png"/></a>
@@ -52,18 +57,11 @@ it (if they don't already sell it themselves).
workspace showing XHR requests to a 'track' URL.</figcaption>
</figure>
-Not to mention the various other issues such as text-based content being far
-better for accessibility than what the web can offer, most of the web-based
-packages being very bloated where pages take seconds to load and megabytes of
-bandwidth, and the fact that web browsers are very resource-hungry pieces of
-software which can be difficult for those with fewer resources (e.g. people with
-second-hand equipment in third world countries) to run.
-
So, what does email bring to the table over contemporary options? Email is
federated, it allows one to use a variety of different clients, it can be used
-both for patches and discussion, it's nowhere near as difficult to use as people
-make it out to be, the asynchronous nature is actually beneficial, and it
-eschews cruft and flash to leave you with nothing but plain text.
+both for patches and discussion, the asynchronous nature is actually
+beneficial, and it eschews cruft and flash to leave you with nothing but plain
+text. It's also nowhere near as difficult to use as people make it out to be.
The fact that email is federated allows anyone with an email address to
communicate with any public mailing list no matter who their provider is. For
@@ -73,32 +71,31 @@ account, and so on. The barrier to entry is lower than with other platforms.
Federation also allows one to run their own email infrastructure if they wish
(and they should, in my opinion).
-With email, one can also choose whichever client they wish to use. If you work
+With email, you can also choose whichever client they wish to use. If you work
in emacs you can choose mu4e. If you prefer Thunderbird then you can use that.
As long as your email client supports plain text email, you can use whichever
-you like the most. This is important to many hackers who often heavily customize
-the software they run to fit their workflow and their needs. Using email allows
-for this freedom, but the wide variety of clients also means that you're not
-forced to either.
+you like the most. This is important to many hackers who often heavily
+customize the software they run to fit their workflow and their needs. Using
+email allows for this freedom, but the wide variety of clients also means that
+you're not forced to do this if you don't want to.
Another great thing about email is that it can be used for patches in addition
to discussion. [Sending patches via email](https://git-send-email.io) is as
-simple and straightforward as using something like Pull Requests. Just like with
-Pull Requests, the discussion can be had in the same thread as a submitted patch
-and patches can be applied to a repository all without needing to open a web
-browser or use a different piece of software.
-
-Unfortunately, email has a reputation of being hard to use because of what I
-think is an unwillingness to learn a new paradigm after having become used to
-the way of doing things over the web. The reality of it is that email is not
-difficult to use at all, it's just different and it takes just a little time and
-effort to learn a different paradigm. Many thousands of people use it every day
-contributing to projects like the Linux kernel without issue.
+simple and straightforward as using something like pull requests. Just like with
+pull requests, the discussion can be had in the same thread as a submitted patch
+and patches can be applied to a repository; all without needing to open a web
+browser.
+
+Unfortunately, email has a reputation of being hard to use. Frankly, I don't
+think this is deserved. Email is not difficult to use, it's just different and
+it takes just a little time and effort to learn a different way of doing
+things. Many thousands of people use it every day contributing to projects like
+the Linux kernel without issue.
Regarding things like bolding and italicizing, people make do just fine using
-`/italics/`, `_underlines_`, or `*bolds*`. There's even `ALL CAPS` for when
-you're really angry. In short, you'll have no issue getting your point across.
-Some also say that email conversations are difficult to follow, but that's not
+`/italic/`, `_underline_`, or `*bold*`. There's even `ALL CAPS` for when you're
+really angry. In short, you'll have no issue getting your point across. Some
+also say that email conversations are difficult to follow, but that's not
really true depending on your mail client; they're more like Reddit threads in
any decent email client which supports conversation threading.
@@ -108,20 +105,15 @@ any decent email client which supports conversation threading.
threads.</figcaption>
</figure>
-The fact that email is asynchronous is actually far better for discussions than
-you might think. Since there are no features showing that someone is online and
-people don't expect immediate replies to emails, this gives one room to take the
-time to draft a much more thoughtful response when compared to the instant
-messaging structure of most other platforms. There's also a lot less pressure
-to respond immediately and there are no anxiety-inducing typing indicators or
-read markers.
+The fact that email is fully asynchronous is actually far better for
+discussions than you might think. Since there are no features showing that
+someone is online and people don't expect immediate replies to emails, this
+gives one room to take the time to draft a much more thoughtful message when
+compared to the instant messaging structure of most other platforms. There's
+also a lot less pressure to respond immediately and there are no
+anxiety-inducing typing indicators or read markers.
The final point that I want to make about email is that, just like IRC, there
are no frills; it's just regular old plain text. There are no embedded images,
flashy moving pictures, reactions or anything else like that. It lets you truly
-focus on just what is important: the content of a message. The best part? Plain
-text email still supports emoji because that's all just Unicode.
-
-_This is my thirty-seventh post for the #100DaysToOffload challenge. You can
-learn more about this challenge over at
-[https://100daystooffload.com](https://100daystooffload.com)._
+focus on just what is important: the content of the message.
diff --git a/content/blog/why-irc-is-still-good.md b/content/blog/why-irc-is-still-good.md
@@ -20,35 +20,34 @@ I think there is still a solid place for IRC in our lives.
IRC (Internet Relay Chat) is a communications protocol [created in
1988](http://daniel.haxx.se/irchistory.html) and, yeah, it shows. IRC is 100%
-plain text; no images, no videos, no stickers, no emoji reactions, just good ol'
-plain text. It was also designed to transmit everything in plain text (i.e.
-unencrypted) all across the Internets in a time when the use of these computer
-networks was limited mostly to universities, governments, and large
-corporations. This was a time when Hollywood-style [1337
+plain text. No images, no videos, no stickers, no emoji reactions, just good
+ol' plain text. It was also designed to transmit everything unencrypted at
+a time when the use of computer networks was limited mostly to universities,
+governments, and large corporations. This was a time when Hollywood-style [1337
h4x0rs](https://www.urbandictionary.com/define.php?term=1337%20h4x0r) were
pretty much just kids using their modems to make long distance calls for free.
-Nowadays, IRC is probably not such a good platform for private personal chats,
-but that doesn't mean it's not good for other things.
+Nowadays, IRC may not be the best platform for private personal chats (though
+I think it can still work for that), but that doesn't mean it's not good for
+other things.
Arguably the best "feature" of IRC is that it's still all in plain text. No
multimedia or fancy features such as emoji reactions, integrations, or stickers
-keeps the bandwidth usage down and the focus on the content of what people are
-saying, rather than on distracting memes and flashy things. It's the same reason
-why people like lean websites, plain text email, plain text notes, and so on:
-plain text is easy, portable, lean, and pure. You can even still [send files
-using IRC](https://en.wikipedia.org/wiki/Internet_Relay_Chat#File_sharing).
+keeps the bandwidth usage down and the focus on what people are saying, rather
+than on distracting memes and flashy things. It's the same reason why people
+like lean websites, plain text email, plain text notes, and so on: plain text
+is easy, portable, lean, and quiet.
One aspect of computing and software design that many developers nowadays seem
to forget is that [over half of the world's population does not have access to
fast
Internet](https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds)
-and many people, even in developed countries, are limited by bandwidth caps and
-spotty satellite or mobile Internet access. For these people, IRC can be the
-much better option compared to other collaboration platforms such as RocketChat,
-Mattermost, Slack, or Matrix, even if they have to use an IRC bouncer or a
-screen/tmux session on a remote server to not miss things if their connection is
-that spotty.
+and many millions of people, even in developed countries, are limited by
+bandwidth caps and spotty satellite or mobile Internet access. For these
+people, IRC can be a much better option compared to other chat platforms such
+as RocketChat, Mattermost, Slack, or Matrix, even if they have to use an IRC
+bouncer or a screen/tmux session on a remote server to not miss things if their
+connection is that spotty.
<p class="note">Did you know, <a
href="https://twitter.com/JobSnijders/status/1300068892719697920">IRC played a
@@ -59,13 +58,13 @@ CenturyLink outage</a>?</p>
One of the biggest flaws I see people discuss when talking about IRC is that
chat history is not saved by the server. This means that, if you want a record
of the conversations which happen when you're not connected, you'd have to use
-an IRC bouncer or screen/tmux session which will keep you connected when you
+an IRC bouncer or a screen/tmux session which will keep you connected when you
have to go offline. I can definitely see this being a limitation for a private
group chat if this is not something you're willing to do, but when it comes to
open source collaboration or support, this makes IRC great for hashing out
-ideas, asking quick questions, and having conversations while hacking on things.
-In these cases you don't really care what's happening when you're not there
-because these are synchronous conversations which is perfect for the ephemeral
+ideas, asking quick questions, and having conversations while hacking on
+things. In these cases, you don't really care what's happening when you're not
+there. These kinds of synchronous conversations are perfect for the ephemeral
nature of IRC.
Even though encryption is not mandated by IRC or enabled by default in many
@@ -76,44 +75,38 @@ weakness would be logs on the servers themselves or logs on client machines. If
you and your friends like the plain text medium, it's entirely possible to set
up an IRC server which mandates encryption and doesn't store logs long-term. If
you're in a group of people you can trust to be competent then it's entirely
-possible to make IRC work this way and have a reasonable guarantee of privacy
-and security.
+possible to make IRC work this way and have a reasonable guarantee of privacy.
I suppose I should also mention the federating aspect of IRC since that's quite
-a hot topic in the open source social platform world. IRC does federate in a
-way, but it's not quite like the way Pleroma or Mastodon do. In the world of
-IRC, IRC networks are made up of one or more IRC servers. If you connect to an
-IRC server, you can view and interact with any channels or users on the same
-network that server is a part of. The way IRC exists right now is due to several
-network splits (netsplits) where many servers decided to split off of a big
-network to form their own, separate network several times throughout IRC
-history. This is similar to having a group of several Mastodon/Pleroma instances
-which have decided to federate with nobody else except those also in the group
-and is why we have the LiberaChat IRC network alongside the Undernet, EFnet, and
-so on. Many of those splits occurred in the earlier years of IRC, and many of
-the larger networks like LiberaChat are quite stable, having a coordinated team
-of admins to make sure things keep running smoothly.
-
-The reason why this isn't really such a big issue when it comes to IRC though is
-that IRC doesn't really have accounts in the same way other platforms do. It
-typically takes the form of registering a nickname with a network's NickServ bot
-to reserve it, but that's often only mandatory for speaking on the larger
-networks as a spam countermeasure. Account registration is also so easy that you
-can join however many IRC networks you want with little hassle; connect, set
-your nick (often done automatically by your client), and a quick message to
+a hot topic in the open source social platform world. IRC does federate in
+a way, but it's not quite like the way Mastodon does. IRC networks are made up
+of one or more IRC servers and you can view and interact with any channels or
+users on the same network that the server you're connected to is a part of. The
+way IRC exists right now is due to several network splits (netsplits) where
+some servers decided to split off of a big network to form their own, separate
+network (usually due to governance disagreements). This is why we have the
+LiberaChat IRC network alongside the Undernet, EFnet, and so on. Many of those
+splits occurred in the earlier years of IRC, and many of the larger networks
+like LiberaChat are quite stable, having a coordinated team of admins to make
+sure things keep running smoothly.
+
+The reason why this isn't really such a big issue when it comes to IRC though
+is that IRC doesn't have accounts in the same way other platforms do. Accounts
+typically take the form of registering a nickname with a network's NickServ
+bot to reserve it, but that's often only mandatory for speaking on the larger
+networks as a spam countermeasure. Account registration is also so easy that
+you can join however many IRC networks you want with little hassle; connect,
+set your nick (often done automatically by your client), and a quick message to
NickServ will get you up and running on just about every network.
-IRC is still a really useful and good platform especially for software
-minimalists and technical users who wish to have a relatively hassle-free
-experience. IRC is great for open collaboration and quick support in free
-software projects (far better than Slack or Discord) and it can be made to work
-for private chats especially if you run your own IRC server. Yes, IRC is not
+IRC is still a really useful and good protocol for users who wish to have
+a mostly hassle-free chat experience. IRC is great for open collaboration and
+quick support in free software projects (far better than Slack or Discord) and
+it can be made to work for private chats especially if you run your own IRC
+server (I would recommend the [Ergo](http://ergo.chat). Yes, IRC is not
necessarily great for non-technical users or those who require extensive
guarantees of security; it might even be too much of a hassle for you, but this
doesn't mean it's dead, useless, or outdated. IRC is not only still useful, but
-can still be the best tool for the job in the modern age, especially with the
-coming improvements in the form of [IRCv3](https://ircv3.net/).
-
-_This is my ninety-eighth post for the #100DaysToOffload challenge. You can
-learn more about this challenge over at
-[https://100daystooffload.com](https://100daystooffload.com)._
+can still be the best tool for the job in the modern age, especially with
+protocol improvements (like chat history) in the form of
+[IRCv3](https://ircv3.net/).
diff --git a/content/garden/programming-style.md b/content/garden/programming-style.md
@@ -63,18 +63,17 @@ your programs the best chance of being usable far into the future instead of
suffering from [code rot](https://en.wikipedia.org/wiki/Software_rot) within
a few years.
-The trend in JavaScript (npm), Python (pip), Rust (cargo), and Go (it's
-de-facto dependencies on Google and GitHub) is very concerning for the future
-of programs written in these languages. (And, in fact, I have run into issues
-getting older Python programs to run due to packages no longer being
-available.)
+The trend in JavaScript (npm), Python (pip), Rust (cargo), and Go (its de-facto
+dependencies on Google and GitHub) is very concerning for the future of
+programs written in these languages. In fact, I have run into issues getting
+older Python programs to run due to packages no longer being available.
## Comments
-Comments should only exist in code to express why something is being done
-a certain way or to clarify a particularly tricky bit of code that is hard to
-express in any other way. Comments like the following are completely useless
-and should not exist:
+Comments should exist in code to express why something is being done a certain
+way or to clarify a particularly tricky bit of code that is hard to express in
+any other way. Comments like the following are completely useless and should
+not exist:
```
struct Node *np = &node /* Create a pointer to the node */
@@ -87,14 +86,15 @@ a function and at the top of a file, you _must_ treat this as writing
high-quality documentation that you would serve to an end user. Otherwise it
ends up being as useless as the above example in practice. I have often seen
these kinds of comments used as an excuse to not write good documentation
-("Look, we have doxygen-generated documentations; we documented this code!")
-which makes these kinds of comments just clutter.
+("Look, we have doxygen-generated documentations that list all the parameters;
+we documented this code!") which makes these kinds of comments just clutter.
Great uses of comments include:
* Pointing to external documentation or another file as a guide or explanation
* TODO or FIXME markers
-* Blocks before the declaration of a particularly complex data structure
+* Explaining a particularly complex data structure
+* Explaining the purpose of a function that isn't immediately clear by reading its name
* Explaining the quirks of a particular algorithm (e.g. working around a hardware limitation)
Also see: [The Misunderstood Concepts of Code
@@ -104,9 +104,9 @@ Comments](https://text.martinmch.com/2020-08-11-comments-should-be-red.html).
Try to minimize complexity as much as possible. Complexity **does not
necessarily refer to lines of code**. Complexity often arises from complicated
-program logic, bad program design, "cleverly-written" code designed to be
-optimized for speed, and excessive reliance on external dependencies, where
-lines of code is just a symptom of these diseases.
+program logic, bad program design, "cleverly-written" code, and excessive
+reliance on external dependencies, where lines of code is just a symptom of
+these diseases.
The more code a program has, the more bugs your program can have. The more
features your code has, the more ways those features can [interact in
@@ -127,7 +127,7 @@ implementing your own multiplication algorithm for whatever reason and you
don't expect to be operating on numbers that large then it's counterproductive
to implement the more complex algorithm because it will perform worse and be
harder to understand. Fancier algorithms and data structures offer more
-opportunity for bugs, and are also harder to debug than their simpler
+opportunity for bugs and are also harder to debug than their simpler
counterparts.
Finally, this is one point that I wish was hammered into every programmer's
@@ -136,9 +136,9 @@ program. Too many programs are written in convoluted or confusing ways in an
attempt to chase perceived performance gains without any actual benchmarking or
measurement. Only tune once you understand how your program behaves, because
only then can you justify the increased complexity that comes along with
-bespoke optimizations. Beyond this, there is no point tuning a program for
-marginal improvements in overall speed unless you are specifically targeting
-a performance metric.
+bespoke optimizations and only then will you know what is worth optimizing and
+what is not. There is no point making a program harder to read by applying
+optimizations that lead to extremely marginal improvements.
## Naming
@@ -187,9 +187,9 @@ decide whether acronyms should be capitalized. Should you write
`fetchRssFeedAsXml` or `fetchRSSFeedAsXML`? Eliminate the need to make that
decision by just writing `fetch_rss_feed_as_xml`. Whatever you do, please don't
mix the two (`XMLHttpRequest` is a classic real-world example, probably done
-because nothing else looked better, but `xml_http_request` looks just fine and
-doesn't make capital letters play double-duty as word boundary markers and as
-abbreviations).
+because nothing else looked better, but `xml_http_request` is perfectly clear
+and doesn't make capital letters play double-duty as word boundary markers and
+as abbreviations).
Furthermore, it is acceptable to use short names where the meaning is
immediately clear from the context. For example, `np` is better than
@@ -527,8 +527,8 @@ Now, onto The Debate™...
There is little difference between spaces and tabs for indentation. Although
some people might cry "accessibility!" as an argument for tabs over spaces,
there is no significant evidence to support this assertion and I have seen
-accessibility anecdotes for both. Unless someone some kind of actual study on
-this, I will continue to assert that there is little meaningful difference.
+accessibility anecdotes for both. Unless someone does some kind of actual study
+on this, I will continue to assert that there is little meaningful difference.
That being said, I prefer tabs wherever supported for the following reasons:
@@ -540,13 +540,18 @@ That being said, I prefer tabs wherever supported for the following reasons:
On the first point, although disk space is quite plentiful today, bandwidth
still isn't. Even on files that are only a couple of hundreds of lines long,
-using spaces instead of tabs to indent increases file size by a decent amount.
-If you're trying to optimize the size of assets you're delivering over the wire
-(e.g. HTML, CSS, and JS files), this is even more pertinent. For example, this
-page as an HTML file indented with four spaces takes up roughly 33.3 kilobytes,
-but it only takes up 23.1 kilobytes if indented with tabs. This quickly
-compounds the more data is sent over the wire and affects everything from
-serving websites to cloning code repositories.
+indenting with spaces instead of tabs increases file size by a non-trivial
+amount. If you have hundreds of source files across a whole project, this
+effect is even more noticeable. Likewise if you're trying to optimize the size
+of assets you're delivering over the wire (e.g. HTML, CSS, and JS files). For
+example, this page as an HTML file indented with four spaces takes up roughly
+33 kilobytes, but it only takes up 23 kilobytes if indented with tabs. This
+quickly compounds the more data is sent over the wire and affects everything
+from serving websites to cloning code repositories. Furthermore, regardless of
+disk space being cheap, the laissez-faire attitude towards being wasteful with
+computing resources demonstrated by people who say that this doesn't matter is
+one that I absolutely detest and has led us into this current era of
+ridiculously inefficient computing.
On the second point, if a programmer prefers to see a lot of whitespace to
indicate levels of indentation (as I do), they can choose to leave tabs at
