Tom Pinckney: Why I gave up on Java and switched to Python | Hacker News Reader

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

tompinckney.com

83 pointsrjim8650 comments

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

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.

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

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.

Maybe those Perl one-liners weren't so useless after all...

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

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.

It could be linear with a different constant multiplier for each language. Perl would presumably have a higher multiplier than Java given its density.

Sounds like the kind of scaling tools like CLOC can display.

http://cloc.sourceforge.net/

static type checking is like compile-time asserts -- it doesn't add to solution complexity, it just verifies assumptions about inherent existing complexity.

Satisfying a rigid, static type checking system often requires adding additional code which may not be significant to the solution. In other words, verifying assumptions requires additional code. Which assumptions actually need to be verified? Bondage-and-discipline languages do force you to do more thorough checking, but that doesn't necessarily mean the code is clearer or more concise. That isn't even the point of a bondage-and-discipline language.

Getting normal things done with static type checking is not always simple; sometimes code gets skewed toward satisfying the type system. This is not completely unlike the way some people pepper their code with statements that serve no purpose except to shut up a lint tool, or make their test code simpler by making their solution code more complex.

Assertions are an interesting case, as the programmer controls what gets verified and when, rather than being forced to code around an inflexible static checking system that inserts itself into language syntax.

     it doesn't add to solution complexity

Yes it does.

"There is a direct and measurable causal relationship between number of LOC and number of bugs"

Does that apply cross-language, or just within a given language?

From what I understand, raw number of lines of code, taking absolutely nothing else into consideration, is the most reliable indicator of bug count by a wide margin. I bought the book this morning to read it for myself but haven't had a chance yet due to work. It's Chapter 8 of "Making Software" (which can legally be had for free I believe)

'There is a direct and measurable causal relationship between number of LOC and number of bugs.'

So if i write unit tests, that increases the number of lines of code, thus increasing the bug count right? The static type information in java is more akin to unit tests than actual programming logic - they decrease the bug count, not increase it.

Whether they decrease the bug count enough to make up for the productivity loss is the part that is debatable

I agree with you.. static type information reduces potential test cases which makes it more like unit tests than LOC which will impact the bug count negatively.. but even though the author argues that the 'extra' Java code is type information, I think that's overly simplistic. Java also lacks mechanisms for re-use that languages like python have.. that increases LOC and redundancy in a way that I think will tend to affect the bug count negatively.

In my experience, done right it's a bit of a wash. There's more potential cases to test in python.. but the tests are easier generally to write, and the code is more concise and easier to read.

With pretty extensive experience at this point in both languages I wouldn't say I've experienced a significant difference in bug trends at all, frankly.

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

First, there are objective aspects to that perception. For example, Python affords trying stuff immediately through its REPL. When you commit it to “real” code, it just works. Opening an UTF-8 file is just `codecs.open`. Alas, there is Zope/Plone to serve as a counterexample.

Second, emotional reactions do affect how we, human programmers, perform. If I feel nice coding in Python, I am very probably more productive. If I hate XML configuration files, I'll be on my nerves when I write them and might perform poorly.

The relationship between a programmer and code is not (just) a mathematical thing and we really should stop seeing emotion as a cognitive defect and appreciate it as the evolutionary improvement that it indeed is.

(Sorry for ranting. I'm hungry.)

All you say is valid but if you are going to argument that A > B, you cannot say that one of the reasons is "because I like A" or its equivalent "because A just work"

Certainly so, but read the title again:

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

The author is not arguing that Python is better than Java. (It's 2011, why would he do that?) He's telling his reasons for switching. We can disagree with all of them, but we cannot say any of them are invalid because they are “emotional” or “subjective”.

"that's just a self delusion caused by an emotional reaction not a valid argument"

It really is not, believe me.

I agree that number 2 doesn't make any sense. I know that code quality is measured by defects in KLOC (1k lines of code) but this isn't a reason.

P.S Even though within the article the python the he explains what he means (with type bugs) such issues won't be by moving to python.

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?

That line alone makes the whole thing a joke.

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.

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.

And since most Java programmers will be in Eclipse, compile-time errors are really typing-time errors, and you have auto-complete anyways.

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

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

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

"I stopped writing tests. Reduced the LOC by half. And with no tests, we actually find fewer bugs!"

This can be true to an extent. Tests are a tradeoff that can potentially give you better stability, yes, but at the cost of more development time, longer builds, costlier maintenance, and more surface area for bugs.

Like types, tests are appropriate in some cases, overkill in others. Imo, a lot of web functionality, especially for prototypes, isn't sufficiently complicated or critical (i.e. life or death or responsible for millions) to warrant tests, and the threshold for types is higher. Also depends a lot on the size of your team and skill of developers. If you're producing code with few bugs to begin with, tests have less value.

It's really all a matter of judgment and right-tool-for-the-job. Generalisms just aren't useful.

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.

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

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.

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

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.

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.

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

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

What a horrible article.

Article dated to:

"Saturday, August 1, 2009"

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

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

Or, for that matter, D2.

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

Yet...

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

Penetration will come.

Python is 20 years old, though your point stands regardless.

Gah :(

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.

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

Reply on news.ycombinator.com