
Tom Pinckney: Why I gave up on Java and switched to Python - rjim86
http://www.tompinckney.com/2009/09/why-i-gave-up-on-java-and-switched-to.html
======
ilcavero
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
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
"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.

~~~
sambeau
I think that the real relationship is between clauses and bugs and in many
languages a line equates near 1:1 to a clause.

This is not the case for Perl & APL: each line can contain a multitude of
clauses and the relationships between them can be complex to unravel.

Conversely some languages (e.g. at the extreme end assembly language) require
multiple lines to express a complete clause.

Complex manually expressed type systems can be similar in effect to both
cases. A single line can become complex to unravel e.g this kind of thing:

    
    
      int (*(*vtable)[])();
    

Reading complex regular expressions also exhibit similar problems in
deciphering. Hence in Perl they are often broken over multiple lines with /x.

We seem naturally drawn to using lines as logical delimiters: code is maybe
similar to poetry in this respect. Also, in similarity to poetry, single
clause lines allow us to annotate our thinking on the same line by way of a
comment.

One clause per line is probably a natural sweet spot.

If my theory is correct then the relationship between lines and bugs will
still be linear but APL would have a multiplier greater than one while
assembly's multiplier could be a fraction (e.g. 5 vs 1/5).

~~~
russell
If I had to nominate favorite chapters in a book, it would be the one in the
Vax C manual that walked you through translating C declarations into English
and English to C. There was also a program that would do the same They saved
me from mental meltdown more than once.

------
lemming
_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?

~~~
kenjackson
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!"

~~~
smackfu
"I stopped writing null checks, because they just added LOC and that increases
the number of bugs."

~~~
icebraining
That would've been true, if it meant the author had switch to a language
without null references.
[http://qconlondon.com/london-2009/presentation/Null+Referenc...](http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake)

------
astral303
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
~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
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
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
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.

------
null_ptr
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.

------
lusr
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#.)

------
ojosilva
"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.

------
EponymousCoward
What a horrible article.

------
astine
Article dated to:

"Saturday, August 1, 2009"

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

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

~~~
sigzero
It has no penetration. Java and Python are both widely used in the industry.
Go is not.

~~~
vegai
Go is about 2 years old. Python just turned 30.

Penetration will come.

~~~
sigzero
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.

~~~
pointyhat
"Enterprise penetration" has traditionally been a matter of time, not
features. Enterprise software is definitely on its way out so I get the
feeling it will not need to penetrate.

