He's treating it as such. There are certainly intermediate users who may not understand more complex tutorials found elsewhere (for example, ones describing how to apply OO principles to code) but who would be helped by such a tutorial.
I don't see how you come to that idea since he's talking about libraries, and not fundamental principals. Unless he's making a clear distinction in his text then what you're asserting is a misconception of his intended message.

I can see where you're coming from, but he just never makes that solid statement that there are only two types of programmers.
In response to Popisfizzy (#20)
Popisfizzy wrote:
There are certainly intermediate users who may not understand more complex tutorials found elsewhere (for example, ones describing how to apply OO principles to code) but who would be helped by such a tutorial.

I'm not sure what this statement means. You're saying that there are users would be helped by a tutorial which they may not understand.

I'm just trying to find the most effective way to help the majority of DM developers. It's not surprising that the most beneficial approach is a more practical one that you're preferred approach - your posts and libraries tend to be much more abstract and much less practical.
In response to Popisfizzy (#20)
He's listing one archetype. Acknowledging that a group of people exist does not mean you automatically acknowledge only one other. 'course there can be intermediate.

It's like saying "there are only six true masters of dragon-fu". This only implies that there are tiers below them.
For once, I actually agree with fizzle.

Creating a library, and then writing a tutorial about about usage of that library, instead of teaching how to use the actual mechanics that the library provides, accomplishes nothing in the long run. If anything, it is a step away from the "what can DM do?", vs "what can I do?" mentality that you seem to be encouraging here.

You (Forum_account) probably have a skewed viewpoint on libraries; because you are the one making them, and are therefore learning all of the fundamental principles that they employ. How many of your pixel movement libraries' users do you think gained even a vague sense of how pixel movement could be implemented through DM? Now, instead of thinking "What can DM do?", they're thinking "What can this library do?". It hasn't somehow bridged a gap to "What can I do?".

Also, that code example you provided in the original post isn't great. There is no reason that users should be looking for some way to override oview() with code that uses oview() to provide the same exact functionality that oview() already provides. Same with that health reduction, though at least that is a more generalized example.
The reason you would want to create your own versions of these already existent simple functions, is to provide more substantial functionality. Like providing target filtering in a custom oview() type proc, or clamping HP, adding bonus effects, and updating HP related HUD systems when changing a HP variable.
In response to Falacy (#24)
Falacy wrote:
How many of your pixel movement libraries' users do you think gained even a vague sense of how pixel movement could be implemented through DM?

I think this is probably where you and fizzle are missing a critical point. The purpose of a library is not educate its users. The purpose of a library is to expand on the features of BYOND or provide a general implementation of a feature that is often needed.

The whole point of a library is to allow people to bypass learning or programming something. In the same way that BYOND does not teach you how to program sockets, a library does not need to teach you how to create a library.

I'll go one step further and state that I believe that the types of people who use alot of libraries are probably beginner to novice programmers, or advanced programmers who are simply trying to save time. So to F_A's point, it's critical to provide useful libraries to beginners/novices because it allows them to implement features into their game that are quite likely above their skill level. A tutorial on the inner-workings of the library is not only unnecessary, but would likely confuse somebody who just wanted to make a piece of code do something.

Also, that code example you provided in the original post isn't great. There is no reason that users should be looking for some way to override oview() with code that uses oview() to provide the same exact functionality that oview() already provides.

There is a definite reason. The reason is to make your code easy to expand on. For instance, suppose you needed to expand on the oview() procedure to only fetch players who were on the opposite team. Now you must add a line of code that says if (m.team != src.team). Suppose you had multiple procedures that dealt damage using oview. You must now add that line of code to every place where you used oview. That is how bugs creep in.
In response to Falacy (#24)
Falacy wrote:
There is no reason that users should be looking for some way to override oview() with code that uses oview() to provide the same exact functionality that oview() already provides.

You know, it's starting to become clear why you act the way you do regarding code. You don't actually understand object-oriented programming or object-oriented design principles. You treat all programming like functional programming.
The reason using libraries is important is because it shows people what you can do with DM. Most DM developers write bad code. It's not because they can't understand how to write good code, it's mostly because they don't have the confidence to do it. They don't think they can write things differently. That's the exact difference between people who think "what can I do?" and "what can DM do?". Using a library shows you what you can do. It doesn't teach you how to do it but that's a separate issue that people can figure out later.

Popisfizzy wrote:
Falacy wrote:
There is no reason that users should be looking for some way to override oview() with code that uses oview() to provide the same exact functionality that oview() already provides.

You know, it's starting to become clear why you act the way you do regarding code. You don't actually understand object-oriented programming or object-oriented design principles.

That's what this original post is about. There's a fundamental way of looking at how to program and if you don't get it, you're limiting yourself. You're never going to be able to advance past a certain point because you're just using what the language provides. You don't have the confidence to create things. This is why a lot of people can "program" with VB or C# but all they're really doing is using the GUI editor to place controls on a form and write a little code to tie it together.

This also relates to the usage of parent_type. Many developers don't use it because they don't have the confidence to change how type paths look. They look at DM passively and would rather just accept the way things are. This is also why people are hesitant to create their own datum types.
In response to NefariousDevelopment (#25)
NefariousDevelopment wrote:
The purpose of a library is not educate its users. The purpose of a library is to expand on the features of BYOND or provide a general implementation of a feature that is often needed.
That is the purpose of a library, but it didn't seem to be the point FA was trying to make here. It sounded like he was saying that using libraries will somehow make people better programmers, and rely on themselves more than they rely on built-in systems. Which sounds backwards.

There is a definite reason. The reason is to make your code easy to expand on. For instance, suppose you needed to expand on the oview() procedure to only fetch players who were on the opposite team. Now you must add a line of code that says if (m.team != src.team). Suppose you had multiple procedures that dealt damage using oview. You must now add that line of code to every place where you used oview. That is how bugs creep in.
That was my point, and why FA's examples were lacking.
proc/CustomOview(var/dist,var/atom/center)
return oview(dist,center)

proc/PointlesslyModular(var/dist,var/atom/center)
return CustomOview(dist,center)
There is no reason to design 5,000 procs that all provide the exact same functionality. If anything, the point of procedures is to avoid rewriting redundant code.

Forum_account wrote:
This also relates to the usage of parent_type. Many developers don't use it because they don't have the confidence to change how type paths look. They look at DM passively and would rather just accept the way things are. This is also why people are hesitant to create their own datum types.
Using parent_type to make your code unintuitive and confusing is in no way similar to utilizing actual top level datums. Also, if parent_type type methods weren't used to split the core atom types away from their full paths, people would probably have a better understanding of datums as a whole.
In response to Falacy (#28)
Falacy wrote:
There is no reason to design 5,000 procs that all provide the exact same functionality. If anything, the entire point of procedures is to avoid doing just that; rewriting redundant code.

I agree with you there =). We're probably looking into forum's example too far, though. I think he was just trying to illustrate a train of thought. Probably, a lot of experienced programmers try to think a couple steps ahead and create procs the way F_A showed in order to expand on them later/have better object oriented design.
The difference between the code examples in the original post is that the inexperienced user thinks "how can I use DM to create this special attack?" and the experienced user thinks "The special attack needs to get a list of targets and inflict damage, so I'll create procs to do those things and use those procs to implement the special attack". This is a fundamentally different way of thinking. The inexperienced user isn't likely to ever make the leap to think the other way on their own - they're just happy they figured out they could use oview(). They don't think of implementing intermediate features with DM.

Using libraries shows new users that that's how you can (and should) program. The libraries implement features in DM that the programmer can use in their project. It doesn't teach people how to actually create these features, but it shows them the good design principles behind how you should implement things. Most BYOND users don't understand this and, with the current resources, they never will. This is why people have been trying to learn DM for years and they still don't get it.

The reason why the second code example is better is because the developer is in control of how it works. The special attack uses proc names they defined. It makes more sense that get_targets() gives you a list of targets than using oview(). It is also more flexible. If you need to do some filtering on the list of mobs (ex: filter out dead mobs) you can easily update get_targets() to make this change. You don't have to udpate every attack that uses oview(). It would also make it easy to change the shape of the range you're checking for targets (ex: a circular range instead of a square one). Putting the code to get a list of targets in one place, as opposed to putting it inline in each proc that needs to get targets, is a good design that DM newbies aren't likely to come up with on their own.
In response to Forum_account (#30)
Forum_account wrote:
The difference between the code examples in the original post is that the inexperienced user thinks "how can I use DM to create this special attack?" and the experienced user thinks "The special attack needs to get a list of targets and inflict damage, so I'll create procs to do those things and use those procs to implement the special attack".
Except, you still used DM for everything. You may have created your own procs to perform these simple functions (which is the correct way to go in more advanced situations), but you're still just using oview() and basic subtraction in your extended example.

Using libraries shows new users that that's how you can (and should) program.
How do you figure this? The use of procedures created by other people in a library is no different than the use of BYOND's built-in ones. Are you expecting people to actually read the libraries, and learn the proper setup from the code within the library? Because I doubt that happens very often, if ever.

This is why people have been trying to learn DM for years and they still don't get it.
That is mostly due to BYOND's primary teaching resource, the "blue book", being poorly written and failing to teach people how to practically implement anything. The "experienced" programmers seem to use that as their goto resource when directing new users, which isn't helping.

The reason why the second code example is better is because [...]
Those reasons are good in concept, but you forgot to include them in your actual example.
using good libaries takes out HUGE chunks of work for the developers who are both experienced and inexperienced and greatly increases the possibility that their games will be playable at some point

I use forum account's pixel movement, map instancing, and hud groups libraries in Epic. there's no reason to make anything from scratch if you use a library and get the exact same functionality

not sure if that's what this flame war is about but thats my opinion on libs
In response to Yut Put (#32)
Yut Put wrote:
I use forum account's pixel movement, map instancing, and hud groups libraries in Epic. there's no reason to make anything from scratch if you use a library and get the exact same functionality
There are reasons; you have more control over the systems, a better understanding of them, and get some general experience by creating them yourself, among other things. There is also the issue of: Did you set out to make a game that just happened to have all of those features, or did you see FA's libraries, and design your game around those? That seemed to be the focus of this topic; that libraries will somehow make people better, more self-sufficient programmers.

not sure if that's what this flame war is about but thats my opinion on libs
Every discussion on BYOND is considered a flame war?
being lazy isn't bad if you're a programmer... that's why we make modular systems that can easily be expanded upon in the first place. hell if i wasn't lazy my game wouldn't even have a hub right now lol

and i have all the control i want over the systems. i often go and make alterations to forum_account's libraries where i see fit. but making them from scratch is just a waste of time.

And i didn't design my game around F_A's libraries. i wanted smooth pixel movement with features that would make game development easier, and he had that. i wanted easy to use and efficient map instancing(i actually requested it), and he had that. look at other games made using his libraries- like bravo1's stuff.

I can make the things he offered. i've done it before, and its pretty damn obvious that i know how to program competently. when i worked with ExPixel, we'd have certain things that we made on our own which we carried between different projects just to save time rather than rewriting the same code over and over again. i'm 100% sure you do that too

not every discussion on byond is a flame war, just the ones between you and [insert person with an opinion that has minute flaws here]
In response to Falacy (#28)
Falacy wrote:
There is no reason to design 5,000 procs that all provide the exact same functionality. If anything, the point of procedures is to avoid rewriting redundant code.

Once again, it's very clear you don't actually understand anything about the object-oriented design model, or else stuff like this (though one that isn't just a strawman that you can knock down to feel good about yourself, as you often do) would make a lot more sense.
In response to Popisfizzy (#35)
Popisfizzy wrote:
Once again, it's very clear you don't actually understand anything about the object-oriented design model, or else stuff like this (though one that isn't just a strawman that you can knock down to feel good about yourself, as you often do) would make a lot more sense.

Whatever you say, trollbait mcfizzle. You constantly accuse me of not understanding things that I clearly have a better grasp on than you ever will. You accuse me of using "strawmen", when I am using examples that other people have initially provided (half the time, your examples). The incompetent, technically inapplicable knowledge that you keep trying to flaunt speaks for itself.
Stick with making those libraries of yours. They are the perfect example of the aforementioned knowledge that you keep trying to pass around; nobody cares, it isn't relevant, its generally wrong, its pointlessly technically, and apparently it provides your ego with a false sense of intelligence.
In response to Falacy (#36)
Falacy wrote:
Whatever you say, trollbait mcfizzle. You constantly accuse me of not understanding things that I clearly have a better grasp on than you ever will.

You have no idea how to use inheritance or encapsulation.

You accuse me of using "strawmen", when I am using examples that other people have initially provided (half the time, your examples).

Falacy wrote:
proc/CustomOview(var/dist,var/atom/center)
return oview(dist,center)

proc/PointlesslyModular(var/dist,var/atom/center)
return CustomOview(dist,center)

Falacy wrote:
obj/MyObject
parent_type=/mob

The incompetent, technically inapplicable knowledge that you keep trying to flaunt speaks for itself.

Are you saying that object-oriented philosophy and design principles are 'incompetent' (????), inapplicable knowledge? So, you think that OO design does not apply? God, you are one hilarious mother fucker. The court jester without the wit.

nobody cares

Right: 1, Wrong: 0

it isn't relevant

Right: 1, Wrong: 1

its generally wrong

Right: 1, Wrong: 2

its pointlessly technically

Right: 1, Wrong: 3

and it apparently provides your ego with a false sense of intelligence.

Projection once again proves hilarious.
In response to Popisfizzy (#37)
Popisfizzy wrote:
You have no idea how to use inheritance or encapsulation.
Would you like me to explain them to you again? Though, I doubt a 4th attempt would be any more successful...

* Examples *
Yes, those are indeed examples of your own poorly provided examples. Turning /gun/ammo, when /gun is parent_typed to /obj, into a /datum is no different than turning an /obj into a /mob. It is pointlessly confusing and non-beneficial.
Creating a proc that does nothing but return oview(), though correct in more advanced situations, was fundamentally lacking when it came to providing an example of when/why you should use those core concepts.

Are you saying that object-oriented philosophy and design principles are 'incompetent' (????), inapplicable knowledge? So, you think that OO design does not apply? God, you are one hilarious mother fucker. The court jester without the wit.
With such offensive language, your brilliance shines through. But no, I am not saying these concepts are inapplicable. Your use of them, however, is incompetent, and not being applied correctly.
In response to Falacy (#36)
Falacy wrote:
You constantly accuse me of not understanding things that I clearly have a better grasp on than you ever will.

I think I'm starting to see why you are looked down upon in this community. The average human-being can come to a simple conclusion about you: you're a self-centered asshole who thinks he's always rational(even when you are blatantly erroneous) about every thing in every way and thinks that he is superior to practically everyone in this community.

You accuse me of using "strawmen", when I am using examples that other people have initially provided (half the time, your examples).

You are not using examples that other people have provided. From what I can tell, you're against using parent_type, for what ever reason that may be.

The incompetent, technically inapplicable knowledge that you keep trying to flaunt speaks for itself.

Incompetent: You lack the ability to act mature, you are in capable of using parent_type, and you are not qualified to be calling yourself "the best developer in this community". The reasons behind(besides the evident) you getting banned once every what? 2-3 weeks? speaks for itself.
Page: 1 2 3 4