Python3 instead of Java?

Discussion in 'Bukkit Discussion' started by gearsgod, Sep 30, 2012.

Thread Status:
Not open for further replies.
  1. Offline


    Porting the entirety of bukkit to Python is a complete waste of time - however, support for other languages for plugins (like Ruby and Python) would be very nice.

    Why are you stating your own opinion as fact? Also, (imo) you're wrong
  2. Offline


    Using the Java scripting shiz, you can write plugins in Ruby, Python, Clojure, Scala, etc.
  3. Offline


    Just leave it Java. No need for any extra hassle on the bukkit team.
    kroltan likes this.
  4. Offline


    Python is painful to program in and even more painful to maintain. Also, why do you think Python would be better for a server? Java dominates the server world... Python is a slow, unproductive, and merely ugly alternative that would make development harder for me and many others who are accustomed to the great language of Java.
    kroltan likes this.
  5. Offline


    Python is a clean, elegant language while Java is verbose. I have no idea what you're talking about.
  6. Offline


    Java is not verbose; in Java you reuse library code... if you aren't then you're doing it wrong.
  7. Offline


    You do that in python too. Python libraries are far less lower level, so they are less verbose. There's more code behind the curtain. I'm not sure if you are suggesting that Python doesn't have libraries at all.

    If you are suggesting that, I would consider writing python before making statements about it. If I sound condescending, that's how I feel right now.

    In addition, Java is just more verbose by nature. For example in Java you have to import individual classes, in Python you can import an entire package.
  8. Offline


    I have programmed in Python... I wasn't talking about particular standard libraries but 3rd-party libraries that can make things you consider "verbose" in Java to be 1 line of code and much more readable than the equivalent in Python. Java has a much MUCH better language design for developing libraries atop libraries; quite evidently Java is the perfect language to do this. That being said, Oracle has been releasing the new Java SLs with more and more helper classes that are just as readable if not more than more dynamic languages as Python or Ruby.

    The last thing you've said makes me highly doubt that you've ever delved into the uppermost surface of the Java world because Java has had importing entire packages via wildcard since the very beginning of the language...
  9. Offline


    Also, the problem with wildcards in Java is that namespace conflicts/cluttered namespace can become a major problem. In python you can rename packages you import (using import as name).

    Well, here is an example of a simple program that makes a simple GET request and printing the output. They both use the preferred library for performing such a task in both languages. (Requests in Python and Apache HTTPComponents in Java)

    The Python program is 12 lines long, while the equivalent Java program is a whopping 77. I guess this is an example of your "better 3rd party libraries that can achieve things in one line of code while being far more readable than the python equivalent"?

    Python 2.7 (requests library) - 12 lines
    import requests
    github_username = raw_input('Username: ')
    req = requests.get('{0}'.format(github_username))
    req_data = req.json
    print('Viewing information about {0}\'s github account:'.format(github_username))
    for key, value in req_data.iteritems():
        key_friendly = (key.replace('_', ' ')).title()
        print('    - {0}\n    {1}'.format(key_friendly, value))
    Java 7 (Apache HTTPComponents library + jsonlib library) - 77 lines
    import java.util.Scanner;
    import java.util.Arrays;
    import java.util.Iterator;
    import org.apache.http.HttpEntity;
    import org.apache.http.HttpResponse;
    import org.apache.http.client.methods.HttpGet;
    import org.apache.http.impl.client.DefaultHttpClient;
    import net.sf.json.JSONObject;
    import net.sf.json.JSONSerializer;
    public class Request {
        public static void main(String[] args) {
            Scanner rawInput = new Scanner(;
            System.out.print("Username: ");
            String githubUsername =;
            DefaultHttpClient httpClient;
            HttpGet httpGet;
            HttpResponse res;
            try {
                httpClient = new DefaultHttpClient();
                httpGet = new HttpGet(String.format("", githubUsername));
                res = httpClient.execute(httpGet);
            } catch (IOException ex) {
            String jsonString = "";
            try {
                HttpEntity entity = res.getEntity();
                BufferedReader in = new BufferedReader(new InputStreamReader(entity.getContent()));
                String tempLine;
                while ((tempLine = in.readLine()) != null) {
                    jsonString += tempLine;
            } catch (IOException ex) {
            JSONObject json = (JSONObject) JSONSerializer.toJSON(jsonString);
            Iterator it = json.keys();
            System.out.println(String.format("Viewing information about %s\'s github account:", githubUsername));
            while (it.hasNext()) {
                String key = (String);
                String value = json.getString(key);
                String[] notWhiteSpace = new String[] {".", "/", "\\", ":", "%", "$", "#", "@", "!", "^", "&", "*"};
                char[] keyChars = key.toLowerCase().toCharArray();
                boolean found = false;
                for (int i = 0; i < keyChars.length; i++) {
                    if (!found && Character.isLetter(keyChars[i])) {
                        keyChars[i] = Character.toUpperCase(keyChars[i]);
                        found = true;
                    } else if (Character.isWhitespace(keyChars[i]) || Arrays.asList(notWhiteSpace).contains(keyChars[i])) {
                        found = false;
                String keyFriendly = String.valueOf(keyChars);
                System.out.println(String.format("    - %s\n    %s", keyFriendly, value));
    Wow. 12 lines (Python) vs 77 lines (Java). After my great adventure attempting to write this simple github API call in Java, I'm not sure if this is what you meant when you referred to a clean language where you can accomplish things in a very small amount of lines. Maybe you should clarify?
  10. Offline


    But you are forgetting the essence of my argument... you can write a library atop this code and make the Java code just as long if not shorter than Python... and let's not forget about the readability gain with Java.
  11. Offline


    Java is not readable at all. Python almost forms coherent sentences, and the strict indentation of Python makes the language similar and easy to understand for all Python programmers. Also, what's the point of writing a library atop the code? That's just a ridiculously stupid amount of abstraction, considering you're already using a library to do the request.

    But that's not the point. The point is, in Python you don't even need to write the 77 line method in a library, because the library is already there for you. Why write the library if you don't have to?

    Even if you did that, that's not even an edge over Python, since you can do that in Python too.
  12. Offline


    Actually, the goal of programming is to make everything as high-level as possible. This means you should write wrapper libraries atop wrapper libraries until operations that you want to do are simple 1-line calls. Sure, this is no edge over Python as it can also do this, but it certainly is harder to develop a codebase of Python wrapper libraries atop wrapper libraries due to Python's general lack of support from big business that pretty much force Java developers into writing such libraries.

    You are using a tailored library with comparison to a generic library... If there was a well designed Java GitHub API the client code would likely match length to Python's... Your Python code does not use a low-level API like Apache... Also, by the look of your Java code, it's pretty obvious that you are a novice of the language...
  13. Offline


    The GitHub API is HTTP, which is language-agnostic. I'm not using a tailored library, the Apache HttpClient library and Python Requests library are both tailored for high-level HTTP operations.

    Python has good support from big businesses, from companies such as Google and Facebook/FriendFeed. Ruby (another great language) is used by Twitter and 37signals.

    With Python libraries, you can create great webapps. Django, Pylons, and Flask are both extremely capable frameworks. The most popular web frameworks that run on the JVM (Grails, Play) aren't even tailored for Java, probably because Java is an ugly, verbose (albeit powerful) language. Grails is tailored for Groovy, and Play for Scala.
  14. Offline


    But you are... tell me more about how requests isn't tailored for JSON keying...

    Python doesn't have good support from big business; Google supports Java more than Python, and Google isn't really a big business... I've never even heard of FriendFeed. Ruby was a pile of junk until the anti-dogmatic programmers came in and spiced it up by introducing legacy compatibility; without such a business owner wouldn't even go near the language. I've never even heard of 37signals...

    Anyway, with a higher-level approach library that your developers can make will result in VERY VERY maintainable code even though the libraries themselves might be much more lengthy than a Python equivalent...

    String username = input("Username: ");
    println("Viewing information about " + username + "\'s github account:");
    for (Entry<String> entry : getJSONKeys(new GitHubKeyFinder(username))) {
        println(format("    - %s\n    %s", entry.getKey(), entry.getValue()));
    The client code (note that the example shown here isn't as high-level as possible, but to the same extent as your Python code) beats your Python code in terms of length and readability.
  15. Offline


    I'm not saying Java is a fundamentally bad language, because it isn't. Java is a pretty good language. It's very powerful, despite being ugly and verbose.

    Some languages are fundamentally broken and poorly designed (coughPHPcough). Java isn't one of them, and Python isn't either.

    However, in cases where you need high level features and you can sacrifice a small amount of performance, you should use Python instead of Java.

    Another however, in cases where you can't sacrifice performance (coughMinecraftcoughBukkitcough) because you're running intensive operations and you need every bit you can get, you should use a language that compiles to machine code, preferably where YOU are managing the memory.

    You're missing the point. In Python using the requests library you don't need to do that. In Python it's done for you.

    Even if I removed the part where I get the json already Marshaled from requests, it would only take 2 more lines of code in python to Marshal the json using the built in Python json package into a Python dictionary object (one to import the json package, one to Marshal the json).

    Also, friendfeed is owned by facebook. So let's just refer to it as facebook.
  16. Offline


    I absolutely disagree with you on everything enlisted other than PHP being poorly designed... PHP is a mere sink of built-in functions... reminds me of another language (cough Python cough).

    Java isn't verbose, or ugly... also, Java isn't very powerful. I think you have these notions in reverse... Java's syntax is very legible, even to those who are new to programming. In fact, people who are new to programming can easily pick up a medium OO language like Java MUCH faster than crappy full OO or no OO languages like Scala and C... Java can have incredible power; but much of this power is locked away with the need for native function calls, and, despite Java being able to do this there exists a need for a wrapper API atop the existing JNI wrapper API (JNA) because it is tearfully difficult to do tasks with such, I would consider the client code to be VERY verbose and not maintainable by any means.

    I don't think Minecraft nor Bukkit needs to use a native language... quite the contrary. Good design inherits good performance with Java... but Minecraft is quite a far fetch when speaking of good design. Bukkit is slow because there is evidently an anti-dogmatic programmer team... they hate following the holy rules... it disgusts me to see programmers abuse the Java language as Bukkit and especially Mojang have done. Although the end result may be the same, the means of which accomplish this figure are made much more difficult than needed maintenance inclusive.

    And likewise 3rd party Java libraries have done it for you as well...

    And with that you're only making your client-code longer...

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 29, 2016
  17. Offline


    Minecraft's insanely bad performance has to to either have something to do with Mojang having terrible programmers (somewhat unlikely), or the JVM not being suited for writing a game in.

    It's probably the latter.

    The JVM is 90 MB. It's a massive dependency. Python is only 19.6 MB, and it comes with most linux distributions and mac os.

    Scala isn't a crappy full OO language. In Scala, all types are objects. It's true OOP. Not only does Scala have OOP, it also fully supports the functional programming paradigm. C isn't a crappy language. Windows, Linux, Mac OS, the Python interpreter, and the JVM are all mainly written in C. C is the backbone of everything. It has fast performance compared to both Java and Python, and its functional programming paradigm was revolutionary and still is efficient and intuitive.

    If Scala is a bad language, why is everyone jumping on the technology (Twitter, Typesafe)?

    Your idea of writing wrapper methods around wrapper methods around wrapper methods around API calls is a terrible idea. It creates a massive amount of feature creep, and dependency hell.

    "Write programs that do one thing and do it well." - Unix programming philosophy

    Write programs that do one thing and do it well, don't pile on a clusterfuck of abstractions to achieve your "one line statements".
  18. Offline


    HAHA! You're saying Mojang has good programmers! Hahahah! Herp derp let's all grant public access to mutable members! Let's go around implementing everything concretely! Let's ignore everything Josh Bloch has been trying to instill for the past decade! Yeah, go team Mojang! Screw Java! We're writing Mojangava! A Mojangster's code is evidence for our cause; end to dogma!

    The JVM isn't a dependency, it's a requirement. It should be law that all machines require a JVM. ;-) In all seriousness the JVM is the golden key of our time; it is the future albeit Java might not be.

    Scala IS a full-OO language, as aforementioned where as Java has types which aren't objects; ergo I prefer this. I didn't say C was a crappy language? Also, I'll let you know right off the bat that I hate a lot of functional paradigms... they are merely approaches of super complex where a representational paradigm is MUCH better suited.

    No, there is no such thing as "dependency hell". There is nothing wrong with having lots of dependencies... it doesn't fluctuate anything so long as you know how to deploy a Java application.

    You're coming off to me just like everyone else; an anti-dogmatic programmer. I'll bet you're using a Linux distribution and ignoring all of the enterprise dealings of programming... I'll also bet you wave the red flag when a Flash guru comes into town ;-) ActionScript is a great language.

    You're forgetting that Python does the same, only such is included with the SL.
  19. Offline


    The JVM is pretty good, but Java isn't. There are so many great languages that can run on the JVM, such as Python, Clojure, and Scala (the last of which I feel could be a true successor to Java).

    I agree that OO is a very good paradigm. It's an interesting concept, because it was difficult for me to understand at first, and then when I figured it out it was very easy to use. However, functional programming can be very easy to understand from the start and it was very easy to pick up for me. Today I do a lot of my programming using the functional paradigm in languages such as Go, C, and Scala.

    Oh, and this is when you called C a "crappy no OO language"
    I actually do dual boot Windows and Linux, but I'm not against using proprietary software. I often find myself writing C#, and I think Mac OS is an efficient, versatile OS that I would love to use.
    Windows is definitely not the best OS:
    • DLL hell
    • Having updates shoved up your arse
    • VC C compiler version incompatibility
    • Difficulty of obtaining development headers and general software compared to Mac/Linux
    • Innate proprietary C API calls
    • Innate bugginess
    ActionScript... is an interesting language. I praise its improvements on EMCAScript, but I'm not a big fan of EMCAScript. I would have to say that AS4 is a pretty good language, but the earlier versions of AS that were closer to JavaScript I would not be a fan of in any way.
  20. Offline


    Because Java is 100x better!
  21. Offline


    Lol no
  22. Offline


    Moving this thread to Bukkit Discussion as it fits in that forum better than Community Feedback.
  23. Offline


    Sushi and Canownueasy's debate is really interested, I hope to see more of their debate.
    chakyl and Sushi like this.
  24. Offline


  25. Offline


  26. Offline


  27. Offline


    C'mon. Both you and I know that Malbolge is 100% times better. I mean, it's readable by babies! Look at this wonderful, beautiful code:

     ('&%:9]!~}|z2Vxwv-,POqponl$Hjig%eB@@>}=<M:9wv6WsU2T|nm-,jcL(I&%$#" `CB]V?Tx<uVtT`Rpo3NlF.Jh++FdbCBA@?]!~|4XzyTT43Qsqq(Lnmkj"Fhg${z@>
  28. Offline


    ŁOOO RLY ?

  29. Offline


    I swear there was this exact thread created before.
    Regardless, the language makes almost no difference to the end product. Its about the design methodology used to make the end product.
    obnoxint likes this.
Thread Status:
Not open for further replies.

Share This Page