5 ms·

Tom Pinckney: Why I gave up on Java and switched to Python

83 points by rjim86 15y ago

astral303 15y ago
If you feel the same way and you are in the Java world, consider also switching to Groovy. It gives you all the dynamic type checking goodness with a smoother learning and adoption curve, since you can start from 100% Java and work your way up into closures, dropping types, simper syntax, etc. #1 is a bit unfair now, as there are plenty of things in pure Java (Guice, Spring Roo) that don't require ridiculous XML files.
- pyre 15y ago
  ~1.5 years ago, we did a project in Groovy and found that some things were not quite there, like passing named parameters into a constructor.
  - mgkimsal 15y ago
    Did you submit a bug report? I'd be curious to see what you were doing that caused a problem. I've been using Groovy for > 3 years and haven't hit an issue with named parameters, but I might be using just simplified cases compared to you.
    - pyre 15y ago
      I think that we just gave up on it. Another thing that I remember being really annoying is that there was no easy way to break out of iterating closures other than to throw an exception. I ended up writing a "BreakClosure" exception specifically for this. (The return value of the closure goes nowhere, and breaking out of one closure just causes the next iteration to run.)
      - mgkimsal 15y ago
        Agreed on breaking - hadn't thought of that approach. I'm used to 'continue/break' from PHP, so reworking the iteration loops to check if the loop should run is annoying. :/ Maybe I'll try your exceptional approach too.
        deleted 15y ago
        [deleted]
pointyhat 15y ago
He should try Go. I'd say it's half way between Java and Python.
- voyvf 15y ago
  Or, for that matter, D2.
