Response to Gigantic Do It All System

[Nestharus]

Just wanted to respond to this post-
http://www.thehelper.net/forums/showpost.php?p=1152569&postcount=11

and as this is a completely different topic, I believe a thread is much more appropriate ^_-.


Themis, I used to think about making a system like that myself . In fact, I even released it a long time ago and it actually worked, lol. The issue here is when you start doing systems that can handle all types and do all of this stuff, you have to sacrifice a lot for the ambiguity of the code. For example, using triggers to handle types, equations, this, that, and the other thing ><. You also end up having to use hashtables in the background to store references and records to various lists. All in all, the entire design becomes very sluggish and it would never be used in a good map. It might be used to quickly make something, but considering the complexities and power of such a system, I doubt it'd be even used for that.


Systems need to be type specific and need to handle very specific needs. About the lowest you can go for data structures is linked lists, stacks, queues, indexed arrays, etc . You can't make a system that handles relationships between unknown data structures and stores records of all of these relationships-

attaching var a and b to var c
attaching var a and b to var d
attaching var d to var f

etc

transferring an instance of a to f

Maintaining order of all of the above as well ><.


Do you know why you can't maintain records of all of these relationships? If you try to handle relationships that you know nothing about, you have to use methods that slow down the entire code. The code is always better written when you know what you are handling. Look at reflection in C# ><. Have any idea how slow that is? Lol.

A good rule of thumb is to only write code for stuff where you know what you are handling. If you write code for stuff that you know nothing about, then it just gives you a headache and gives people using it a headache.

The next good rule of thumb is to minimize coupling and maximize cohesion.

What this means is that you don't write code that has to be used in a very specific way (things using it then have to have a lot of work put into them to use it and maintainability over the entire map dies).

While making a system that can do everything etc can increase maintainability dramatically (you never have to make any new code, all code handles all types), the problem again is that the methods used kill your map. Would you write a projectile system using this enormous system of your friend's? I know I wouldn't write a projectile system with my AGL-T3 (previously Spawn). Why? A projectile system written for the specific unit type would be 30x faster.

While these huge systems can be like feats of accomplishments (making one piece of code work for 30 types or attaching data no matter what it is etc and having your system handle it and gets its properties like x and y coordinates no matter what it is), they kill on speed. Polymorphism can be a good thing, but it can also be a bad thing.


This is the reason why I myself put a lot more effort into developing collections for JASS rather than continuing my AGL project. Collections can be used in any situation, but they don't handle the relationships.


Don't do too much, otherwise the entire thing fails . This is a lesson I've been learning for the last year ;p.


Btw, my AGL was a highly sophisticated hasthable/trigger system. Last version I did was 2000 lines and the newest version would have been 3000. There's a reason I stopped working on it ; ).

 

[Jesus4Lyf]

>A good rule of thumb is to only write code for stuff where you know what you are handling. If you write code for stuff that you know nothing about, then it just gives you a headache and gives people using it a headache.

You've said that really well. That is a good way to know system boundaries.

>This is the reason why I myself put a lot more effort into developing collections for JASS rather than continuing my AGL project. Collections can be used in any situation, but they don't handle the relationships.

See, I don't believe a monstorous system is necessary. But I do believe you can automate a lot, with modularity. That is the wonderful thing about vJass.

It means we do not need a "do-it-all" system.

 

[Nestharus]

Yup. When entering the world of polymorphism, a lot of people see code that's almost the exact same except for the type, so they try to make it more and more ambiguous until they get into those huge frameworks that handle all of the relationships and types. It almost turns into Lisp gone bad, lol.


Oh, and another issue with these do it all systems that I failed to point out. When you do it all, you have to account for all of your features with every given operation. This means if you don't need these extra operations, it just bogs down on your code for no reason, meaning you rip stuff out of the system that you actually need and throw the rest away (easier than writing it from scratch if it's complicated, but why have that huge system in the first place then? Maybe different flavors, who knows).

This is something that I came to realize while working on collections ^_^. For example, if you wanted to maintain records for quick and fast statistical analysis of a given collection, you'd have to do extra operations to update those records, which would probably be stored in a hashtable. This makes the overall collection much slower than it has to be, and it'd be slower than any regular collection. This means that you should only do operations when you need to do them, which brings us to the point of splitting functions up into many functions. However, splitting functions up into many functions isn't a good practice in JASS for obvious reasons ^_^, which is why cJASS has actually been a blessing to me as I've been able to split them up into many definitions rather than functions and just use parts and pieces ;D.


