This post originated from an RSS feed registered with Python Buzz by Ian Bicking. Original Post: Java Usability Recap Feed Title: Ian Bicking Feed URL: http://www.ianbicking.org/feeds/atom.xml Feed Description: Thoughts on Python and Programming. Latest Python Buzz Posts Latest Python Buzz Posts by Ian Bicking Latest Posts From Ian Bicking

A short response to the LinuxWorld article I linked to a couple days ago (Why Do Java Developers Like to Make Things So Hard?) [via]

I think a lot of the issue relates to this:

I'm not smart enough to be able to guess how my code will be used by somebody else, so I like to reduce coupling and allow for different implementations to be substituted during runtime. Much of this is due to my experience with Java, but it's also based on bitter real world experience where I need to have this reduced coupling because in more cases than not, I've needed this flexibility. Using a scripting language (Perl for example) much of this can be resolved by having different and specific implementations in each environment. I'm sure this is fine for many people, but when I'm shipping class files to a customer, they don't have the ability to change the code for their environment, so I have to allow it beforehand.

Java isn't a proprietary platform just because the JDK is proprietary -- it's a proprietary platform because it is largely a proprietary community. Proprietary code is structured fundamentally differently -- the structures of the systems we design reflect the structures of our organizations. (I saw a quote recently to that effect, perhaps from a 1960s paper, maybe by an architect, but damned if I can find it now)

Free software development is a peer relationship, one that involves feedback and incremental and cooperative growth in all areas of a system. Free software systems are themselves a community of software, just like the social structure they come out of. Proprietary development doesn't look like this -- there's more specification of duties, strict boundaries and lines, and feedback is largely limited to general comments and commercial forces, it doesn't take the form of code itself. (This relates some to my recent packaging post, in that proprietary OS's packagers reflect these community differences as well)

It's because of this that I'm not optimistic about proprietary code being freed and becoming a strong piece of open source code. They are different methodologies, not just different licenses, and it's hard to separate code from methodology.