- sigzero 15y ago
  It has no penetration. Java and Python are both widely used in the industry. Go is not.
  - pointyhat 15y ago
    Yet...
  - vegai 15y ago
    Go is about 2 years old. Python just turned 30. Penetration will come.
    - tmhedberg 15y ago
      Python is 20 years old, though your point stands regardless.
      - vegai 15y ago
        Gah :(
    - sigzero 15y ago
      Will it? I don't think it will. There are a plethora of languages right now and people write more all the time. Go doesn't bring anything "special" to the table to give it Enterprise penetration. People are pretty entrenched with what is out there and it would take some confluence of events to make Go have penetration like Java, Python and others.
      - 15y ago
lemming 15y ago
Easily half of my java was type info. If the number of bugs in a program is proportional to the program length, by omitting the type info a python program has fewer opportunities for bugs. You're kidding me, right?
- smackfu 15y ago
  That line alone makes the whole thing a joke.
- dexen 15y ago
  That's true and he is right; having the programmer juggle types is human compiler at work. The more a human is relied upon, the more bugs result. Let the machine (here: the compiler or interpreter) do the dirty work. Of course, there are distinct classes of errors that occur only when programmer off-load juggling types to the computer, but that by itself doesn't invalidate his stance -- those errors are less prolific than errors associated with doing all type work by hand.
  - ootachi 15y ago
    Are we talking about compile-time or runtime errors here? I can accept that manifest typing leads to more compile-time errors, but the idea that it leads to more runtime errors is nonsense. Types constrain, statically, the set of values that are permissible at any program point. They strictly reduce the possibility of runtime errors.
    - smackfu 15y ago
      And since most Java programmers will be in Eclipse, compile-time errors are really typing-time errors, and you have auto-complete anyways.
- kenjackson 15y ago
  I was going to write almost the exact same response. It's like someone saying, "I stopped writing tests. Reduced the LOC by half. And with no tests, we actually find fewer bugs!"
ilcavero 15y ago
I'm sure there are many reasons why such switch would make sense, but the ones provided here are just BS. 1)"No more XML config files" XML configs are slowly disappearing 2)"by omitting the type info a python program has fewer opportunities for bugs" this reason was just nonsensical 3)"It's free software and easier to hack on", go check the openJDK 4)"Things in the python world seem to "just work"" that's just a self delusion caused by an emotional reaction not a valid argument 5)"I can still relive the good old scheme days" ok so maybe this one is not BS
- mattdeboard 15y ago
  There is a direct and measurable causal relationship between number of LOC and number of bugs. This was discussed at length on Stack Exchange podcast #9 (I believe) when the author of "Making Software" was a guest. This exact topic was discussed at length. Java is for better or worse more verbose than Python, which means more lines of code which means more opportunity for bugs. It is hardly nonsensical. That opinion is a product of language-centric parochialism with no regard for actual fact. Ditto for the "just work" line being a "delusion." Like it or not, Python does indeed "just work" in most cases. This isn't unique to Python of course, but I do think that is a fair opinion of the author to hold.
  - arethuza 15y ago
    "There is a direct and measurable causal relationship between number of LOC and number of bugs" I don't believe it is a simple linear relationship otherwise we'd all be using Perl or APL. More likely there is a "sweet spot" in the verbosity/terseness spectrum that is occupied by languages like Python.
    - mattdeboard 15y ago
      Well, I'm not going to carry the banner for the authors' research, but that is not the case they make. According to them, more lines of code = more bugs.
      - 15y ago
cafebabe 15y ago
Sounds like he has worked alot on awful Java projects. He probably writes something equal to this about Python in the future.
EponymousCoward 15y ago
What a horrible article.
lusr 15y ago
So... with a statically type-checked language, most of his errors were null reference errors? Funny, with Python most of my errors were type errors. (And most of my serious problems were with refactoring complex applications as they grew larger. This is why I stick to C#.)
astine 15y ago
Article dated to: "Saturday, August 1, 2009"
- karussell 15y ago
  Yeah ... the first thing every guy should do: look at the dates!! Maybe he is now back at the JVM ;)
null_ptr 15y ago
My main language is C, and my go-to language for quick programs to get some job done used to be Java. Until I learned Python and realized how nice it is. Now I write all my scripts and tools in Python, it's a superb language. I enjoy C because of its bare-bones simplicity, but I like working in Python just as much.
ojosilva 15y ago
"to get Tomcat to produce good performance under load" Tomcat is a servlet reference implementation, and is good as a development application server. But for anything serious in production, get JBoss or something. I know the Tomcat team has been working hard on making it more robust, but still! I think some people/companies and some languages are just meant for each other. Looks like these folks just got into Java through the wrong door. The switch to Python could only make a lot of sense to them. And I'm glad they did.

83 points by rjim86 15y ago

If you feel the same way and you are in the Java world, consider also switching to Groovy. It gives you all the dynamic type checking goodness with a smoother learning and adoption curve, since you can start from 100% Java and work your way up into closures, dropping types, simper syntax, etc. #1 is a bit unfair now, as there are plenty of things in pure Java (Guice, Spring Roo) that don't require ridiculous XML files.

pyre 15y ago
~1.5 years ago, we did a project in Groovy and found that some things were not quite there, like passing named parameters into a constructor.
- mgkimsal 15y ago
  Did you submit a bug report? I'd be curious to see what you were doing that caused a problem. I've been using Groovy for > 3 years and haven't hit an issue with named parameters, but I might be using just simplified cases compared to you.
  - pyre 15y ago
    I think that we just gave up on it. Another thing that I remember being really annoying is that there was no easy way to break out of iterating closures other than to throw an exception. I ended up writing a "BreakClosure" exception specifically for this. (The return value of the closure goes nowhere, and breaking out of one closure just causes the next iteration to run.)
    - mgkimsal 15y ago
      Agreed on breaking - hadn't thought of that approach. I'm used to 'continue/break' from PHP, so reworking the iteration loops to check if the loop should run is annoying. :/ Maybe I'll try your exceptional approach too.
      - deleted 15y ago
        [deleted]

pointyhat 15y ago

He should try Go. I'd say it's half way between Java and Python.

voyvf 15y ago
Or, for that matter, D2.
sigzero 15y ago
It has no penetration. Java and Python are both widely used in the industry. Go is not.
- pointyhat 15y ago
  Yet...
- vegai 15y ago
  Go is about 2 years old. Python just turned 30. Penetration will come.
  - tmhedberg 15y ago
    Python is 20 years old, though your point stands regardless.
    - vegai 15y ago
      Gah :(
  - sigzero 15y ago
    Will it? I don't think it will. There are a plethora of languages right now and people write more all the time. Go doesn't bring anything "special" to the table to give it Enterprise penetration. People are pretty entrenched with what is out there and it would take some confluence of events to make Go have penetration like Java, Python and others.
    - 15y ago

lemming 15y ago

Easily half of my java was type info. If the number of bugs in a program is proportional to the program length, by omitting the type info a python program has fewer opportunities for bugs. You're kidding me, right?

smackfu 15y ago
That line alone makes the whole thing a joke.
dexen 15y ago
That's true and he is right; having the programmer juggle types is human compiler at work. The more a human is relied upon, the more bugs result. Let the machine (here: the compiler or interpreter) do the dirty work. Of course, there are distinct classes of errors that occur only when programmer off-load juggling types to the computer, but that by itself doesn't invalidate his stance -- those errors are less prolific than errors associated with doing all type work by hand.
- ootachi 15y ago
  Are we talking about compile-time or runtime errors here? I can accept that manifest typing leads to more compile-time errors, but the idea that it leads to more runtime errors is nonsense. Types constrain, statically, the set of values that are permissible at any program point. They strictly reduce the possibility of runtime errors.
  - smackfu 15y ago
    And since most Java programmers will be in Eclipse, compile-time errors are really typing-time errors, and you have auto-complete anyways.
kenjackson 15y ago
I was going to write almost the exact same response. It's like someone saying, "I stopped writing tests. Reduced the LOC by half. And with no tests, we actually find fewer bugs!"

ilcavero 15y ago

I'm sure there are many reasons why such switch would make sense, but the ones provided here are just BS. 1)"No more XML config files" XML configs are slowly disappearing 2)"by omitting the type info a python program has fewer opportunities for bugs" this reason was just nonsensical 3)"It's free software and easier to hack on", go check the openJDK 4)"Things in the python world seem to "just work"" that's just a self delusion caused by an emotional reaction not a valid argument 5)"I can still relive the good old scheme days" ok so maybe this one is not BS

mattdeboard 15y ago
There is a direct and measurable causal relationship between number of LOC and number of bugs. This was discussed at length on Stack Exchange podcast #9 (I believe) when the author of "Making Software" was a guest. This exact topic was discussed at length. Java is for better or worse more verbose than Python, which means more lines of code which means more opportunity for bugs. It is hardly nonsensical. That opinion is a product of language-centric parochialism with no regard for actual fact. Ditto for the "just work" line being a "delusion." Like it or not, Python does indeed "just work" in most cases. This isn't unique to Python of course, but I do think that is a fair opinion of the author to hold.
- arethuza 15y ago
  "There is a direct and measurable causal relationship between number of LOC and number of bugs" I don't believe it is a simple linear relationship otherwise we'd all be using Perl or APL. More likely there is a "sweet spot" in the verbosity/terseness spectrum that is occupied by languages like Python.
  - mattdeboard 15y ago
    Well, I'm not going to carry the banner for the authors' research, but that is not the case they make. According to them, more lines of code = more bugs.
    - 15y ago

cafebabe 15y ago

Sounds like he has worked alot on awful Java projects. He probably writes something equal to this about Python in the future.

EponymousCoward 15y ago

What a horrible article.

lusr 15y ago

So... with a statically type-checked language, most of his errors were null reference errors? Funny, with Python most of my errors were type errors. (And most of my serious problems were with refactoring complex applications as they grew larger. This is why I stick to C#.)

astine 15y ago

Article dated to: "Saturday, August 1, 2009"

karussell 15y ago
Yeah ... the first thing every guy should do: look at the dates!! Maybe he is now back at the JVM ;)

null_ptr 15y ago

My main language is C, and my go-to language for quick programs to get some job done used to be Java. Until I learned Python and realized how nice it is. Now I write all my scripts and tools in Python, it's a superb language. I enjoy C because of its bare-bones simplicity, but I like working in Python just as much.

ojosilva 15y ago

"to get Tomcat to produce good performance under load" Tomcat is a servlet reference implementation, and is good as a development application server. But for anything serious in production, get JBoss or something. I know the Tomcat team has been working hard on making it more robust, but still! I think some people/companies and some languages are just meant for each other. Looks like these folks just got into Java through the wrong door. The switch to Python could only make a lot of sense to them. And I'm glad they did.