Really, understanding the true art of programming is a long journey as there's just so much ^_^. A lot of good programmers always say, "simplicity is man's best friend." This is entirely true for all programming languages and is really what everything boils down to ; ), but understanding the full meaning of that message is difficult unless you've been through it. That message only rings true to people who have been there, but people who haven't been don't really fully understand it. When people who haven't been there think simplicity, they think try to make it as easy to use as possible or w/e and try to make it as fast as possible, but this leads us to those huge do it all systems.

Really, keeping it simple as possible just means a simple solution, not simple to use . Simple solution means no extra operations. Simple solution also automatically makes it easy to use .

By just keeping in this mindset, by just looking for the simplest possible solution, 99% of the time that's the solution you really want .


No, I don't think anyone who understands this would ever use a system that handles relationships, or a system that does code of different types (units and items and this and that) or etc .

The thing we should be focusing on are implementing common collections into JASS in a highly efficient way rather than working on these huge pointless systems ^_^. Linked Lists aren't enough, because sometimes you only need to go forward or backward. There actually needs to be things out there that specifically do a Stack, a Pool (recycling), a Queue, a Linked List, or even a basic collection (indexed array).

This is what I've come to realize .

Once all of this is done, global map pool standards so that systems can share them (recycling for common types)

Then very very simple data attachment for handles (array is faster than hashtable) for the common types supported by the global pools.

Finally, relationships between types (very specific), for example AIDS is specifically used to store data into units, or SUPOT is specifically used to attach a spawn to a location, or this and that. Rather than having one system being able to handle all of these relationships and having the people define the types for it (ambiguity kills), make a thousand utilities to handle different types of relationships, common solutions to common problems ^_^.


These are actually the steps I've been trying to follow ^_-. I hope Themis and your friend that you come to understand like I have what's really needed and what's really usable =).

 

[Jesus4Lyf]

Really, keeping it simple as possible just means a simple solution, not simple to use . Simple solution means no extra operations. Simple solution also automatically makes it easy to use .

By just keeping in this mindset, by just looking for the simplest possible solution, 99% of the time that's the solution you really want .


No, I don't think anyone who understands this would ever use a system that handles relationships, or a system that does code of different types (units and items and this and that) or etc .

The thing we should be focusing on are implementing common collections into JASS in a highly efficient way rather than working on these huge pointless systems ^_^. Linked Lists aren't enough, because sometimes you only need to go forward or backward. There actually needs to be things out there that specifically do a Stack, a Pool (recycling), a Queue, a Linked List, or even a basic collection (indexed array).

This is what I've come to realize .

I think you went off the rails from your first wink to your last, aside from that, yea.

Collections should just be coded by the mapper. Codewise there is no advantage to using a standard collection, it will generally be more efficient to write it yourself as you virtually said. You would write 50 different collections, then the user is afflicted with choosing one.

(If they could choose, they'd make it themself.)

 

[Nestharus]

Collections should just be coded by the mapper. Codewise there is no advantage to using a standard collection, it will generally be more efficient to write it yourself as you virtually said. You would write 50 different collections, then the user is afflicted with choosing one.

Yea, while my thoughts on the matter may be accurate, JASS doesn't include the 1001 collections while most other programming languages do. That's the major difference, meaning that'd it'd be kind of crazy to do them all and have people try to include all of the ones they may need ; o.

I suppose just doing the bare simple collections would be within reason though : ). That'd cover all of the common needs ^_^.

I myself am only focusing on-
Linked Lists
Stacks
Queues
Pools (recycle)
Basic (indexed array)

All of the others be damned ;p, lol.

 

[Viikuna]

You guys worry too much about speed. If you desing your stuff properly, speed wont be an issue.

Also the more transfer work to big bad ass systems, the less you need to type stuff in the end. In the long run, its a good investment.

Also you just cant do stuff like Blueshift (link) without a proper big and bad ass projectile system.
It might be slower, but its also damn cool.

 

[Jesus4Lyf]

>You guys worry too much about speed.
I will PROVE YOU WRONG WITH A MIGHTY DO-EVERYTHING SYSTEM!
<Starts>

 

