Conquering Complexity, Eckel on Java and Python and Chunk Theory [closed]

Question

In the introduction to Bruce Eckel's Thinking In Java, he says, in 1998:

Programming is about managing complexity: the complexity of the problem you want to solve, laid upon the complexity of the machine in which it is solved. Because of this complexity, most of our programming projects fail. And yet, of all the programming languages of which I am aware, none of them have gone all-out and decided that their main design goal would be to conquer the complexity of developing and maintaining programs.

In the second and later editions he adds this footnote (circa 2003):

I take this back on the 2nd edition: I believe that the Python language comes closest to doing exactly that. See www.Python.org.

I am a dabbler with java, with a background in Delphi (Pascal), C, C++, and Python. Here is what I want to know:

1. What exactly did Eckel consider when he called Python 'better' at conquering complexity, and are his thoughts on track with others who have used both?

2. What do you think about conquering complexity? Is the shorter and more terse syntax of Python a key way to conquer complexity (and thus, for instance, Jython might be a nice bridge of Java's great libraries, and Python's terse syntax), or is the strong-typing-mentality of Java, which inherits this idea from C++, which inherited that idea from simula, I think it was, a key to conquering complexity? Or is it the Rapid Application Designer (think Delphi, or for Java, the excellent free NetBeans window/form designer tools) or components, or beans, or J2EE? What conquers all, for you?

This is already tagged subjective. [edit]

Note: More on Bruce's thoughts, on why he loves Python are found here. A key quote from the article:

Bruce Eckel: They say you can hold seven plus or minus two pieces of information in your mind. I can't remember how to open files in Java. I've written chapters on it. I've done it a bunch of times, but it's too many steps. And when I actually analyze it, I realize these are just silly design decisions that they made. Even if they insisted on using the Decorator pattern in java.io, they should have had a convenience constructor for opening files simply. Because we open files all the time, but nobody can remember how. It is too much information to hold in your mind.

So, chunk theory. By the chunk theory metric, Python kills everybody else dead. I'll grant him that. But what is the metric you use? I would like to particularly invite people to stand up for Java, and oppose Bruce, if you care to.

[Please do not vote to re-open, this subject is inherently incendiary, and my gaffes have made it more-so. I agree with the moderators.]

Answer 1

I think Bruce was taking his cue from Fred Brooks, who talks about complexity in his essay "No Silver Bullet", and describes two types. The first type is inherent in the problem you are trying to solve, which he calls essential complexity and is the same regardless of what language you use. The second is the complexity added by the tools and languages we use - all the stuff you have to think about that does not directly add to solving the problem. By this measure Java has a LOT more complexity than Python. The simplest example is the canonical Hello World program. In Python (and several other languages) it is one line:

print "hello World!"

In Java it is

class HelloWorld {
  static public void main( String args[] ) {
    System.out.println( "Hello World!" );
  }
}

most of which has nothing to do with the task of printing "Hello World" and is basically noise.

There are several factors that IMHO add to the complexity of Java compared to other languages like Python.

1) everything must be in a class. This forces you to use the OO paradigm even when it is not appropriate, like the example above, and add lots of unnecessary boilplate class definitions.

2) Even though it forces you to use classes it is not fully object oriented. By this I mean that not everything is an object, such as primitive types and methods. In python you can subclass all the builtin types and pass functions & methods around like any other object.

3) Java is not functional - in fact it goes out of its way to stop you using a functional paradigm. Being able to pass functions around and create closures and lambdas can simplify a lot of code. The closest you can get in Java is to use anonymous inner classes for things like callbacks.

3) Java forces you to put in type declarations everywhere, which adds a lot of clutter without adding useful information. This is not just a static vs dynamic issue - there are statically typed languages like Scala that can infer the types 90% of the time and cut out all the noise.

4) Although Java forces you to use static typing, many (perhaps most) real world Java programs use dynamic type checking part of the time. Every time you do a cast from an Object to a specific type you are doing dynamic type checking - before generics were added in Java 5 this meant every time you used a container class for example. Even when using generic containers some of their type checking is done at runtime. Also every time you have an XML file with class or method names in it them somewhere in the code it has to do a dynamic type check to make sure it matches up with a real class. So many Java programs still have the alleged "dangers" of dynamic typing but with all the verbosity that Java's static typing forces you to add.

I could go on (and often do), but I will stop here with the observation that I have seen a lot of code that is simpler, cleaner and less complex in Python than in Java but none the other way around. If anyone can point me to some then I would love to see it.

Answer 2

Bruce Eckel: They say you can hold seven plus or minus two pieces of information in your mind. I can't remember how to open files in Java.

I can:

new FileInputStream(filename);

I've written chapters on it. I've done it a bunch of times, but it's too many steps. And when I actually analyze it, I realize these are just silly design decisions that they made. Even if they insisted on using the Decorator pattern in java.io, they should have had a convenience constructor for opening files simply.

This is solved in a matter of minutes by writing that utility method with a simple api. And it has been. If that is the strongest criticism than can be directed at Java, I remain distinctly unimpressed.

Answer 3

And yet, of all the programming languages of which I am aware, none of them have gone all-out and decided that their main design goal would be to conquer the complexity of developing and maintaining programs.

Almost every single language is based on conquering complexity. There is no other aim worth pursuing. Assembly, C++, Java, Python, and virtually every other language in existence is based on making programming easier.

How is python good at conquering complexity?

Python definitely has some of the most intuitive syntax of any language IMHO. Its use of block indenting solves a lot of problems, and most of it is as close to plain language as you should get. M = [x for x in S if x % 2 == 0] is a good example, see any python book for countless more.

Is the shorter and more terse syntax of Python a key way to conquer complexity?

I believe the simple syntax of python is a good way of conquering complexity. However, that's the only definitive answer I can give to your other query:

What do you think about conquering complexity?

You are asking the question that is the entire core of language theory, which encompasses battles that will probably rage until the end of time. static vs dynamic typing is one such debate. There are mounds of other developments in language theory like Procedural vs OO vs Functional languages and Aspect Oriented Programming that try to simplify programming. Look at the latest (or any) release of a language to see some examples of what's being done to 'conquer complexity'. There is never going be one definitive answer, and a full discussion of each approach would take a few months to read, and would probably completely change by the time your were done. :D