ID:307829
 
This article explains why DM libraries can greatly benefit the community. It's not just meant to convince people to use libraries, it's also meant to convince people to create and support them. Many people write tutorials but it'd be much more beneficial to write a library first, then write your tutorial about how to use the library.

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.
Lige wrote:
Personally, I only use one or two libraries.

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.

As for creating libraries and tutorials, I wouldn't place myself anywhere near being qualified for such tasks.

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.
Lige wrote:
Edit: I'll be sure to make a library one of these days so you can see why I'm confident about not being qualified.

I'll take your word for it =)

There's probably a connection between your lack of using libraries and your lack of confidence in making one. You won't magically learn to write a library just by using one but it will help. By learning how to effectively use a library you'll end up writing better code. Even if it doesn't make you able to write a complete library from scratch it'd at least make you able to write a demo about how to use the library.

Sometimes libraries aren't made for what I need

I'm always taking requests. If there's a topic you think could really use a library, let me know!
I think that's probably the most important point, there. There's a miscommunication between new developers and skilled library writers- simply put, the library writers don't know what needs to be made. Either they're not speaking up about it, or they don't know how to articulate that "this is the problem", and "this is how you fix it".

I applaud the recent efforts that have come out of the help forums, for example Forum's warp demo and lib. Good example of the new community at work.
Only time I create libraries is if I can provide features that are normally not available in BYOND or to make various tasks easier. Normally, I rarely use libraries since I like to try building my own unless I find a good use for the libraries provided here (much like your own libraries Forum_account that actually provide capabilities that can speed up production). It is a good practice as well if you're heading into C/C++ (since those languages are very dependent on library use even for the basics unless you want to spend a bunch of time trying to create your own functions).

For that reason, I say encourage library usage. :D
I've just gotten to the point where I start using libs. I have about 10 of them downloaded mostly used so I can learn new ways to do things. In the past I'll admit when I first started it was a bit too confusing trying to use most libs though. Most aren't commented fairly well.

Dariuc, can you point out which libraries were poorly commented on? Perhaps we could create an updated version, or have the creator fix it.
It's been a while. I just recently got back into programming DM again last month. Before that I was gone for about a year or two. The ones I mentioned were from back then.
SqueakyReaper wrote:
There's a miscommunication between new developers and skilled library writers- simply put, the library writers don't know what needs to be made.

I'm not sure what you mean. Are there any topics in particular that need a library?

Keep in mind that using libraries isn't the solution. The solution is that people learn to look at code (and BYOND game creation) differently and get the confidence to think "what can I do?" instead of "what can DM do?". Using libraries is just a way to get people thinking this way.

Dariuc wrote:
In the past I'll admit when I first started it was a bit too confusing trying to use most libs though. Most aren't commented fairly well.

