Talk:Essays/A Defence of Brainfuck Derivatives

Here's my take on this (Challenger5 (talk) 06:51, 8 February 2017 (UTC)):

BF is one of the most well-known esoteric languages. It is a simple language based on a Turing machine, and, with 8 instructions, it was one of the first examples of a Turing tarpit. Because of BF's popularity, it is often the first esoteric language that people work with, which means that many users begin participating in the esolang community by creating a language inspired by BF. This had led to many members becoming increasingly frustrated with too many of what they call "BF derivatives."

In this essay, I aim to accomplish these goals:

• To clarify the idea of a "BF derivative."
• To look at the differences between different types of BF-like languages.
• To find ways to deal with the large number of BF derivatives.

When people say "there are too many BF derivatives," what do they really mean? After all, BF is an interesting language and was very influential to the esoteric language community. So why wouldn't they want to see more languages that build off of BF? And we do have some truly original and interesting BF derivatives, like Hexagony and Brian & Chuck. So why do people have a problem with too many BF derivatives? In order to understand what people mean, let's consider the types of BF derivatives:

• Addition: These languages try to add new features to BF to make writing programs easier. This may include features like unbounded cell sizes, arithmetic operators, additional layers of storage, functions/procedures, etc. These languages are often created because the users could find a way to map these operators onto normal BF but didn't want to have to manage their memory/program accordingly, so the creator just added a set of extra instructions. Another reason that these may be created is because the creator found BF too difficult and wanted to create a "wimpmode." This type is often made by beginning esolang designers; I've made one of these myself as well (Z).
• Removal: These languages attempt to minimize BF instructions while preserving Turing completeness. This is often done by changing bytes to bits, memory-mapping I/O (or removing it altogether), and combining various instructions into a single instruction. However, this type is less common because there is mostly no new work that has been done minimizing BF instructions.
• APIs: This is similar to the "addition" type, but it is focused on adding new features that could not be easily recreated (or recreated at all) in BF. For example, these languages might add networking, file I/O, graphics, etc. These are often created because the creator wanted to write a complex program, but found themself unable to because of the restrictions on I/O.
• Substitution: These languages have instructions that can be substituted fairly easily into BF. Languages like Alphuck, Pi, and VerboseFuck are substitution derivatives.

At this point, I feel the need to distinguish between a language that is a derivative of BF and a language inspired by BF. The characteristic of a derivative is that it has mostly the same instructions as BF. That is, it most likely has tape memory operations, while loops, etc. Note that by this definition, languages like Hexagony and Brian and Chuck are not actually BF derivatives! Hexagony changes the memory layout, control flow, and program structure, and Brian and Chuck removes direct loops and forces you to use self-modification for Turing completeness. These languages should not be considered derivatives of BF, but rather inspired by BF. BF is such a simple language, and so close to a Pure Turing machine, that it is easy to rationalize any tape-based language as a BF derivative. This is a very nonconstructive view of BF derivatives. The true value of BF derivatives comes from their ability to be a "sounding board" for esolang designers' ideas. Earlier, I said that many users enter into the esolang community by making a BF derivative. This is because BF is a simple and easily extensible language that allows them to test new ideas. Almost all of these BF derivatives had some interesting addition to them. This is why we can't just criticize "BF derivatives" - we have to criticize bad BF derivatives. We have to make languages that encourage new development and ideas.

So maybe BF derivatives aren't so bad. But then why are they still so irritating? I think this is because currently the presentation of BF derivatives is not done well. Here are some things to keep in mind when you are writing about your derivative:

• It can be difficult to understand what makes a BF derivative unique. This means that if you want your BF derivative to be well=received by the community, you have to clarify exactly what sets your language apart from BF and every other BF derivative out there.
• We often see multiple almost identical derivative languages. It can often be hard to figure out whether a BF derivative has been made already that is similar to yours. When you are submitting your BF derivative, add it to language lists and add a description so that other people can quickly understand what your derivative is about.
• It would be nice to have a few more features on the Esolangs wiki like a better search feature or a way to filter results. This way it would be easier to find languages that interested you, if you're not convinced and really hate BF derivatives that much.

To conclude, bad BF derivatives are indeed far too numerous and are a problem in the Esolang community. However, BF is a useful template for developing new ideas, and many unique and interesting languages have been inspired by BF. We need to move away from automatically disregarding over every BF derivative we find, and instead encourage people to develop new, unique esolangs. Our community is not really about languages - it is about unique models of computation or program development expressed by creating new languages. A good esolang will always bring something new to the table, and very good ones will inevitably inspire derivatives. Each derivative is a compliment to the original language creator, but each new derivative should also be interesting and unique in itself.