Definitely one of the biggest advantages of a scripting language. In Denizen, debugging is so ridiculously easy as there’s full console output that can automatically be saved to a colored paste bin, each command run fully described, variables filled described, etc. all in color coded output. Compare that to Java, where you get nothing but stack traces unless you specifically program in manual output wherever you think trouble might lie.
Yeah, you get stack traces which tell you what the error is, exactly where the error occurred, when it happened, and every detail possible about what was occurring when it happened. If you know how to look at a stack trace and you know your own code it is easy to debug.
1 Like
With debugging I mean no beauty, custom logging output,
I mean live/remote debugging with breakpoints, code injection, memory tree navigation in the IDE, …
That is not part of the “pure” scripting language, or?
No, it is. It’s in ruby and python.
As far as I know, Forge includes Groovy and Scala bindings (is that the right word?) so implementing either as alternatives would be (disclaimer: probably don’t know what I’m talking about) dead easy.
1 Like
@IDragonFire It’s part of the engine rather than the language. The java tools you mention aren’t part of anything, they’re entirely separate. Denizen can replicate breakpoints (queue pause) and code injection (edit the script as it runs or /ex a script command or whichever), and even memory navigation (just open the saves file!)
@RobodudeMC stacktraces tell you where the error occurred- they don’t give any hints as to why. And a lot of errors are things just not working without any stacktrace involved.
I talked about the beauty, custom logging output.
Btw, debugging in python is similar to JAVA, but it is harder not impossible
(try to debug multithreaded application)
Again, it is harder not impossible. In Java you can use Reflection, HotSwap to program a debugger.
Script language have (normally) no build in feature and must simulate it (e.g. like Denizen).
Btw. There is not the “best” thing, it depends on the usecase. For Sponge atm. JAVA is the best choice.
YES! This!
CommandHelper is MILLIONS times better than Skript.
Er… Denizen’s debug is built in, not simulated. Your Java version is simulated.
Yup.
Character Limit is so nice eh
Good point that its look’s build in…
But you cannot debug things out of your scope.
Without a compiler it is hard to debug same kind of errors,
because you can be in a unsafe context.
btw. the biggest point is the performance
There really should not be built in support for one or multiple scripting languages. The API will give plugins access to whatever they need, and installing a scripting plugin is simple enough, and allows server owners to choose what language they want, or none at all. Why delay release for everyone to support something that most people wouldn’t use?
If you want to write in pseudo code, get Skript.
If you want basically nearly all the capabilities of a plugin while still being able to change things at run time, choose the immensely more powerful Commandhelper. Seriously, want to read the NBT data from your player, save it to a file, email that file to someone, access that info from another server entirely, generate a world with the player’s login timestamp as the seed and then fly around that world on top of a fireball while throwing exploding diamonds at your friends, and then send a tweet about your armor set that cycles all the colors of the rainbow? Commandhelper can do all that while running a shell script in the background to backup your world before you spawn an enderdragon that replaces cobblestone with stonebricks. I may be just slightly biased.
Want javascript? There’s a plugin for that too.
Groovy? Commandhelper has an option for that, and I’ve heard Forge has some as well.
If you want it, download a plugin for it, but a small demographic’s preference shouldn’t bog down the entire project.
3 Likes
We are not against the plugin or idea,
but we against the integration into the SpongeAPI.
First off, I don’t believe this belongs in the Sponge API. It just doesn’t feel like something that pertains to core Minecraft mechanics, which is Sponge’s domain, if you will.
It would be absolutely great as a plugin/mod/whatever, and I would actually propose to use Groovy as a language, for three reasons:
-
It doesn’t impose much more on the JVM. Groovy is a compiled dynamic language that doesn’t have a big runtime. Most of you probably are unsure what I mean, but a runtime is basically the libraries that are loaded while your Minecraft server runs. It takes up memory, which is already being used a ton by Minecraft, and which there isn’t a lot of. Groovy is way better than Jython and JRuby in this respect.
-
It is the best language for building DSLs. Developers, see how Groovy does DSLs. Gradle uses Groovy to build a pretty awesome build tool. You can totally do the same with Sponge scripting. Groovy just has the tools to do it, unlike any other proposed language or one you make on your own.
-
It has better Java interoperability. If you’ve ever seen how Jython and JRuby’s Java imports look, I’ll save you the trouble: they suck. It’s because of the vastly different object models that Java doesn’t have, and it makes working with them a pain. Any developer would appreciate Groovy much more than Java implementations of ruby or python.
EDIT: It would probably be useful to have some examples. I ported some of Skript’s example scripts to a fictional Groovy-based DSL, just for example.
on mine of "stone" {
at player send "You just mined stone!"
}
on leftclick with "golden axe" {
// a condition:
require player have "thor" permission
// and some effects:
at target strike lightning
broadcast "Fear the mighty Thor!"
}
2 Likes
The difficulty between Java and x scripting language is subjective. Something like Skript is less verbose and has its own syntax, but you’d still be working with similar logic as you would when designing a plugin. From Skript’s page:
# This example informs the player when he mines stone
on mine of stone:
send "You just mined stone!" to player
In Java (using Bukkit):
@EventHandler // on
public void onBlockBreak(BlockBreakEvent breakEvent) { // mine
if (breakEvent.getBlock().getType() == Material.STONE) { // of stone
breakEvent.getPlayer().sendMessage("You just mined stone!"); // send "You just mined stone!" to player
}
}
For me, it is more difficult to use Skript because I have to look up Skript code. But if the logic is similar, why not take the time to learn a bit of Java and the API you’re working with, and develop uninhibited?
Since all Skript did was map to associated Bukkit API, those were probably limitations everyone had to deal with. The more that gets added to Sponge, the longer the wait between recommended builds is going to be… an embedded scripting language wouldn’t really be doing anything different than it would if it were a plugin, so that would be a little silly. 
I don’t think we should make a new language, rather implement support for JS or Python.
I’m also pretty sure somebody is planning on a ruby version.
TypeScript? Anyone?
Because Object Oriented/Statically typed is cleaner than JavaScript spam. AND, you can debug it just like java.
But then again, it’s just as complicated as java, so using it is actually worse than just writing the plugin java and not having a scripting layer in between the scripted plugin and the server.
The same goes for JS and maybe Python.
But what’s different than just letting it continue to be a plugin? Why throw another thing on the core team’s plate instead of letting the creator, the true expert on his plugin, continue his plugin as always?