Alternatively, what I learned about engagement from making Vyxal
I've always believed that there are two ways to get the most out of participating in the Code Golf Stack Exchange: playing the main game of answering challenges and playing the metagame of golfing language/esolang creation. And arguably, though problem-solving is fun, it's the meticulous planning, strategising and marketing of esolangs, as well as community engagement where the real thrills of this site lie.
And while it's a relatively simple process to become a player in the esolang market, it's really gosh dang hard to become a successful player; out of the thousands of esolangs in existence, only a handful ever leave the confines of their esolangs.org page and gain popularity in the big wide world. So then, how do you beat the odds?
That's a question many have asked over the years. Hell, I even asked that question myself. But I now have answers, thanks in part to observations about the hyper-growth of Vyxal and in part to studying the history of some of the most influential golfing languages (05AB1E, Jelly, Husk and MATL). And I'm here to share those answers with you.
Before I start explaining the "magic" that draws people into using your esolang, I'd like to clarify a few things about the wording of this blog post:
- Whenever I use the word "esolang", I'm talking about languages intended to be used by humans for problem solving on code golf - languages like Malbolge and Brainfrick are novelty languages that you look at once and say "ha, that's cool. Time to never use this lol". Those kinds of esolangs don't exactly leave much room for growth outside of shock-factor responses.
- The word "market" is used to mean "the pool of actively used esolangs on code golf". There's no monetary value involved in this metagame, only bytes.
- The phrase "language launch" is defined as the point in time where an esolang is considered ready for normal usage - the language creator(s) decide that enough has been done that it's a "complete" enough language, and not in beta/alpha anymore.
- "Community building" refers to the act of expanding an esolang's userbase. "Community engagement" refers to the act of maintaining an esolang's userbase.
While it's tempting to view community building as something that happens after the launch of an esolang, the reality is that to successfully promote a new language, pre-launch and post-launch marketing needs to be carefully considered. As this post will detail, the pre-launch era of an esolang consists of:
- Premise generation
- Implementation
- Finalisation
While the post-launch era consists of:
- Initial engagement
- Controlled expansion
- Maintenance
These stages within each era all have to be planned and executed in a way that is always focused on the long game of popularity - whether you like it or not, ambition and thirst for market domination is an important part of esolang success. However, it is important to note that in the post-launch era, there are environmental factors that influence community building and engagement that fall outside of the control of the language creator(s). These variables will be discussed in their own section.
Alternatively, the part where everything is under your control
Getting the pre-launch era right is extremely important - it sets the foundations and tone for the post-launch era of the esolang. And while the majority of this era is writing the interpreter/compiler for the esolang, there are still long-term marketing decisions that need to be made.
But for a blog post talking about community building and engagement, one would think there wouldn't be a need to discuss the process of creating the initial ideas for the esolang. Surely, the actual esolang creation process doesn't impact the popularity of the esolang? Well yes. It does. In fact, if you get the design goals of your esolang wrong, you'll have a bad time later on when trying to advertise and spread your language. Note that this section does not intend to tell you what to include in your esolang or how to actually write the code for the interpreter/compiler - that's completely up to you. What this section does do it point out some things that you might not have previously conisdered important.
The first pre-launch step to get right is establishing the goals and purpose of the esolang; a clear and objective vision for the esolang will not only help development, it will act as the foundation for how the esolang is defined and marketed. The two things one absolutely needs to consider in this phase are the paradigm of the esolang and the desired userbase. The paradigm of the language impacts what the language will look and feel like, as well as the total percentage of the code-golf userbase will be interested in using your language. The desired userbase will guides through language design decisions and helps tailor the esolang to their needs.
The paradigm of any programming language (practical and esoteric) is the style in which programs are written in that language (trust me, I did a whole uni course on different programming paradigms.) Possible paradigms include functional, logic, stack-oriented, tacit, tape-oriented, and imperative. And while esolangs can utilise whatever paradigms they desire, it's a good idea to choose one that isn't already monopolised by another major esolang; unless the esolang can stand out from its competitors, people are unlikely to leave what they know. For example, the functional programming paradigm as well as prefix flavoured imperative paradigm are open markets for new esolangs - leaders such as Husk and Pyth have fallen relatively quiet over the last few years, meaning these categories are ripe for the picking. On the other hand, the tacit paradigm and the stack-oriented paradigm aren't as open for new esolangs - Jelly has a strong grip on the tacit market and the stack market is already divied up between Vyxal and 05AB1E. This isn't to say it's a futile activity to make tacit and stack esolangs, and that functional and imperatieve esolangs are the only esolangs that should be made. Rather, this is to say that one is more likely to achieve success by investing in viable markets.
As an aside, one might ask whether or not the market for fractional-byte esolangs is open in the context of dominating esolangs. And while a full discussion is outside of the scope of this blog post (fractional bytes are a scoring system, not a language paradigm), there is arguably room for a new fractional-byte esolang to rise up and become one of the major golfing languages. But such a language has proven elusive, thusfar, as no-one has managed to make such a language that is competitive with standard SBCS languages and is intutive/user-friendly. Prove me wrong.
As another aside, when choosing an esolang paradigm, it's a good idea to avoid something purely for novelty like a brainf*ck derivative or a heavily thematic esolang. This is because novelty esolangs are hard to sell - people will see them, think "oh that's cool", try it for a bit and realise that it's too much effort for them to do anything more complex than adding numbers. Therefore, the esolang should be designed with the intention of either being a) long-term interesting or b) able to win code golf challenges. And it should also be deisgned to be an enjoyable experience for users; unless you're going for an intentional hard mode tarpit, then make it fun and straightfoward to solve non-trivial challenges. You shouldn't need a PhD in finite state automata to sort a list.
The intended userbase of an esolang is the group of users that the language inherently caters toward. That is, the esolang is designed in such a way that a specific set of people are drawn to the language. Unlike the esolang paradigm, the intended userbase doesn't have to be completely objective or rigid - it can change over time and be expanded/narrowed as needed. Possible userbases include new users, casual golfers, hardcore golfers (think those who torture themselves with tarpits) and enthusiasts of another existing language (think APLers and languages such as J, K and BQN). It's important that the chosen intended userbase will be comfortable with the paradigm of the language - a stack-oriented esolang might not be as appealing to experienced golfers as it would be to new users, and a tacit language might be too confusing for news users but a delight for experienced golfers. Put simply, let the paradigm influence the intended userbase.
The next pre-launch step to get right is actually implementing the esolang - not the actual coding itself, but the way people interact with the development of the esolang. Indeed, it is important to consider not just the coding aspect, but the whole process of implementation, as it lays the groundwork for the initial engagement step that occurs post-launch.
To get a better understanding of why this phase is crucial to esolang success, first consider what can appear to be the most logical method of implementing an esolang: an individual programming and writing the entire language in secret and then having a big reveal once everything is completed. One would expect that hype generated by dropping hints and teasers over time would be enough to fuel initial engagement and secure a user base, as the innate human desire to not be left out of the loop would draw people into being the "first" to use the language. In reality, this has led to a sudden spike of interest followed by a sharp decline into obscurity. People see the announcement, experiment a little, and then move on. They don't get to appreciate the effort that went into making the language and they don't get to identify with the language development process. All they see is something that "magically" appeared, something that comes and goes with the wind. Thus, the esolang is seen as a novelty and a gimmick that has about the same lifetime as that of a starred message.
In this way, the implementation phase of an esolang must allow for a lifetime longer than a starred message. Indeed, it needs to create history and a story that people can embrace and adapt as their own. This is accomplished best by what this post terms "chatlogging" - the process of creating a dedicated language chat room and logging updates to the language, as well as answering any questions prospective users may have. Ideally, one would share "real-time" progress while they develop the language by announcing non-trivial changes and engaging in brain-storming and idea generation sessions.
Aside from the organisational benefits, chatlogging will allow users specifically interested in new and active esolangs to see progress and investigate the language - many code golf users are interested in the metagame of language creation, and chatlogging creates a source of exposure to attract these users. Once curious users start trickling into the chatlogging room, it is important to involve them with the development of the language; ask for language feedback, feature requests and opinions on different items. Doing so creates a "prototype userbase" - a set of people who will be able to a) help development but also b) act as the initial users of the language. And in addition to chatlogging, a good idea to help with the implementation phase is to occasionally ask about language design in TNB. This creates exposure for the esolang to the metagame inclined users who may not scan the active rooms list but do logread TNB.
Design phase: