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:
mob
proc
special_attack()
for(var/mob/m in oview(3, src))
m.health -= 10
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:
mob
proc
special_attack()
for(var/mob/m in get_targets(3))
m.take_damage(10)
get_targets(radius)
. = list()
for(var/mob/m in oview(radius, src))
. += m
take_damage(d)
health -= d
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.
Out of curiosity, is this because...
1. You haven't found libraries for the things you need to do?
2. You didn't look for libraries on those topics?
3. You prefer to write everything yourself?
There are some good libraries out there and they provide a good starting place for new users. The problem is that new users are new - they don't know about these libraries. Even if you don't use them in your own projects, it's good just to be aware of what resources are out there.
It doesn't take much. If there's a library you use a lot, write up a post about how you use it and include a little demo. Either you're qualified to explain how to use it (and the demo is beneficial) or you're not qualified (and someone else can explain what you did wrong) - either way someone benefits.
Many BYOND users treat developer resources as things you spend an hour making and never touch again. Getting involvement from other users would turn these resources into community projects. It could make a big difference.