Whyyy people?

[tokumei]

I've been seeing people use plugins like CommandHelper and Python Plugin Loader for the longest time to make custom plugins... Why the heck, people?

1. It's insensible to have one plugin in a different language than all of the others
   
2. Having a plugin to interpret the code of another plugin just wastes CPU time
   
3. It doesn't make any difference in the length of the code (I can code a simple plugin with one command in Java with as few lines as I could in Python, minus brackets)
   
4. Java is the language Bukkit was originally designed for, and thus is the most efficient for plugin development.
   

I'm not just some crazy person, I have tried all three ways of coding a plugin, and I lean heavily towards staying with Java.

[David]

Xeo is the pligin developer. Xeo + java, nuff said.

[redstonewarrior]

1. Not particularly. Most servers don't have skilled enough staff members to actually develop in a java environment. A python project environment is significantly easier to learn and manage than a java project environment, or any other compiled system for that matter. As far as the VM goes, all calls are resolved at init time, so the language is irrelevant.
2. You're missing the real bottleneck, but I'll answer with this: All things we script with this are snort one-shot events that are not executed repeatedly. Execution rarely happens, and quite frankly, this is not the bottleneck on minecraft servers. In this case, the wasted cycles are absolutely irrelevant to the server's performance. I think there's a nice quote about wasting the CPU's time, not the developers'.
3. It kinda does, not to mention ease of both development and modification. For most any decently sized problem, python's source will be much much shorter.
4. Languages of this type are completely interoperable without any cost of speed, provided the various concepts are handled correctly. You could write a javascript plugin and, provided a decent compiler/interpreter (rhino?), it would work just fine. The ideas behind the languages are shared once you move above C++, and there are no structural elements of bukkit that make java plugins more efficient. (You could make a C# one.) You could argue that there are optimizations in the JVM for java generated bytecode, but this is irrelevant to the task at hand (and small.)

You do have one decent point: It's a little slower (Python isn't great with that.) That is why for any events that are executed constantly, such as movement, physics, and generators, we have a tiny java plugin which then calls python when needed (currently just the generators, we'll add a physics thing if we add in command block support.)

On the whole, I disagree with your points and your leanings. From experience as an admin, python plugins are much more staff-friendly and maintainable, in addition to sufficiently speedy.

[mort96]

One major feature of Python is that if we discover a problem with a plugin, anyone who knows a bit Python can hotfix it by doing nano [path], fix the script, then just reload. No need to scp the source code over to your machine from wherever it's stored, open it in some kind of Java IDE (which you have to download and install because you've deleted it since last time), do the fix, compile, replace the faulty plutin with the new build, update the source code and then reload.

Also, what red said.

(Keep in mind, I know no Java. What I weote above is how I assume the process would be. If ai'm wrong, shoot me again, I ain't dead yet.)

[Chibill]

I for being the one who loves java likes to make bukkit plugins with python because its using jython the between ground of java and python. Also it gets confusing when you are coding mods then go to code plugins.

[tokumei]

All excellent points, amd I do see how it is easier, especially how you don't have to recompile a Python script every time a small change has been made. That makes it a good language for developing plugins, yes. BUT! I protest once more. I have had trouble with all of the different versions of Python and how some things will only be compatible with a certain version. So... Another topic for debate. ;_;

[redstonewarrior]

Bah.
~red

[Xeomorpher]

The only real versions are 2.7 and 3.3, one is a stable; it will not change, the other is a dev; it will update constantly. Whilst it does provide some incompatability, it's usually nothing I can't write a script to fix for me, and besides, using a version not likely to change will mean that our code will work for an indefinite period.

[tokumei]

And what about Jython? They don't have any stable versions for either of those. They're still at 2.5 :/

[Xeomorpher]

2.5 is literally 2.6, but without format() there are no other real changes