BYOND has been around long enough that users who were new to programming when they found BYOND should be pretty good by now. BYOND has a lot of long-time users but there are hardly any examples of BYOND's home-grown talent. Something about BYOND is stunting their growth. Given the title of this article, it shouldn't come as a surprise that the lack of libraries (and lack of people using them) has something to do with it.
People don't use or develop libraries for a variety of reasons. Most often, the reason for not using them is that people have a hard enough time wrapping their head around DM, involving code written by someone else would just make it more confusing. This line of thinking is correct, it would be confusing, but it also prevents programmers from making a crucial leap that's needed to become an experienced programmer. The resistance to use libraries (or to split your code into separate libraries) is a sign of a fundamental problem that'll keep you thinking (and coding) like an inexperienced programmer forever.
An inexperienced programmer is excited to see the features BYOND provides. They take procs like view(), locate(), and step() and use them to make parts of their game. They directly apply DM's built-in procs to do what they need. For example, an inexperienced programmer would write code like this:
An experienced programmer doesn't rely on BYOND's features. They implement the features they need for their game. While these features may be implemented using DM's built-in procs, there is a difference. An experienced programmer would write code like this:
The experienced programmer first thinks "I need a proc that returns a list of targets". The inexperienced programmer thinks "I can use oview() to find the targets". While the inexperienced programmer isn't wrong, they've limited themselves to doing only things that DM can easily do for you. They'd be lost if they wanted to make the attack only hit mobs in a circular area because there's no equivalent of oview() to do that.
The inexperienced programmer thinks this way because they're more passive. They're not as confident in their programming ability so they don't think "what do I need to make and how can I build that?". They think "what can DM do?", not "what can I do?". They don't define the features they need, they let DM's features dictate what they're able to do.
Note: This is why experienced programmers can easily pick up new programming languages and inexperienced programmers struggle to learn one. The idea to create the get_targets() and take_damage() procs isn't a DM thing, it's a universal idea. Most of the thought that went into the first code example is DM-specific. Most of the thought that went into the second code example isn't specific to DM.
If people are left to their own devices they'll be stuck in that inexperienced mentality. It's no fault of their own - it's hard to make this leap without some help. Libraries are an opportunity to get DM users on the track to becoming experienced programmers by showing them that a program can have many layers. You can use DM to implement features and use those features to create a game.
Libraries don't have to be complex to show this - the Warps library is an example of this idea. The library uses areas to create warps. An inexperienced programmer might think that areas (or the Entered proc) are warps, but the library shows that we can use areas to create warps, then use those warps in a game.
This line that separates the behavior of an experienced programmer from an inexperienced one is subtle. The simplest I can explain it is that the inexperienced programmer thinks "what can DM do?" and the experienced one thinks "what can I do?". We can't expect that all BYOND users will correct this problem within themselves. By recognizing this problem we can design demos, libraries, and tutorials to help fix this situation.Most of BYOND's existing educational resources reinforce the "what can DM do?" way of thinking. With a better set of tutorials BYOND would be in a lot better shape.