I agree completely. Most DM libraries that I download are terribly complicated. That's why I put such an emphasis on making sure mine are easy to use. With each library I try to include a very basic demo that's as small as possible - it's a good way to make sure the library remains easy to use.
In response to Forum_account (#8)
I'm not sure what you mean. Are there any topics in particular that need a library?

Poor wording on my part. What I mean is that I don't know what topics need a library or guide, so I can't make one.
In response to SqueakyReaper (#9)
SqueakyReaper wrote:
I'm not sure what you mean. Are there any topics in particular that need a library?

Poor wording on my part. What I mean is that I don't know what topics need a library or guide, so I can't make one.

In that case, if there are any libraries you often use, write a guide about them. Even a simple post explaining how you used the library in one of your projects is enough to bring attention to the library.
Forum_account wrote:
Many people write tutorials but it'd be much more beneficial to write a library first, then write your tutorial about how to use the library.

This. I am completely and utterly against this. It's all fine and good to write a tutorial about how to use your library, but doing this and only this is bad. For example, writing a tutorial on how to use a library with a hash table in it does nothing to teach someone how a hash table works or should be implemented. Similarly, teaching someone how to use a library implementing A* teaches someone nothing about how to actually write an implementation of A*.

There are very, very good reasons to write tutorials. They are useful to teach people about abstract concepts that may be hard to grasp. Writing a library that implements the abstract concept and then just teaching the library completely renders the whole point of it moot. I don't think you're being malicious with this, but I think you are being very, very naive.
In response to Popisfizzy (#11)
Popisfizzy wrote:
teaching someone how to use a library implementing A* teaches someone nothing about how to actually write an implementation of A*.

I'm not sure why you think it would.

Using libraries is beneficial not because it will magically teach you how to do something, it's good (for BYOND users) because it promotes good habits that are rare in the BYOND community. Learning to use libraries doesn't teach people how to implement anything in particular, it just teaches people how to be better programmers in general.

A tutorial that explains the A* algorithm to the BYOND community is not useful for a few reasons:

1. People on BYOND rarely implement their own search algorithms. To most people, walk_to() and step_to() are their pathfinding. You don't have to convince people that A* is better than the algorithm they use, you have to explain why they should bother to implement their own pathfinding.

2. There are plenty of tutorials available that explain A*. People can just check Wikipedia to see how the algorithm works. The problem is there's a gap between the average DM developer and someone who is capable of looking up an algorithm and implementing it. Another tutorial about the topic wouldn't bridge that gap.

There's certainly a place for the kind of tutorials you're describing but they aren't that beneficial to the BYOND community. You can talk about abstract concepts all you want but it'll go over most people's heads.
In response to Forum_account (#12)
Forum_account wrote:
I'm not sure why you think it would.

... clearly I don't think it would. This is one of hte things I'm criticizing you for.

Using libraries is beneficial not because it will magically teach you how to do something

I'm getting the feeling that the whole point of my post went directly over your head. Either that, or you're deliberately twisting my words for some bizarre end.

2. There are plenty of tutorials available that explain A*. People can just check Wikipedia to see how the algorithm works. The problem is there's a gap between the average DM developer and someone who is capable of looking up an algorithm and implementing it.

And in that gap are people who could understand it if the terminology is brought down to a simpler level, and if things are explained more clearly, using less jargon that is incomprehensible to a newbie.

Another tutorial about the topic wouldn't bridge that gap.

No, it wouldn't. But tutorials of increasing complexity may help. You're taking the route of, "Well, most of them won't get it, so I'm not going to help any of them." when there are still some who will benefit.

There's certainly a place for the kind of tutorials you're describing but they aren't that beneficial to the BYOND community. You can talk about abstract concepts all you want but it'll go over most people's heads.

So? If for everyone hundred whose head it goes over there's one that it makes use of, it's worth it. Your methodology just says, 'fuck it' to the ones who could be helped.
We could just take Forum_Account's "write libraries with the intent of utilizing the libraries" and Popisfizzy's "also teach them why you chose the code lines you did." Just have two documentation posts, one with a practical application of your library and one that shows how and why you made it. Really no need to argue.
In response to SqueakyReaper (#14)
SqueakyReaper wrote:
Really no need to argue.

That's no fun.

Part of the allure of BYOND for many of people is probably the ease of being able to develop games without needing to know how networking, direct-x, or any of that stuff works. To that end, I can appreciate forum_account's drive to create tools that are both powerful and easy to use, as that's somewhat how BYOND is.

As far as tutorials go, they're really useful, but it depends on what they are about. For instance, I think any programmer who *wants* to learn how A* works can easily research it and find a way to implement it into BYOND. The internet is full of useful algorithms and programming techniques if you look for them. There isn't much sense in trying to convert all of that material to BYOND's syntax because the people who actually *want* to learn that information can already easily interpret it. If they can't, then they're still a beginner and shouldn't be dabbling with that anyway.

The best kinds of BYOND tutorials are those that help beginners get familiar with the tool-set/language. The rest have already been written.
It makes more sense to gear tutorials to the people who would benefit most. The "advanced" users who I am ignoring (of which there are fewer than 10) can use non-byond resources. Someone with a firm grasp on programming doesn't need a BYOND tutorial about A*, they can use any tutorial they can find about it.
In response to Forum_account (#17)
Forum_account wrote:
The "advanced" users who I am ignoring (of which there are fewer than 10)

I want to point out the false dichotomy here: Not everyone can be grouped into 'complete newbie' and 'advanced user'.
I don't remember seeing him make only those two distinctions.
Page: 1 2 3 4