Toadfish wrote:

It has taken me about 15 minutes to understand how Forum's map library works from the documentation (incidentally, Forum, should document that maps.copy() actually returns the MapBase.make()).

Sounds like you've already run across issues with it, and probably haven't even made heavy use of it, if any at all. These are the kind of issues that an experienced developer should be expecting, and why they should know to avoid libraries, especially BYOND libraries.

Coming up with an elegant API for this kind of thing, implementing it and testing it for bugs would've taken me a couple of hours at least and in all probability I would've ended up with an inferior product.

If you're expecting an inferior product, then you shouldn't just be plopping other peoples work into your game, but instead focus on being able to create the best possible product yourself. As for it taking a couple of hours, that isn't much in the long run of creating a game, and it will leave you with a perfect understanding of the systems, making all further involvement with them smoother, possibly saving you time in the long run, especially if you run into any unexpected fails with the library.

Were I a game developer, I would've preferred to spend that time designing my next dungeon.

Personally, I don't enjoy creating such content, and would much rather spend time programming my own dynamic dungeon generator, or something along those lines.

Sounds like you've already run across issues with it, and probably haven't even made heavy use of it, if any at all. These are the kind of issues that an experienced developer should be expecting, and why they should know to avoid libraries, especially BYOND libraries.
If you're expecting an inferior product, then you shouldn't just be plopping other peoples work into your game, but instead focus on being able to create the best possible product yourself. As for it taking a couple of hours, that isn't much in the long run of creating a game, and it will leave you with a perfect understanding of the systems, making all further involvement with them smoother, possibly saving you time in the long run, especially if you run into any unexpected fails with the library.

I've run across an issue with the documentation being unclear, but I don't think it's an issue with the library. The fact map.copy() returns MapBase.make() is not a problem (it's the only way the proc will make any sense!).

Now, yes, you are correct. I haven't used it in a game, so maybe I'll run into issues which I haven't thought about yet. However, I am just as likely to do that, if not even more likely, with code I write on my own. Forum devoted much more thought to his library than I would devote to my own equivalent if I just needed to get some dungeon instancing system going on. So I trust he's already accounted for a lot of issues I can't even imagine at this point.

It's not that I can't one-up the library (maybe I can't, maybe I can), it would simply take me a nontrivial amount of time and brainwork, resources which I would rather spend on something else. It's not even an issue of knowledge, I know how the library works. It's just about coming up with an API that makes sense and debugging, debugging, debugging.

Personally, I don't enjoy creating such content, and would much rather spend time programming my own dynamic dungeon generator, or something along those lines.

That actually sounds pretty fun, you know? I think I'd want to create my own dynamic dungeon generator as well, instead of using a library. But there's some features I don't like creating (I don't want to implement A* pathfinding for example. I know how, I did it before. It's just tedious). So I use a library for those and get to jumpstart my magnificent 100-floor underground metropolis generator.

Kinda sounds like you're suggesting all of us invent our own wheels Falacy.

This is the kind of thing the Javascript guys went through about 5 years ago I'd say, as they were typically one-man band development teams, like BYOND projects often are (same goes, the access controls on code and potential to side-effect is not too dis-similar to DM). Also, a surprising number of semi-professional Javascript types were fairly incompetent at Javascript in 2005, as we had a big old surge in demand for the skill and people switched to where the money was.

To hopefully save about 50 posts, I shall likn a similar discussion had in Javascript circles, kicked off by someone who likes libraries. Check the comments.

http://davidwalsh.name/ 6-reasons-to-use-javascript-libraries-frameworks

Java's community, by constrast, will heavily hit you on the head for not using frameworks and libraries, as it's an industry that has 10 years of bespoke code written, and all the duplicated effort in fixing the same kind of bugs that came with that. For professional Java these days, you get ahead and get money by having a good working knowledge of Spring, JPA, Java EE stacks etc (You'll also be about the only guy in the team that gets it, and be working on a system that's retro-fitted a library or framework on a bespoke design, so good luck there).

When using a library the only concerns I can think of are:

1. How well it's made.
2. How actively it's maintained.
3. How well documented it is.
4. How active its community is (how easily you can ask/get help from another user)

These are legitimate concerns but they don't make a case for never using libraries.

You're not going to find many people with this same idea that libraries make you lazy and deprive you of learning things. No Java developer will tell you "if you use Java's list object you'll never learn how to make your own" because real programming is about using lists, not implementing them.

Falacy wrote:

Those in support of libraries also seem to agree that libraries should only be used by already competent developers who have a full understanding of what the library will do and how

The full understanding isn't necessary but being competent is. Developers who aren't competent at using a language should be focusing on more basic things. The full understanding might be beneficial but often isn't. There's nothing wrong with using an encryption algorithm without knowing how it works. Knowing that you can encrypt data to protect it and knowing what algorithm to use are more important than knowing exactly how the algorithm works.

Edit: I had an idea for an analogy but I'm not sure how well it'll work: Libraries are like machines and programmers are like mechanics.

Knowing how to use a car (turn it on, steer, gas/brake, etc.) doesn't make you a mechanic. A mechanic doesn't need to know how every piece of machinery works. They usually focus on something specific (airplanes, cars, sometimes even certain makes or parts of cars).

Knowing how to use a library (call its functions, output the result) doesn't make you a programmer. A programmer doesn't need to know how every piece of code works. They usually focus on something specific (web development, games, applications, databases).

I'm not sure why, but Falacy assumes that using libraries means that people will only know how to use libraries (which means they're not really programmers). In fact, most people use libraries because they're already programmers - they did their time learning the basics and don't want to waste their time on little details.