[Lyerae]

> You guys worry too much about speed.
This need for speed is what gets us to make awesome systems, and do all these benchmarks.
Without speed, things would lag. A lot.

 

[TriggerHappy]

Without speed, things would lag. A lot.

Do you know how minimal the speed differences are?

It just makes people feel better if the are using the fastest.

 

[Hatebreeder]

Isn't New Gen and E-Gui a Do-It-All System?

A collection of smaller systems IMO is better than something big. Since one won't be using everything it has to offer no?

 

[Viikuna]

Naah. There is a difference between optimizing stuff and going crazy.



And desinging your map is more important. No matter how much you optimize, you still cant get some X amount of triggered projectiles to work without lagg.

The trick is to make that Y amount of projectiles, which are possible to handle without any lagg with some properly optimized script, to feel so cool that you dont need more than that.



You can sacrifice your codes readability and polymorhism stuff for 10 extra projectiles, but that just aint worth of it; you actually you loose more coolness than you gain.

 

[Nestharus]

Actually, you'd end up sacrificing about 60% of your projectiles if not more by using a big system instead of one designed to do projectiles.

It'd be at least half speed. My estimates put it at 1/3 of the speed ;\.

So if a 100% optimal one did 1200 homing projectiles max without lag, one that ran through a do it all would do 400 by my estimates, or around 720 if I'm being generous.

That's a pretty major dif eh? : p


A 100% polymorphic script (all types, all situations) just cannot compete because of all of the trigger evaluations involved ;| and because of hashtable reading vrs array reading for large amounts of data (arrays are 70% faster remember?)

The best method is just code it yourself, as jesus4lyf pretty much said. The reason is there'd be so many variations of a given thing that the task would be finding the right variation that you need ;p.

The almost as good method is by writing common solutions, like my example of 5 collections out of the many there are =).

The bad way is writing one solution to do them all ><.

 

[quraji]

Actually, you'd end up sacrificing about 60% of your projectiles if not more by using a big system instead of one designed to do projectiles.

It'd be at least half speed. My estimates put it at 1/3 of the speed ;\.

So if a 100% optimal one did 1200 homing projectiles max without lag, one that ran through a do it all would do 400 by my estimates, or around 720 if I'm being generous.

That's a pretty major dif eh? : p

Yeah. Myself, I estimate that a pregnant unicorn that eats an apple a day can lift about 10 million kilos, only about a third of what your average sea monster can lift, and that's only on a good day.

Seriously though, I don't know. Not all big systems are slow, not all small systems are fast, etc. It all depends on the end product (a map) anyways, you can't play a system.

 

[Jesus4Lyf]

>you can't play a system.
Hence:

MIGHTY DO-EVERYTHING SYSTEM!
<Starts>

I think I found a really good execution speed vs mapping speed (and entertainment) sacrifice.

 

[Nestharus]

Actually, a mighty do everything system would be useful in speed maps.

If production time is your concern, def yea. If quality is your concern, def no ;p.


Maybe there is a place for these behemoths, lol.


Another use would be quickly making a bundle of maps (implementing your ideas and releasing them), and then actually working on the ones that turn out well (getting rid of the huge behemoth system and replacing it with good solid code).

;o

 

[Jesus4Lyf]

>Another use would be quickly making a bundle of maps (implementing your ideas and releasing them), and then actually working on the ones that turn out well (getting rid of the huge behemoth system and replacing it with good solid code).
Now we're talking.

>If production time is your concern, def yea.
Look, some massive systems require too much time to learn and have dumb interfaces. These will not help development time. But I'm making something that should.

 

[Nestharus]

Wait, are you saying my interface for Spawn was bad??? >: O

 

[Azlier]

Well, if I can't grasp an interface, it must be terrible. And I'm quite good at making huge and overcomplicated interfaces.

 

[TriggerHappy]

Wait, are you saying my interface for Spawn was bad??? >: O

Most of your interfaces are bad.

No offense.

 

[Frozenhelfir]

A good rule of thumb is to only write code for stuff where you know what you are handling. If you write code for stuff that you know nothing about, then it just gives you a headache and gives people using it a headache.

So the truth finally comes out. You only wrote spawn to give me a ton of headaches in TH chat...