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
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
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
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
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
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
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
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.
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?
In response to Falacy
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
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
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
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
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.
In response to Falacy
Falacy wrote:
Would you like me to explain them to you again? Though, I doubt a 4th attempt would be any more successful...

You have never attempted to explain them to me. To my knowledge, you have never attempted to explain them to anyone on these forums. In fact, you've basically tried to anti-teach inheritance and namespaces with that pathetic '''tutorial''' of yours.

Yes, those are indeed examples of your own poorly provided examples.

No, those are strawmen. I don't think you know what a strawman is. Per Wikipedia, "A straw man is a component of an argument and is an informal fallacy based on misrepresentation of an opponent's position." Let me explain why these were straw men.

Turning /gun/ammo, when /gun is parent_typed to /obj, into a /datum is no different than turning an /obj into a /mob.

The main difference here is that the /obj and /mob classes are sister classes; they derive from the same superclass. Thus, they have independent methods and variables. Using a /mob as a namespace for an /obj makes the mistake of implying it has some coincident relation, when there is none. This is why it's a strawman. You see, you're claiming that an /obj subclass has a similar relationship to a /mob as ammunition does to a gun. This is not true. Thus, you are misrepresenting my position, and many others, by making this claim. Hence, it is a strawman.

And this is to say nothing of the fact that there is a clearer, direct relation between a subclass and the 'zenith superclass' (i.e., between /gun/ammo and /datum) and two sister classes (/mob and /obj).

Oh, and the fact that you claim using parent_type "turns" one class "into" another indicates you still have no idea how namespaces are used. Thus, it appears in part you are so abhorrent to the idea because you fundamentally fail to understand what it is, and what it does. Not unlike those fundamentalist Christians who laugh at the absurdity of "a fish turning into a monkey turning into a man".

It is pointlessly confusing and non-beneficial.

It's confusing to you and appears non-beneficial to you because you are ignorant of how to properly benefit from inheritance and namespaces. Because you've never used a more complex programming language and, and hell let's admit it, because you're not a real programmer, you can't conceive of how these may be properly used.

Creating a proc that does nothing but return oview(), though fundamentally correct in more advanced situations, was lacking when it came to actually providing an example of when/why you should use the core concepts.

So, let me get this straight. You are claiming he is wrong because his example is wrong. You're claiming that he is wrong because his example was wrong, even though his actual implementation was fine? If I'm understanding you right (and it's entirely possible I'm not because your statement only barely makes sense when read a certain way), this is like claiming the Pythagorean theorem is fundamentally wrong because someone's example used an equilateral triangle.

Which is to say nothing of the fact that the relevant example was tantamount to a loaded question, and provided none of the context that Forum_account's method did, thus misrepresenting his

What appropriate language you use, your brilliance shines through. But no, I am not saying these concepts are inapplicable. Your use of them, however, is incompetent, and not applied correctly.

Please explain why, so that others may dissect your inept application and/or understanding of concepts like polymorphism, encapsulation, inheritance, and so forth.
In response to Urias
Urias wrote:
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.
It isn't a difficult conclusion to reach. I am "superior to practically everyone in this community". I am usually right, and I am not overly complaisant when everyone else is wrong. If somebody is going to post something in the tutorial section, then it should be 100% accurate, 100% relevant, and 100% beneficial to BYOND design. Though I don't agree with the primary focus of this topic (that libraries will somehow make better, more self-sufficient BYOND developers) the actual criticisms that I provided about the examples could have been easily fixed.
The biggest problem with BYOND, especially in the community/help forums, is that it is a circle of noobs "helping" noobs, which never leads to any actual improvement.

From what I can tell, you're against using parent_type, for what ever reason that may be.
Feel free to read up on why you shouldn't use parent_type
http://www.byond.com/forum/?post=302547

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.
Should I know who you are? Or are you just another noob troll who has been around for barely a month, but tells stories about BYOND's history?


Popisfizzy wrote:
In fact, you've basically tried to anti-teach inheritance and namespaces with that pathetic '''tutorial''' of yours.
The broken inheritance that parent_type provides should indeed be "anti-taught".

This is why it's a strawman. You see, you're claiming that an /obj subclass has a similar relationship to a /mob as ammunition does to a gun.
That is an accurate representation. By parent_typing your /gun/ammo to /datum, it strips it of the proper class data that you should be able to rely on.

Oh, and the fact that you claim using parent_type "turns" one class "into" another indicates you still have no idea how namespaces are used.
This is exactly what it does. By parent_typing an /obj as a /mob, you will no longer inherit /obj class data, but will instead be artificially classed as a /mob. It does not work as a namespace, like you seem to think it does, namespaces could provide additional class data, parent_type is an unnecessary full override that essentially creates an entirely new (broken) subtype within a type. A namespace is more accurately compared to a top level /datum or an entire library.

It's confusing to you and appears non-beneficial to you because you are ignorant of how to properly benefit from inheritance and namespaces.
It is confusing because /obj/X should behave as an /obj, not as a /mob. It is not beneficial because there are more practical, intuitive, and correct methods to create type paths in DM.

Because you've never used a more complex programming language and, and hell let's admit it, because you're not a real programmer, you can't conceive of how these may be properly used.
What was that you said about projecting?

You're claiming that he is wrong because his example was wrong, even though his actual implementation was fine?
I'm not saying his example was wrong, just lacking.

If I'm understanding you right (and it's entirely possible I'm not because your statement only barely makes sense when read a certain way), this is like claiming the Pythagorean theorem is fundamentally wrong because someone's example used an equilateral triangle.
If somebody is attempting to explain the Pythagorean theorem to you using an equilateral triangle, then yes, they are doing it wrong. Providing broken examples isn't the best way to teach.

Please explain why, so that others may dissect your inept application and/or understanding of concepts like polymorphism, encapsulation, inheritance, and so forth.
You want me to explain why it isn't effective to create a procedure that does nothing but return another procedure? Or why using parent_type to break inheritance isn't an acceptable practice? That was the entire point of these discussions. As I said earlier, explaining things to you for a 4th time probably won't accomplish much. Just go back and reread things if you couldn't understand them on your first attempt.
Page: 1 2 3 4