shouldn't vjass be deprecated in favor of wurst?

[Ruke]

Shouldn't vJass be deprecated in favor of Wurst?

Resume of the thread so far:

We should because

• Wurst is an active project
• You can use version-control (in a easy way)
• Auto-complete (more features than TESH)
• Support for warnings
• Most of the important resources are already ready to use in the standard lib
• Wurstpack supports vJass

We shouldn't because:

• ...

 

[Tal'Rarity]

I am pretty sure this will be turned down quickly. . .

Lots of people still use vjass.

 

[edo494]

until Wurst is easily writable with editor open, I think not. Why would you depracete it? thats like saying: Shouldn't we deprecate Jass in favor of vJass? or vJass in favor of Zinc?

 

[Ruke]

vjass and wurst have the same goal, but one of them is not an active project (meaning no support for possible bugs).

 

[edo494]

I will ask, whats the real point of this thread? You expect diehard vJass funs to start bitching on you?

How many bugs does vJass have exactly? and its source should be open, so anyone could pick it up and work on it again.

Same goal? and? thats not enough to deprecate. Thats like deprecating all DDSs but one, because they all have the same goal(Provide a Generic Unit Takes damage event)

 

[Ruke]

calm down, or i will not answer your questions/arguments anymore. we're here to talk nicely.

How many bugs does vJass have exactly?

as any other software, it is not perfect, so there should be quite a few.

and its source should be open, so anyone could pick it up and work on it again.

did you check the source code?, i mean, i don't have anything against vexorian (i like him actually, he contributed a lot in wc3) but god, that is a real mess.

Same goal? and? thats not enough to deprecate. Thats like deprecating all DDSs but one, because they all have the same goal(Provide a Generic Unit Takes damage event)

what is wrong with deprecate all but one? (actually hiveworkshop encourage this xD)

 

[edo494]

because different DDSs provide different perspectives and approaches to the problem

just as much as vJass and Wurst provide different approaches to the same thing. You know not everyone is fond of tab-indended language(me including), but on the other hand people can be uncomfortable with way Jass is typed the same as the ones with Wurst. But why limit people to one? We could also have only one working programming language, but we have tons of them. Different people like different coding style, and no single language can please them all.

I havent seen the Source

Also dont forget that Cohadar did some work on vJass too.

There should be, but if you cant find any there are none visible, hence no problem.(Imagine I have map that has brokenly overpowered item placed at the top of a peak that is unreachable. Since noone can get it, it is not really a problem, but still it is there and exists in the game file)

 

[Ruke]

because different DDSs provide different perspectives and approaches to the problem

just as much as vJass and Wurst provide different approaches to the same thing. You know not everyone is fond of tab-indended language(me including), but on the other hand people can be uncomfortable with way Jass is typed the same as the ones with Wurst. But why limit people to one? We could also have only one working programming language, but we have tons of them. Different people like different coding style, and no single language can please them all.

i don't like it either (i hate python-like syntax actually), but there's jurst now.

Also dont forget that Cohadar did some work on vJass too.

nobody uses it though XD!

There should be, but if you cant find any there are none visible, hence no problem.(Imagine I have map that has brokenly overpowered item placed at the top of a peak that is unreachable. Since noone can get it, it is not really a problem, but still it is there and exists in the game file)

as i mentioned, it's a dead project. having a dead project as standard cannot be good at all.

i'm not saying "remove all stuff done in vjass", i'm just proposing to deprecate it, where you could still use it, but it is not recommended.

 

[Daffa]

I don't think it's such a good idea for now, unless people switch between VJass and Wurst (and I mean, LOTs of people), then we can try proposing such idea.

Taking the source code of VJass is a good idea IMO.

 

[moyackx]

I wrote a long thing about the inconvenient of imposing modding styles in moddable games when is actually the community which decides what's best for them and not a few people. I think you were straight in your question and the answer must be in the same way:

NO. A very bad idea.

And yes, I'm back... from the ashes...

 

[Ruke]

Why is not recommended vJASS? You can do many things with it in an easy way than simple JASS.

Ahhh, yes, Wurst does the same.... with a little less writing, both does the same thing, both have the same purpose but this is a way to impose the Wurst way, and I believe imposing is not the way.

This is a game, we enjoy the act of making maps & mods, and you have to deal with the fact that a game / mod development must avoid impositions and forced deprecations just because some of "old jassers" believe that wurst is cool.

vjass is dead, has no support at all and it's hard to maintain (see source-code).
i'm not proposing deprecating vjass in favor of wurst because it is "cool". it have been proven to be a solid/active project.

And to be honest, wurst way for developing code is far less comfortable that vJASS. Using Eclipse is the benefit and the worst disadvantage at the same time because it has to work as a total external thing in order to make a little bit easier to make wc3 scripting

to me, best decision ever:

+ you can use version-control (in a easy way)
+ autocomplete
+ warnings
+ all features of eclipse

And the fact you have and imposition attitude, that doesn't help.

i'm not forcing anything. i asked if it should be deprecated. now i'm answering to your arguments and giving my point of view.

 

[moyackx]

to me, best decision ever:

+ you can use version-control (in a easy way)
+ autocomplete
+ warnings
+ all features of eclipse

That's the point, this and more are your benefits and are solid arguments for you and for the small amount of wc3 modders that use your way, but for the other big amount of people... MANY many people, those features are meaningless because they're no coders.

And the worst thing is that it doesn't happen to wurst, it happened to vJASS too since it started. Therefore, with that kind of proposals you're moving in the same direction that did vJASS.

Seriously, please stop this thread. It's not proposing something useful to the wc3 modding community.

 

[Ruke]

That's the point, this and more are your benefits and are solid arguments for you and for the small amount of wc3 modders that use your way, but for the other big amount of people... MANY many people those features are meaningless.

maybe on "you can use version-control (in a easy way)", but the other 3, come on...

Seriously, please stop this thread. It's not proposing something useful to the wc3 modding community.

no. but thank you for your messages.

 

[pred1980]

+ you can use version-control (in a easy way)
+ autocomplete
+ warnings
+ all features of eclipse

That features you can also use if you choose "vJass". You just have to put all your triggers out of the WE and import (//! import) them.

That's it! So you can write "vJass" with all those features.

 

[bhusta]

haha, this thread makes me smile.
It is so funny seeing vJass people desperately trying to defend themselves.
But I have to agree with them, this thread won't come to a meaningful end.

Nevertheless, I personally recommend Wurst for every project that has more then one coder. Once, you started with Wurst, all other languages start to look like cancer. And the gitHub implementation is just awesome. There are so many features like closures and compiletime functions that also never make me go back. Maybe I'll do a tutorial for some of it but that does not belong in this thread and vJass is still the leading language here.

Also the spell section isn't fit for Wurst yet, because you won't find any Wurst code in a test map. As long as it is not clear how to do that Wurst is limited to the text bound resource section and new coders won't look there in the first place.

 

[pred1980]

In my opinion it's too late for Wurst. The community has become very small over the years.

I wish that Wurst had been published earlier.

 

[Zwiebelchen]

The problem with Wurst is only that most code ressources are still JASS and vJASS only.

And that I am too lazy to recode all my systems to Wurst. Otherwise I would have made the switch already.


As long as there's almost no content for Wurst, Wurst's popularity will be low. But low popularity also prevents more content. It's a downward spiral.

 

[pred1980]

And that I am too lazy to recode all my systems to Wurst

or in other words... it's too much work and needs much time nobody have.

 

[bhusta]

The problem with Wurst is only that most code ressources are still JASS and vJASS only.

And that I am too lazy to recode all my systems to Wurst. Otherwise I would have made the switch already.


As long as there's almost no content for Wurst, Wurst's popularity will be low. But low popularity also prevents more content. It's a downward spiral.

The problem with people who don't know Wurst is that only that most of the important ressources are already ready to use in the standard lib.

And that people are working on an auto translator from vJass to Wurst (it was in a discussion a few month ago I don't know if this is still up-to-date).

It is true if you are saying there is almost no content for Wurst in case of fancy spells, but most of the important systems are already ready to use just by starting Wurst.

I have to admit that I am exaggerating but there is a growth of interest about Wurst and the existence of this thread is proof enough.

 

[moyackx]

I have to admit that I am exaggerating but there is a growth of interest about Wurst and the existence of this thread is proof enough.

This thread is a proof that wurst fans are desperate to make the language popular.

 

[bhusta]

This thread is a proof that wurst fans are desperate to make the language popular.

You have a very limited view about what is going on. Please try to be a little bit open minded. I look at both sides and I admit that it is not an omniscient perfect coding revolution. It is a development of coding, made by professionals. The development can be followed by everyone on gitHub and peq and frotty post periodically news here on the hiveworkshop to keep everyone updated. And they are really open for suggestions.

You do a lot for the vJass side which is also awsome and I respect that. I whish that WurstWE could have a few features you present on blizzardmodding. But the benefits which come by using eclipse are not outdone by your features from my subjective view.

That this language is not that popular at the moment is no secret. The released Wurst version is not even 1 year old and vJass was the only option besides standard Jass for the last 8 years or so. But simply denying that Wurst could become the new standard is just something simple minded people could say and I don't believe you are one of them.

 

[Frotty]

Long Post incoming:

+ you can use version-control (in a easy way)
+ autocomplete
+ warnings
+ all features of eclipse

That features you can also use if you choose "vJass". You just have to put all your triggers out of the WE and import (//! import) them.

That's it! So you can write "vJass" with all those features.

Pred you are simply wrong. You kind of flame yourself in other posts too. You always whine about the shrinking community, but do nothing against it. Your map has 0 plays and yet 5 or more Bots pollute the battle.net lobby list.
Apparently you can't accept that your map sucks and therefore flame all other resources?
But enough of that.

Version-Control

Again, you along others use the arguement, that vJassers only code inside the map and don't have many seperated .j files next to their map.
Who uses the import directive? It is uncomfortable to outsource scripts in vJass.
Additionally eclipse has git built-in, no extra software or shell-knowledge needed.
Also, when using the editor you always save your map and it will always need to be commited after you tested your map.
By starting the map from eclipse the map doesn't get touched.

Autocomplete

Eclipse autocomplete is far, far superior over TESH or the newer alternative in the editing tools forum.
It is context sensitive (which means it suggests fitting stuff and not just everything),
uses a fuzzy search (which means entering .get will suggest ".getZ" as well as ".posGet" or even ".together"),
has built-in hot-doc providing documentation about even suggested function,
works for class constructors,
automatically places brackets (but only when needed),
and the main improvement is that it works with custom code (packages, globals, functions, classes, ...) and not just common.j and blizzard.j

warnings

JassHelper doesn't support warnings at all, so really, no discussions here, you are just wrong.

all features of eclipse

This is probably your worst case of being wrong.
It seems like you didn't even try or just don't know all the features of eclipse.
Going into details here would go beyond the scope of this already long post.
In summary the TESH editor doesn't even compare to eclipse.

This thread is a proof that wurst fans are desperate to make the language popular.

The Thread wasn't even started by a popular wurster and a Collaborator of the project didn't post till now.
I think it is a valid question, but of course the answer is obvious.

but for the other big amount of people... MANY many people, those features are meaningless because they're no coders.

How does this matter for the question?
Deprecated doesn't mean old resources will be deleted or anything.
It simply means, if you're a coder/content creator that requires Jass, don't use the old, partly broken, not anymore maintained, less in features - deprecated - tool, but use the new, maintained, safer, easier, faster, "better" tool for your work, as that would improve the quality of resources, help you work faster & easier, etc.

Obviously the viewpoint on "better" varies from user to user, but from a technical standpoint wurst is far ahead of vJass.
I havn't heard one technical fact as arguement against wurst, other than taste, being lazy/not open for change or similar.
Yes, wurst doesn't have many resources done for it publicly
Yes, the editor isn't supported anymore, because it shouldn't be! (The editor is only used for Terrain, as it lacks in the other features!!)

But we don't receive any issue tickets, proper feature requests or feedback.
I have yet to meet someone that disliked/changed back to vJass after giving Wurst and the workflow a serious try.

And that I am too lazy to recode all my systems to Wurst. Otherwise I would have made the switch already.

As I wrote in other posts: Features, as well as scripts can be requested in the thread or with the Issue Tracker.
The Standard Library is part of Wurst and therefore maintained by the collaborators (mostly by me).
If your scripts aren't too map-specific and could be used in other maps I might just do it for wurst.

Also, there is Jurst. It's basically wurstscript in a vJass syntax-style.
Therefore vJass libraries can be translated faster.
Nevertheless, Wurst supports vJass! It gets parsed and WurstPack even has the option to run JassHelper on the required scripts.

Apropos syntax style:
It might be different for some keyboard-layouts, but logically indention-based is the best. Why?

• The tab-button is big and easily accessible with the left hand. No shortcut is needed (unlike {}) and I don't need to type 10 different endblock-keywords again and again. But just like {} the tab can be deleted with 1 hit of backspace, unlike the endblock-keywords
• If you adhere to proper coding standards you will indent anyways, so it's natural to code this way anyways
• Wurst still supports linebreaks inside brackets, where they are mostly needed. Having code in one line with {} just decreases readability

Therefore I cannot understand the "hate" against indention-based languages, as I don't think it's rational.
I understand if it's not your exact taste, but the actual workload of typing is at least the same, mostly way less.

---------
In conclusion: Help make Wurst better (and better fit your needs) instead of discussing what's better.
We are constantly adding features, fixing bugs, improving user experience and workflow - and we are open for feedback/requests.
Not only are we doing a language, we are augmenting it with tools like an eclipse-plugin, the import/export tool, a native-java mpq implementation, object generation at compiletime, "professional" help in irc or here, open source & freeware from almost day 1, and much more.
So please, don't jump to conclusions and show some love.

 

[pred1980]

Pred you are simply wrong. You kind of flame yourself in other posts too. You always whine about the shrinking community, but do nothing against it. Your map has 0 plays and yet 5 or more Bots pollute the battle.net lobby list.
Apparently you can't accept that your map sucks and therefore flame all other resources?
But enough of that.

WTF? I flamed? Are you studid or can't you read?

I just said, it's possible to do it... and i'm developing in this way.

Why should I say this here: "I wish that Wurst had been published earlier. "? huh???

Who flamed Frotty? And btw, all bots are offline cuz Battle.net is full of bots and not enough players. Our Bots are offline since 3 months...

Btw. I support Wurst and give others to test it instead of vJass... You're such a kind of ... i dont wanne say it... sensless... just sensless -.-

 

[Frotty]

Yes, I was referring to not just the posts in this thread, obviously.
I got my Ent-Welcome-Email less than a month ago and the fbf-bots were still active then (I joined one) so 3 months cannot be true.
And yes, not enough players, but mostly because no one wants to play fbf

If you support Wurst, why are you ranting about it?

 

[pred1980]

Check your PM... this is not the place for such a kind of discussion!

 

[Chaosy]

I tried it, never came to like it. I'd say no if possible. Not that my opinion is highly valued anyway

 

[sethmachine]

I haven't looked at Wurst very much, so I have little to add about whether vJASS should be deprecated in favor of it.

While vanilla vJASS doesn't support these features,

+ you can use version-control (in a easy way)
+ autocomplete
+ warnings
+ all features of eclipse

you can get the first two by following Nestharus' old project:

http://www.hiveworkshop.com/forums/...s-277/volunteers-needed-notepad-vjass-238264/

I myself use a version control system with my project, and it's all written in VJASS through Notepad++.

By starting the map from eclipse the map doesn't get touched.

You can start a map from Notepad++ as well (windowed mode etc.).

Who uses the import directive? It is uncomfortable to outsource scripts in vJass.
Also, when using the editor you always save your map and it will always need to be commited after you tested your map.

While you don't get any warnings, you literally just need a single line in the map that points to wherever your script is. Then you can save inside the map, or via Notepad++ (making it a true sandbox) and it will automatically compile the vJASS code.

In summary the TESH editor doesn't even compare to eclipse.

If vJASS can be made to work with Notepad++, I guess it wouldn't be too hard to get to work with eclipse? In fact I think Nestharus also worked something up for this as well.

However it is true that these features require research and some technical awareness and are not supported out of the box for vJASS (I am probably one of the few who use vJASS with Notepad++ and version control).

One of the biggest problems with vJASS is making objects. Since custom objects aren't actually a part of JASS, I guess it is not really the job of vJASS to support 'procedural' custom object generation. It's done via Lua scripts, which are *ok*, but require some outside help to make them really modular and clean (evidence enough from all the posts I've made about Lua, forcing me to pre-process stuff with Python scripts).

Does Wurst bridge this gap that vJASS never filled? A modular and unified treatment of object generation would really sell it for me.

But what I like about vJASS is that it's all text based, so it makes extending the language easy, and it's very close to JASS.

(The editor is only used for Terrain, as it lacks in the other features!!)

At some point wouldn't it be nice to provide support for procedural generation of Terrain, or at least allow for a programmatic interface for doing terrain / global object placements?

 

[Frotty]

you can get the first two by following Nestharus' old project:

http://www.hiveworkshop.com/forums/...s-277/volunteers-needed-notepad-vjass-238264/

I myself use a version control system with my project, and it's all written in VJASS through Notepad++.

I can't look at the file since it's 404, so does this support custom-content autocomplete as well? And fuzzy? etc.

Then you can save inside the map, or via Notepad++ (making it a true sandbox)

You can save and run from eclipse.

One of the biggest problems with vJASS is making objects. Since custom objects aren't actually a part of JASS, I guess it is not really the job of vJASS to support 'procedural' custom object generation. It's done via Lua scripts, which are *ok*, but require some outside help to make them really modular and clean (evidence enough from all the posts I've made about Lua, forcing me to pre-process stuff with Python scripts).

Does Wurst bridge this gap that vJASS never filled? A modular and unified treatment of object generation would really sell it for me.

Apparently you didn't read much yet or my big post.
Yes, this is a crucial part of WurstScript.
Objectcreation in Wurst ist like class Creation:
Create the Definition

let def = new UnitDefinition(NEW_ID, 'hpea')

set various properties

..setDefenseBase(armor)..setModelFile(modelPath)
..setScalingValue(scale)..setCollisionSize(collisionSize)

Done!

If the class is created at compiletime (called from compiletime-annotated function), the object will be created. From all that data then the objects wiles .w3a, .w3u etc. are created.
If you have "Inject Compiletimeobjects" enabled, those objects will automatically be imported on mapsave. (in eclipse as standard)

I recently published this package http://www.hiveworkshop.com/forums/wurst-resources-719/wurst-ability-tooltip-generator-253389/
You apply it to the Definitions and it creates a tooltip.

If you want to get more fancy, you can use Lists like in a current map I'm working on.
The user just has to create a new CreepDefinition and the object behind it is automatically generated.
The Creep-Defs are saved in LinkedLists and the ID stays the same due to the List-ordering.

It works like a charm!

But what I like about vJASS is that it's all text based, so it makes extending the language easy, and it's very close to JASS.

Well, that's one of the things we didn't like. JassHelper is just a slightly augmented search & replace tool (basically).
But syntax-wise there is jurst, which uses end-BLOCK keywords like normal Jass and vJass, so feel free using that.

At some point wouldn't it be nice to provide support for procedural generation of Terrain, or at least allow for a programmatic interface for doing terrain / global object placements?

perhaps

 

[sethmachine]

I can't look at the file since it's 404, so does this support custom-content autocomplete as well? And fuzzy? etc.

AFAIK Notepad++ does have support for custom autocompletion, but only on a local level. If you define any variables / functions inside the .j file you're working it, it will also suggest those, albeit without the parameters. So it only offers full autocomplete for the stuff in blizzard.j and common.j.

Whether it supports all that or not I think is moot, since Nestharus did in fact develop support for vJASS inside eclipse. Which would then entail all of the special autocompletion that eclipse provides for Wurst?

Apparently you didn't read much yet or my big post.
Yes, this is a crucial part of WurstScript.

Aye I remember now. I had read your post awhile back but I guess I forgot some of the details.

But what about an interface between the custom objects and the code, e.g. if I want to refer to some custom object I generated, but via its name, not its raw code?

e.g.

constant integer HUMAN_FOOTMAN  = 'hfoo'

Does Wurst automatically generate a library of constants for all the map objects? Imo they are a hundred times more readable. Again I've had to roll my own scripts to get this done.

JassHelper is just a slightly augmented search & replace tool (basically).

Which makes it that much easier to extend and understand, no?

 

[Frotty]

But what about an interface between the custom objects and the code, e.g. if I want to refer to some custom object I generated, but via its name, not its raw code?

e.g.

constant integer HUMAN_FOOTMAN  = 'hfoo'

Does Wurst automatically generate a library of constants for all the map objects? Imo they are a hundred times more readable.

No, that would be pretty pointless. If you want a list of constants you can simply copy them from the common.ai http://warcraft.ingame.de/maps/mappedia/Common.ai

The interface has to be done by you for now, we do plan some feature for it, but it already works so great that it's low priority.

If you want referencing by name, simply write a wrapper function

HashMap<int, CreepDef> nameMap = new HashMap<int, CreepDef>()
function saveUnitDef(CreepDef def, string name)
    nameMap.put(StringHash(name), def.id)

In this example the CreepDef class holds the id.

In other cases, you often don't need direkt id-referencing, like internal dummy units or waves etc.
Then you can create a List. (If you want more help here, ask)

If you#re like me and don't wanna worry about IDs, there are our ID-Generators that generated valid Ids in the same order.

Again I've had to roll my own scripts to get this done.

As for the name-referencing it's a few lines which you have to "roll out".
But again, suggestions are welcome! Use the issue tracker.
I can add those things to the standard-library if they seem useful.

Which makes it that much easier to extend and understand, no?

Maybe, but also unsafe, no optimization except 1-line-inline, relying on PJass for errors, etc.

 

[Zeatherann]

vJASS will be the 'coding standard' for as long as it is the only stable and popular 3rd party world editor. It doesn't matter what features a language has if it requires using multiple programs at once. The majority of the community doesn't see the benefit of it because they are lazy programmers. If you want your language to be more widely used than vJASS then create a 3rd party world editor to work with it and create a good map archive for use with Warcraft III. That said, the IDE for the language, as well as the lexer and 'compiler' must be well enough coded to be fast and efficient, which a lazy programmer can't do. Another thing to note is that vJASS will never be 'depreciated' because it has a decent enough IDE.

 

[sethmachine]

Using the editor I think is sub-optimal if one is developing a high quality vJASS source script for a map. Reality is once you're familiar with JASS, you know most of the (important) native functions by name, and the ones you don't can be found via autocomplete. Lastly, if you need to look up information about a function, you can just do ctrl+f on Jeff Pang's JASS manual. Very useful resource. This all comes from using Notepad++ and two .xml files by Nestharus: http://www.hiveworkshop.com/forums/...s-277/volunteers-needed-notepad-vjass-238264/

 

[Zeatherann]

Yes, I personally use Nodepad++ and normal JASS, but I'm talking about the mapping community.

 

[Waffle]

An IDE that doesn't take 2 minutes just so it can tell you you made a bloody typo is a real pain to use..

thats why i would so love if we could take everything away from the map archive and just use it as a release mechanism..

not likely that will happen tho.
and Wurst isn't vjass compatilbe.. meaning few existing maps can convert :'(

 

[Frotty]

An IDE that doesn't take 2 minutes just so it can tell you you made a bloody typo is a real pain to use..

thats why i would so love if we could take everything away from the map archive and just use it as a release mechanism..

not likely that will happen tho.
and Wurst isn't vjass compatilbe.. meaning few existing maps can convert :'(

Wursteclipse takes <1 second to show errors if you have a decent pc.
Wurstpack supports vjass.
And going away from the map archive is exactly whatb wurst is doing..?

 

[Zeatherann]

IDE's are popular because of what it stands for; integrated development environment. The keyword (hehe... see what I did there?) here is integrated, that is, only one program is needed.

 

[Deleted member 219079]

shouldn't vjass be deprecated in favor of wurst?

Yes.

 

[oger-lord]

I think the problem is that "Wurst" does not sound cool enaugh for the typical hive user.
You should have named it something like "Extreme Jass" and everyone here would want to try it.

The majority of the community doesn't see the benefit of it because they are lazy programmers.

But Wurst is the way to go when you are lazy.

 

[Deleted member 219079]

Sausage doesn't sound cool, it's DELICIOUS!

 

[chobibo]

I agree, it could. Though some "old dogs" can't learn new tricks (that's me).

 

[Vinz]

No. Everyone can have both.

 

[Deleted member 219079]

I think the problem is that "Wurst" does not sound cool enaugh for the typical hive user.
You should have named it something like "Extreme Jass" and everyone here would want to try it.

Actually he has a point here. Extreme jass, xJass / eJass would sound killers.

On topic to clarify my statement:
Wurst:

function group.printNames()
    for u in this
        print(u.getName())

vJass:

private function GroupEnum takes nothing returns nothing
    call BJDebugMsg(GetUnitName(GetEnumUnit()))
endfunction

private function PrintNames takes group g returns nothing
    call ForGroup(g, function GroupEnum)
endfunction

Wurst uses 50% less lines.
Not bad for vjass, yet

Now let's use arguments:
Wurst:

function group.printNames(string s)
    for u in this
        print(s + u.getName())

vJass:

globals
    private string s
endglobals

private function GroupEnum takes nothing returns nothing
    call BJDebugMsg(s + GetUnitName(GetEnumUnit()))
endfunction

private function PrintNames takes group g, string str returns nothing
    set s = str
    call ForGroup(g, function GroupEnum)
endfunction

Wurst uses 70% less lines.
This is the point where vJass loses its dynamism, and Wurst is superior to vJass.

I wonder if anyone can get higher percentage for Wurst ^^ nah, 70% is enough!

 

[edo494]

And what? Thats like depracating C++ just because you can write some thing in less lines of code in Java for instance. I think vJass still has its place, mainly because vast majority of the hive still uses it and vast majority of resources are in vJass(you still need to alter libs if you want to convert them into Jurst)

 

[Deleted member 219079]

You know they aren't separate languages, just syntaxes to be converted to JASS2

Edit: And I can do em all, GUI, jass, vjass, wurst. I have NOT abandoned vjass, it's useful if you wanna contribute to the masses and take part in contests..

 

[Frotty]

mainly because vast majority of the hive still uses it and vast majority of resources are in vJass(you still need to alter libs if you want to convert them into Jurst)

Wurstpack supports vJass, maybe I should add this to my signature as people seem to have stuck this in their head as counter arguement.

It simply runs Jasshelper before Wurst, converting all the vJass to vanilla Jass which Wurst can handle.
So you can freely combine your resources while trying to convert or just try out WurstScript.

This doesn't work for running from Eclipse and linux/mac users of course, since Jasshelper is an windows executable file.

 

[edo494]

They are different languages

Ah well Im not really following Wurst progress, I thought it was still at the Jurst point

 

[Frotty]

That feature came before Jurst, but okay!

 

[Zeatherann]

There are Two Points

Actually he has a point here. Extreme jass, xJass / eJass would sound killers.

On topic to clarify my statement:
Wurst:

function group.printNames()
    for u in this
        print(u.getName())

vJass:

private function GroupEnum takes nothing returns nothing
    call BJDebugMsg(GetUnitName(GetEnumUnit()))
endfunction

private function PrintNames takes group g returns nothing
    call ForGroup(g, function GroupEnum)
endfunction

Wurst uses 50% less lines.
Not bad for vjass, yet

Now let's use arguments:
Wurst:

function group.printNames(string s)
    for u in this
        print(s + u.getName())

vJass:

globals
    private string s
endglobals

private function GroupEnum takes nothing returns nothing
    call BJDebugMsg(s + GetUnitName(GetEnumUnit()))
endfunction

private function PrintNames takes group g, string str returns nothing
    set s = str
    call ForGroup(g, function GroupEnum)
endfunction

Wurst uses 70% less lines.
This is the point where vJass loses its dynamism, and Wurst is superior to vJass.

I wonder if anyone can get higher percentage for Wurst ^^ nah, 70% is enough!

The first point is ease in coding, the second is performance; what to these snippets turn into when converted to JASS?

 

[Deleted member 219079]

To be honest I've no idea about that :/ Ask someone who's been making the syntax (or language I don't even know anymore..)

 

[muzzel]

1. There are a lot more maps which remain unfinished because the maker underestimated how much work it is than maps which are completed but arent playable because of bad performance.
So: ease in coding > runtime performance

2. Usually it is a very small part of the code which takes the longest time to execute. So the biggest part isnt even performance-critical.
So: For the small, critical part you want performance, but for the big, non-critical part you want easy in coding.
Btw- this applies to most software projects, not only wc3.

3. Lots of things are just the same in wurst and vjass, sometimes wurst does some additional security checks but those have a very low impact on the performance. However, in vjass you can do extremely fast things like using custom allocation, which usually leads to ugly code but slighty (few %) more performance.
On the other side wurst has some features which are even faster than the vjass equivalents, like dynamic dispatch of class methods (vs. vjass stub methods). Also dont forget the wurst optimizer which is extremely powerful.

In short:
Wurst is overall a tiny little bit slower while increasing coding efficiency (==easy in coding) a lot.