4 ms·

""" Java is a bureaucratic language. You have to cross your t's dot your i's, fill out your requests in triplicate at the FactoryFactoryFactory to get the objec

""" Java is a bureaucratic language. You have to cross your t's dot your i's, fill out your requests in triplicate at the FactoryFactoryFactory to get the objectOfYourDesire. """ This is such an absolutely fantastic way of succinctly describing why I dislike Java so much. Bureaucratic! Absolutely fantastic post, get this on a blog somewhere. I seriously wish I could upvote you more.

Lewisham 16y ago
It's also a great way of specifying why I love it. Having been bitten on the ass one too many times by typing problems in a Python project, the feeling of confidence I get from doing the Java bureaucracy (to some extent mitigated now I do Scala instead) is something I have really come to love. It's like a security blanket for me.
- zephyrfalcon 16y ago
  (Disclaimer: Not meant as flamebait) Not to be a prick, but if you're having "typing" problems with Python, you're using it wrong. Types are almost irrelevant in Python. What matters is whether, in a given situation, the method you're calling is supported and does what is intended. The actual type/class of the receiving object doesn't really matter, ditto for any arguments you pass to the method. While this may seem highly unsafe and brittle, it has important benefits. You can just hack up some code that "just works" in a few minutes, without having to sacrifice a goat to the compiler first, making sure that all the correct types are specified, subclasses are defined, interfaces are implemented completely, etc. The rigid type systems in other languages often require this and more; making changes to your software becomes a chore. Rapid prototyping this is not. In Python, when used correctly, you don't have this problem. Write a bit of code, write a test, run it, and decide what to do next. Ideal for testing out ideas. It doesn't work? Throw that shit out and write something else; two minutes later you'll be testing your new code again. Yes, you do need to have unit tests, but the same is (or should really be) true for most languages. Just because something compiles, doesn't mean that it does what you want. (Except maybe in Haskell. :-) Interestingly, the quickly-written prototype might well be good enough to become the actual production code, with some additions. Just keep you tests up-to-date, for reasonable use cases, and there's no reason why your code shouldn't work in real life. Sure, that function foo(x) that wants to call x.bar() will fail if you call it with an x that doesn't support the bar() method. So don't do that, then! ;-) Anyway, to summarize, I personally would much rather have Python's flexibility, paired with unit testing, than Java's lack of flexibility paired with compiler checks.
  - bdr 16y ago
    Note that you start with "you're doing it wrong" and end with "I personally would much rather". :) You also switch from arguing against type checks overall (could be Haskell) to arguing against Java. I'd say that strong compiler checks become more helpful as the size of a program increases. You can keep less of a big program in your head, and big programs have more code paths that could potentially need testing.
    - zephyrfalcon 16y ago
      Hm, I didn't mean to argue against all type checks, just the flavor of static typing as described by the OP (i.e., Java). I don't consider Haskell's type system "rigid"; it's strict as hell, but it's also very expressive. Either way, both flavors of static typing require development methods that are very different from Python's, though. My original point was that in Python, you shouldn't really have to worry about types, or checking them (in tests or otherwise). You can, but (IMHO) you'd be going against the grain of the language.
  - Lewisham 16y ago
    Well of course I'm doing it wrong, I got crashers during execution :) I understand the concept, but sometimes in a medium-size project, you just accidentally send the wrong object back. It happens. But Python won't tell you, and it'll blithely wait for the code to get exercised before dying. I don't remember exactly why I was having this problem, but the bug wasn't shallow, and required a certain confluence of exceptions to occur before it would fire. The sort of thing that would even escape most unit testing. I would never force static typing on Python or Ruby or upon any language that didn't want it, and when I switched to Python I was very pleased with dynamic typing. However, I find myself much happier with the stronger compiler checks. Writing a medium project in Python now frays my nerves!
    - zephyrfalcon 16y ago
      "I don't remember exactly why I was having this problem, but the bug wasn't shallow, and required a certain confluence of exceptions to occur before it would fire. The sort of thing that would even escape most unit testing." I agree that this does indeed happen... I think it's a matter of, the more flexible a language is, the more rope you get to hang yourself with, even unintentionally and unexpectedly. (Anecdote:) For my work, I have been developing and maintaining a fairly large Python code base... (~70K lines... comparable to about 700K lines of Java <wink>). Another developer changed a module so it would access the database upon importing, which was a no-no (IMHO), so I changed it back, using a class that gets the desired info from the db upon instantiation, and some sort of singleton construct so the same instance would be reused. I also decided to write a test to check that when this module was first imported, there would be no instance of said class yet. To make sure it was a first import, I removed any references to the module from sys.modules, then did an import. This worked great... until I ran the whole test suite using nose [http://code.google.com/p/python-nose/ http://code.google.com/p/python-nose/], which has its own ideas about import order and such. This turned out to be surprisingly hard to fix... a non-shallow bug that wouldn't even be possible in less flexible languages.
- gte910h 16y ago
  I think zeph is saying it a little strongly, but doctests find a HUGE portion of typing errors with python. Additionally, many people who do have typing problems find many go away when they make their python code slightly more object oriented. Here is a link to doctests. There are godly, and unlike any testing library, in that they aren't a library, they're a comment scanner: http://docs.python.org/library/doctest.html http://docs.python.org/library/doctest.html Smallest amount of rigmarole required to make testing happen I've seen in any language.
- eru 16y ago
  If you like static guarantees, you might want to look into the type systems of, say, Clean or Haskell. Java is almost untyped by comparison. Languages like Ocaml and F# occupy a middle ground.
cgbystrom 16y ago
Much of Java's complexity is cultural and not imposed. Take the Java web framework, Play, as an example. http://www.playframework.org/ http://www.playframework.org/
- chc 16y ago
  That's true, but the flip side is that the language is tailored to that culture. They love it and it loves them. The culture has grown around Java more than any other language because of Java's features. It's statically typed, but its typing isn't very powerful. It's dynamic, but makes it hard to write the sort of dynamic programs you'd write in Python or Smalltalk. It has methods but no functions. It has anonymous classes but no simple closures. All of Java's features conspire to create a language that's pretty verbose and doesn't do a lot to make things easier for you (aside from simple object orientation). If you like spelling everything out in excruciating detail, that's good. If not, the language doesn't want to twist your arm, but it's certainly not going to do anything to help you.
gte910h 16y ago
I haven't use that blog in awhile, but here you go: http://rowdybytes.blogspot.com/2010/06/learning-to-love-python-from-cc.html http://rowdybytes.blogspot.com/2010/06/learning-to-love-pyth...

Lewisham 16y ago

It's also a great way of specifying why I love it. Having been bitten on the ass one too many times by typing problems in a Python project, the feeling of confidence I get from doing the Java bureaucracy (to some extent mitigated now I do Scala instead) is something I have really come to love. It's like a security blanket for me.

zephyrfalcon 16y ago
(Disclaimer: Not meant as flamebait) Not to be a prick, but if you're having "typing" problems with Python, you're using it wrong. Types are almost irrelevant in Python. What matters is whether, in a given situation, the method you're calling is supported and does what is intended. The actual type/class of the receiving object doesn't really matter, ditto for any arguments you pass to the method. While this may seem highly unsafe and brittle, it has important benefits. You can just hack up some code that "just works" in a few minutes, without having to sacrifice a goat to the compiler first, making sure that all the correct types are specified, subclasses are defined, interfaces are implemented completely, etc. The rigid type systems in other languages often require this and more; making changes to your software becomes a chore. Rapid prototyping this is not. In Python, when used correctly, you don't have this problem. Write a bit of code, write a test, run it, and decide what to do next. Ideal for testing out ideas. It doesn't work? Throw that shit out and write something else; two minutes later you'll be testing your new code again. Yes, you do need to have unit tests, but the same is (or should really be) true for most languages. Just because something compiles, doesn't mean that it does what you want. (Except maybe in Haskell. :-) Interestingly, the quickly-written prototype might well be good enough to become the actual production code, with some additions. Just keep you tests up-to-date, for reasonable use cases, and there's no reason why your code shouldn't work in real life. Sure, that function foo(x) that wants to call x.bar() will fail if you call it with an x that doesn't support the bar() method. So don't do that, then! ;-) Anyway, to summarize, I personally would much rather have Python's flexibility, paired with unit testing, than Java's lack of flexibility paired with compiler checks.
- bdr 16y ago
  Note that you start with "you're doing it wrong" and end with "I personally would much rather". :) You also switch from arguing against type checks overall (could be Haskell) to arguing against Java. I'd say that strong compiler checks become more helpful as the size of a program increases. You can keep less of a big program in your head, and big programs have more code paths that could potentially need testing.
  - zephyrfalcon 16y ago
    Hm, I didn't mean to argue against all type checks, just the flavor of static typing as described by the OP (i.e., Java). I don't consider Haskell's type system "rigid"; it's strict as hell, but it's also very expressive. Either way, both flavors of static typing require development methods that are very different from Python's, though. My original point was that in Python, you shouldn't really have to worry about types, or checking them (in tests or otherwise). You can, but (IMHO) you'd be going against the grain of the language.
- Lewisham 16y ago
  Well of course I'm doing it wrong, I got crashers during execution :) I understand the concept, but sometimes in a medium-size project, you just accidentally send the wrong object back. It happens. But Python won't tell you, and it'll blithely wait for the code to get exercised before dying. I don't remember exactly why I was having this problem, but the bug wasn't shallow, and required a certain confluence of exceptions to occur before it would fire. The sort of thing that would even escape most unit testing. I would never force static typing on Python or Ruby or upon any language that didn't want it, and when I switched to Python I was very pleased with dynamic typing. However, I find myself much happier with the stronger compiler checks. Writing a medium project in Python now frays my nerves!
  - zephyrfalcon 16y ago
    "I don't remember exactly why I was having this problem, but the bug wasn't shallow, and required a certain confluence of exceptions to occur before it would fire. The sort of thing that would even escape most unit testing." I agree that this does indeed happen... I think it's a matter of, the more flexible a language is, the more rope you get to hang yourself with, even unintentionally and unexpectedly. (Anecdote:) For my work, I have been developing and maintaining a fairly large Python code base... (~70K lines... comparable to about 700K lines of Java <wink>). Another developer changed a module so it would access the database upon importing, which was a no-no (IMHO), so I changed it back, using a class that gets the desired info from the db upon instantiation, and some sort of singleton construct so the same instance would be reused. I also decided to write a test to check that when this module was first imported, there would be no instance of said class yet. To make sure it was a first import, I removed any references to the module from sys.modules, then did an import. This worked great... until I ran the whole test suite using nose [http://code.google.com/p/python-nose/ http://code.google.com/p/python-nose/], which has its own ideas about import order and such. This turned out to be surprisingly hard to fix... a non-shallow bug that wouldn't even be possible in less flexible languages.
gte910h 16y ago
I think zeph is saying it a little strongly, but doctests find a HUGE portion of typing errors with python. Additionally, many people who do have typing problems find many go away when they make their python code slightly more object oriented. Here is a link to doctests. There are godly, and unlike any testing library, in that they aren't a library, they're a comment scanner: http://docs.python.org/library/doctest.html http://docs.python.org/library/doctest.html Smallest amount of rigmarole required to make testing happen I've seen in any language.
eru 16y ago
If you like static guarantees, you might want to look into the type systems of, say, Clean or Haskell. Java is almost untyped by comparison. Languages like Ocaml and F# occupy a middle ground.

cgbystrom 16y ago

Much of Java's complexity is cultural and not imposed. Take the Java web framework, Play, as an example. http://www.playframework.org/ http://www.playframework.org/

chc 16y ago
That's true, but the flip side is that the language is tailored to that culture. They love it and it loves them. The culture has grown around Java more than any other language because of Java's features. It's statically typed, but its typing isn't very powerful. It's dynamic, but makes it hard to write the sort of dynamic programs you'd write in Python or Smalltalk. It has methods but no functions. It has anonymous classes but no simple closures. All of Java's features conspire to create a language that's pretty verbose and doesn't do a lot to make things easier for you (aside from simple object orientation). If you like spelling everything out in excruciating detail, that's good. If not, the language doesn't want to twist your arm, but it's certainly not going to do anything to help you.

gte910h 16y ago

I haven't use that blog in awhile, but here you go: http://rowdybytes.blogspot.com/2010/06/learning-to-love-python-from-cc.html http://rowdybytes.blogspot.com/2010/06/learning-to-love-pyth...