3 ms·

Python is a great language to start programming in. My biggest frustration with traditional programming languages (well, C/Java mostly) was just how much upfron

by pm90 8y ago

Python is a great language to start programming in. My biggest frustration with traditional programming languages (well, C/Java mostly) was just how much upfront effort and understand is required to do useful stuff. Whereas with python it is pretty easy to whip up a script, read input and transform it into output in real time etc. That said, I think its also important for Python programmers to dabble at least a little bit with Java to really understand how OOP works. Python does have OOP but it has certain quirks which can confuse newcomers. Java helped to clarify my understanding of OOP a lot, even though I've only used it marginally.

kjeetgill 8y ago
I'm going to chime in to 100% agree with you. I'm a big fan of both of those languages and their respective ecosystems. I'm in love with the idea that there a good case of polyglot (biglot?) program synergy between the two. Keep your eyes open on Jython and GraalPython!
meowface 8y ago
Other than interfaces and generics (which would make no sense to add in Python, since it's dynamically typed), can you name some OOP features Java has that Python doesn't have?
- Alex3917 8y ago
  > can you name some OOP features Java has that Python doesn't have? Encapsulation. In Python you can write code in an OO style and benefit from inheritance, but it’s really only good for people writing libraries and frameworks. For end user code, objects are best avoided because they can pick up state in unexpected ways, which leads to problems that are extremely difficult to debug.
  - deleted 8y ago
    [deleted]
  - meowface 8y ago
    Could you give some examples? What encapsulation features does Java have that Python doesn't? You can get private methods with double underscores. It's true that attributes in Python objects are all public by default and in Java you have to be more explicit to get public attributes, so maybe that counts, but otherwise what do you mean by "objects can pick up state in unexpected ways"?
    - Alex3917 8y ago
      So let's so you have: class Foo(): def __init__(self): self.bar = 1 Then let's say you have foo_instance imported in your module, and you see that foo_instance.bar has a value of 2. You can see that foo_instance is imported from module A. So you go there, and see that the instance wasn't created there, it was imported from module B. But wait, it wasn't created there either, it was imported from module C, etc. Somewhere along the way bar picked up the value of 2. But it's almost impossible to figure out where because there isn't any requirement use a uniquely-named accessor to modify the instance, so you can't just grep through the code to see where that method was called. (And maybe the name of the instance has changed a few times along the way, for whatever reason.) And what's worse, the code that modified the instance might not even be visible in any of the modules, it's possible that someone took advantage of Python's ability to change the way the importing system works to mess with either the class or the instance. Or maybe there is some global middleware that's messing with objects or instances, or unrelated module Z is secretly monkey patching module B somewhere in the middle of this process. Who knows, and good luck figuring out. Whereas if you just write the user-code logic in functions then it's not possible for developers to create situations like this. That obviously isn't possible for a library where the entire point is to make everything extensible and where you don't know how people will want to use something in advance, but hopefully the people writing libraries and frameworks have good enough judgment not to completely abuse the tools. I'm not sure if I can really articulate how this is different than Java or Swift or whatever, but for whatever reason it just feels different.
      - meowface 8y ago
        I understand your point. I think this is partly related to the fact that instance attributes are public by default and do not require accessor or mutator methods (though you can easily create them with the @property decorator) and partly due to the fact that Python is a very dynamic language. You can make instance variables "culturally private" by pretending the variable name with a single underscore, and you can name-mangle (to make it effectively private, unless someone really goes out of their way) with double underscores, but I know that's annoying to do for most/all variables and that making them private by default has advantages. Python is just not as strict a language as Java, Swift, C#, etc. That has advantages and disadvantages. Personally, this hasn't generally been an issue for me, because I've rarely directly modified instance variables in my own code unless I'm intentionally doing something really "meta", and it's not a pattern I've seen much of in other codebases.
- pm90 8y ago
  This may sound super n00b but I really like that Java is explicit about everything. So for instance, you explicitly specify variables, methods as private with the keyword 'private'. In python you have to use an underscore, and its still not really private, its obfuscated. That's just one example, but in general I really like that kind of by-the-book verbosity, instead of having to mentally map it into the OOP concepts.
  - xapata 8y ago
    Why would you want to actually enforce privacy? That makes it harder for the user to patch. Better to provide a mild discouragement via "_name".
    - twblalock 8y ago
      Because in traditional object-oriented design you would extend rather than patch. It's the open-closed principle. There are many benefits to enforcing privacy, and one of the biggest ones is that you can make changes to the internals of your library without breaking your users' code, because they never had access to the internals.
      - xapata 8y ago
        You can get that benefit with Python. Name mangling helps. It gets the benefits of `final` without the annoying enforcement. Don't stop me from patching your buggy code. If writing an extension is more efficient, that's how I'd solve the problem.
    - marvin 8y ago
      That's an eternal ideological debate where there is always a rebuttal on the form "a-ha - but you could just...", but the rationale is this: Your class will probably be doing things with the private variables that aren't obvious, and will break things if you access them from outside. (Either by them having a different value than you expect, or expecting a different value than you set). Of course, if you have a perfect understanding of the code, this will never be a problem, as the program is always executed as it is written. But most likely, not everyone in your organization will be as patient, smart and attentive to the details as you are.
nishantvyas 8y ago
W/O going into the war of I'm better than you (Python vs JAVA)... Python is built to make it easy to write good programs... where as JAVA is built to make it hard to write bad programs.... same objective but different thinking/approach to achieve it... hence one(Python) would eventually have larger adoption....
- kickopotomus 8y ago
  I agree with this sentiment but it is a bit of a double edged sword for Python professionally. There is some really good Python code out there but there is also a lot of bad stuff too. I know this can be said for every language but I think I have seen it most in languages like JS and Python because of the ease of access.
  - xapata 8y ago
    A better measure would be the amount of bad code produced conditioned on the skill/experience of the author. I'd be more worried about a beginner C programmer than a beginner Python programmer.
eikenberry 8y ago
I don't think Java's take on OOP is good to learn before you really understand OOP already. Its heavy handed style of OOP really hasn't aged that well and is rightfully being avoided in all newer languages.
- kjeetgill 8y ago
  I couldn't agree more. I don't know how to explain it exactly, but I had the opposite experience. Learning basics of functional programming in Python improved my OOP in Java over time. I think it's probably more like this: learning a second, contrasting topic really helps explore the motivations that drive their respective goals. OOP and Functional are broad classes of contrasting design patterns and philosophies but share the common idea: be principled about state.
oh-kumudo 8y ago
There is not an Universal OOP specification to follow. In Java's case, a lot OOP flavor's design patterns are created due to Java's lacking of some primitives like closure/lambda and higher-order functions back in its old days. In short, Java's OOP solves many problems that are unique to Java and could be easily avoided in other languages.

by pm90 8y ago

kjeetgill 8y ago

I'm going to chime in to 100% agree with you. I'm a big fan of both of those languages and their respective ecosystems. I'm in love with the idea that there a good case of polyglot (biglot?) program synergy between the two. Keep your eyes open on Jython and GraalPython!

meowface 8y ago

Other than interfaces and generics (which would make no sense to add in Python, since it's dynamically typed), can you name some OOP features Java has that Python doesn't have?

Alex3917 8y ago
> can you name some OOP features Java has that Python doesn't have? Encapsulation. In Python you can write code in an OO style and benefit from inheritance, but it’s really only good for people writing libraries and frameworks. For end user code, objects are best avoided because they can pick up state in unexpected ways, which leads to problems that are extremely difficult to debug.
- deleted 8y ago
  [deleted]
- meowface 8y ago
  Could you give some examples? What encapsulation features does Java have that Python doesn't? You can get private methods with double underscores. It's true that attributes in Python objects are all public by default and in Java you have to be more explicit to get public attributes, so maybe that counts, but otherwise what do you mean by "objects can pick up state in unexpected ways"?
  - Alex3917 8y ago
    So let's so you have: class Foo(): def __init__(self): self.bar = 1 Then let's say you have foo_instance imported in your module, and you see that foo_instance.bar has a value of 2. You can see that foo_instance is imported from module A. So you go there, and see that the instance wasn't created there, it was imported from module B. But wait, it wasn't created there either, it was imported from module C, etc. Somewhere along the way bar picked up the value of 2. But it's almost impossible to figure out where because there isn't any requirement use a uniquely-named accessor to modify the instance, so you can't just grep through the code to see where that method was called. (And maybe the name of the instance has changed a few times along the way, for whatever reason.) And what's worse, the code that modified the instance might not even be visible in any of the modules, it's possible that someone took advantage of Python's ability to change the way the importing system works to mess with either the class or the instance. Or maybe there is some global middleware that's messing with objects or instances, or unrelated module Z is secretly monkey patching module B somewhere in the middle of this process. Who knows, and good luck figuring out. Whereas if you just write the user-code logic in functions then it's not possible for developers to create situations like this. That obviously isn't possible for a library where the entire point is to make everything extensible and where you don't know how people will want to use something in advance, but hopefully the people writing libraries and frameworks have good enough judgment not to completely abuse the tools. I'm not sure if I can really articulate how this is different than Java or Swift or whatever, but for whatever reason it just feels different.
    - meowface 8y ago
      I understand your point. I think this is partly related to the fact that instance attributes are public by default and do not require accessor or mutator methods (though you can easily create them with the @property decorator) and partly due to the fact that Python is a very dynamic language. You can make instance variables "culturally private" by pretending the variable name with a single underscore, and you can name-mangle (to make it effectively private, unless someone really goes out of their way) with double underscores, but I know that's annoying to do for most/all variables and that making them private by default has advantages. Python is just not as strict a language as Java, Swift, C#, etc. That has advantages and disadvantages. Personally, this hasn't generally been an issue for me, because I've rarely directly modified instance variables in my own code unless I'm intentionally doing something really "meta", and it's not a pattern I've seen much of in other codebases.
pm90 8y ago
This may sound super n00b but I really like that Java is explicit about everything. So for instance, you explicitly specify variables, methods as private with the keyword 'private'. In python you have to use an underscore, and its still not really private, its obfuscated. That's just one example, but in general I really like that kind of by-the-book verbosity, instead of having to mentally map it into the OOP concepts.
- xapata 8y ago
  Why would you want to actually enforce privacy? That makes it harder for the user to patch. Better to provide a mild discouragement via "_name".
  - twblalock 8y ago
    Because in traditional object-oriented design you would extend rather than patch. It's the open-closed principle. There are many benefits to enforcing privacy, and one of the biggest ones is that you can make changes to the internals of your library without breaking your users' code, because they never had access to the internals.
    - xapata 8y ago
      You can get that benefit with Python. Name mangling helps. It gets the benefits of `final` without the annoying enforcement. Don't stop me from patching your buggy code. If writing an extension is more efficient, that's how I'd solve the problem.
  - marvin 8y ago
    That's an eternal ideological debate where there is always a rebuttal on the form "a-ha - but you could just...", but the rationale is this: Your class will probably be doing things with the private variables that aren't obvious, and will break things if you access them from outside. (Either by them having a different value than you expect, or expecting a different value than you set). Of course, if you have a perfect understanding of the code, this will never be a problem, as the program is always executed as it is written. But most likely, not everyone in your organization will be as patient, smart and attentive to the details as you are.

nishantvyas 8y ago

W/O going into the war of I'm better than you (Python vs JAVA)... Python is built to make it easy to write good programs... where as JAVA is built to make it hard to write bad programs.... same objective but different thinking/approach to achieve it... hence one(Python) would eventually have larger adoption....

kickopotomus 8y ago
I agree with this sentiment but it is a bit of a double edged sword for Python professionally. There is some really good Python code out there but there is also a lot of bad stuff too. I know this can be said for every language but I think I have seen it most in languages like JS and Python because of the ease of access.
- xapata 8y ago
  A better measure would be the amount of bad code produced conditioned on the skill/experience of the author. I'd be more worried about a beginner C programmer than a beginner Python programmer.

eikenberry 8y ago

I don't think Java's take on OOP is good to learn before you really understand OOP already. Its heavy handed style of OOP really hasn't aged that well and is rightfully being avoided in all newer languages.

kjeetgill 8y ago
I couldn't agree more. I don't know how to explain it exactly, but I had the opposite experience. Learning basics of functional programming in Python improved my OOP in Java over time. I think it's probably more like this: learning a second, contrasting topic really helps explore the motivations that drive their respective goals. OOP and Functional are broad classes of contrasting design patterns and philosophies but share the common idea: be principled about state.

oh-kumudo 8y ago

There is not an Universal OOP specification to follow. In Java's case, a lot OOP flavor's design patterns are created due to Java's lacking of some primitives like closure/lambda and higher-order functions back in its old days. In short, Java's OOP solves many problems that are unique to Java and could be easily avoided in other languages.