An interesting side-node here is that DM's built-in functions can be considered a library. Just knowing how to use step() and locate() doesn't make you a programmer. The people who focus on just learning the DM language and claim to be proficient because they know how to use these built-in procs, they're not really programmers.

I actually remember back when I was quite the newbie with DM, still getting the hang of the language, I hardly knew what a library was, much less how to use it. I don't know when exactly I caught on, but I never did realize you could check the box and then start calling procs from inside that file.

Libraries aren't taught at a very detailed level to new developers, unless they hear about them and specifically seek out information on libraries.

As such, a good amount of those who know how to use libraries have at least a decent grasp of DM, and while they may not be as competent as is spoken of here, they will get there by continuing their studies.

I never stopped trying to learn new things in DM, even after whenever it was I learned about libraries. I realized how helpful they could be, but it still took a while to see which libraries where the good ones, and a bit longer for my undeveloped knowledge to grasp them.

However, I have come far since then, and I'm sure I'm not the only person here with a story similar to this. We got through it just fine.

Forum_account wrote:

1. How well it's made.

And how do you plan to determine this? By reading through the entire source code of the library? That seems counterproductive.

2. How actively it's maintained.

Very few BYOND libraries are actively maintained. From the look of it, only yours, and the ones LordAndrew took over.

3. How well documented it is.

This varies, and can be completely different for every library, so I'm not sure how valid of a point it even is...

4. How active its community is (how easily you can ask/get help from another user)

Even the most actively used library will not have the same community as DM itself, so libraries automatically fail this requirement in all cases. If anything, they have the exact opposite effect; people asking for help in public areas, and the general community there having no clue how to use a specific library to accomplish some common feature.

I'm not sure why, but Falacy assumes that using libraries means that people will only know how to use libraries (which means they're not really programmers). In fact, most people use libraries because they're already programmers - they did their time learning the basics and don't want to waste their time on little details.

Flip every accusation made there, and it might be believable. I don't assume that, nor do I even think it is true. Putting effort into learning how to use a library takes almost as much effort as just creating the systems yourself, one of my many many points against them. They also vaguely teach core practices, but leave out important details. Most people who use libraries are NOT already programmers, at least not already competent programmers, and they don't use libraries because they want to save time, they use them because they lazily want everything done for them and/or have no clue how to do it themselves.

Looking back, this is a bit of a trick question.

Not really, the average BYOND users are just that, what make up majority of the community. You have to assume they also make up majority of the people using libraries. Your Map Instancing library, for example, has 250 downloads. I seriously doubt there are that many competent developers on BYOND, or even a 10th that many.

Lugia319 wrote:

Oh great Falacy, teach us all to be better programmers, so that we may better understand how awesome it is to bask in your glory.

Here you go http://www.byond.com/forum/?post=292504

Falacy wrote:

Putting effort into learning how to use a library takes almost as much effort as just creating the systems yourself, one of my many many points against them.

This seems to be the crux of your argument (as the other points depend on specific instances of libraries / users), and I have to say that I generally disagree with it. Any library worth using would take far longer to design, program, and debug your own version from scratch than it would to read and understand the documentation.