I'm enjoying Ryan Tomako's series on Python for Java programmers, the second of which has a good overview of Python attributes compared to Java's get/set idiom. I think the article strays a bit when it looks to enter into the mind of a Java programmer. Accessors, Attributes, Autoboxing Here's where I see a huge difference in mind-set between Python and Java coders... Practices like getter/setter that lead to code bloat are generally met with less resistance in the Java community because the intelligent IDEs and other tools go a long way in managing the excess code. What I would say here is that I write a good amount of Java and Python code, at the moment it's probably close to a 50/50 split. With my Java hat on, I dot find code bloat cause by the get/set idiom to be an important issue. And yes, I read a lot of other people's code. [In any case, Java 1.5 has autoboxing, which provides some kind of parity with Python attributes.] The real problem with getters and setters is to do with code management, not bloat. Alan Holub has laid this out in a JavaWorld article. If you're not careful you end up with a small fraction of classes doing all the work by pulling the data they need from a lot data objects. Holub's argument is that get/set makes it easy to fall into that trap - procedural programs obfuscated by object oriented gorp. Then again, if you can pass around functions as easily as you can objects, procedural clumping doesn't seem to be as much of an issue. So whether or not you have autoboxing doesn't seem to matter as much from a code management standpoint as whether you have function passing and/or lexical closures. In that regard, use of Command and Plugin patterns are indications of trying to emulate that function passing capability via APIs. Certainly Command and Plugin are two of the more powerful ways I know for organising code in C# or Java. In short: object languages that have a get/set idiom and do not have function passing naturally lean a programmer towards larger centralized units of behaviour orbited by collections of fields masquerading as objects. IDEs This is the primary reason why there is little serious demand for Python IDEs. Many people coming to Python can't believe no one uses IDEs. The automatic assumption is that Python is for old grey beards who are comfortable with vi and Emacs and refuse to accept breakthroughs in programming productivity like IDEs. Then they write a little Python code and realize that an IDE would just get in their way. I would say that the day you need an IDE with Python is further away than with Java. But is there really little demand for Python IDEs? That might be rationalising things a bit. I know I want a better one. Forget debuggers, wizards, code generators, code folding, code tidy, syntax checking, tree views, all that stuff normally associated with an IDE. Those are not the key productivity boosters. The facilities a good IDE gives you that counts are, autocomplete, refactoring, easy testing, version control I suspect refactoring and autocomplete are some of the reasons Guido Van Rossum is noodling on type declarations for Python. Once a Python IDE exists that has anywhere close to the refactoring and testing functionality of IntelliJ or Eclipse, it'll get used. Not having anything other than Emacs is affecting Python adoption. Refactoring and version control The next wins in IDE productivity could be profiling support and direct mapping of refactoring steps onto version control operations. Paul Graham has made the case for better profiler support, so let's consider the situation with refactoring today and how integrated version control might be beneficial. Currently with automated refactorings you're doing twice the work you need to - first to tell the IDE what to refactor and second to manually emulate those refactorings with version control before checking in without losing version history or getting entirely frustrated. [This is one reason why CVS is a dead-end for Java and C#. CVS gets in the way of refactoring and as the refactoring capabilities for those langauges improve, the pain of using CVS will increase.] In that case the IDE extends beyond the developer desktop and onto the repository server. You'd have to think that if Jetbrains had either Resharper or IDEA refactorings mapped onto svn operations, and went on to offer a complimentary custom build of Subversion, they would shift plenty of units....
Previous Topic
