Java – Python productivity VS Java Productivity

javaproductivityprogramming-languagespython

Over on SO I came across a question regarding which platform, Java or Python is best for developing on Google AppEngine. Many people were boasting of the increased productivity gained from using Python over Java. One thing I would say about the Python vs Java productivity argument, is Java has excellent IDE's to speed up development whereas Python is really lacking in this area because of its dynamic nature.

So even though I prefer to use Python as a language, I don't believe it gives quite the productivity boost compared to Java especially when using a new framework. Obviously if it were Java vs Python and the only editor you could use was VIM then Python would give you a huge productivity boost but when IDE's are brought into the equation its not as clear cut.

I think Java's merits are often solely evaluated on a language level and often on out dated assumptions but Java has many benefits external to the language itself, e.g the JVM (often criticized but offers huge potential), excellent IDE's and tools, huge numbers of third party libraries, platforms etc..

Question: Does Python, or related dynamic languages, really give the huge productivity boosts often talked about (with consideration given to using new frameworks and working with medium to large applications)?

Best Answer

One of Python's major advantages is its "batteries included" philosophy: an extensive and simple to use standard library. In Java, just reading a text file requires several lines of code, nested readers and such. In Python it's f.read(). This will definitely be a huge productivity boost especially in quick prototyping. Python the language is also generally less verbose, which is not a bad thing (although I think the importance of verbosity vs. conciseness is often overemphasized).

However, if you're already working on some framework, such as GAE, then I would expect the differences to be much smaller, and mainly up to one's personal fluency in the language. You'll be mostly just wiring the framework together with the syntax of your choice, and there Python's great standard library helps little.

Related Solutions

Java – When are Getters and Setters Justified

Having getters and setters does not in itself break encapsulation. What does break encapsulation is automatically adding a getter and a setter for every data member (every field, in java lingo), without giving it any thought. While this is better than making all data members public, it is only a small step away.

The point of encapsulation is not that you should not be able to know or to change the object's state from outside the object, but that you should have a reasonable policy for doing it.

Some data members may be entirely internal to the object, and should have neither getters nor setters.
Some data members should be read-only, so they may need getters but not setters.
Some data members may need to be kept consistent with each other. In such a case you would not provide a setter for each one, but a single method for setting them at the same time, so that you can check the values for consistency.
Some data members may only need to be changed in a certain way, such as incremented or decremented by a fixed amount. In this case, you would provide an increment() and/or decrement() method, rather than a setter.
Yet others may actually need to be read-write, and would have both a getter and a setter.

Consider an example of a class Person. Let's say a person has a name, a social security number, and an age. Let's say that we do not allow people to ever change their names or social security numbers. However, the person's age should be incremented by 1 every year. In this case, you would provide a constructor that would initialize the name and the SSN to the given values, and which would initialize the age to 0. You would also provide a method incrementAge(), which would increase the age by 1. You would also provide getters for all three. No setters are required in this case.

In this design you allow the state of the object to be inspected from outside the class, and you allow it to be changed from outside the class. However, you do not allow the state to be changed arbitrarily. There is a policy, which effectively states that the name and the SSN cannot be changed at all, and that the age can be incremented by 1 year at a time.

Now let's say a person also has a salary. And people can change jobs at will, which means their salary will also change. To model this situation we have no other way but to provide a setSalary() method! Allowing the salary to be changed at will is a perfectly reasonable policy in this case.

By the way, in your example, I would give the class Fridge the putCheese() and takeCheese() methods, instead of get_cheese() and set_cheese(). Then you would still have encapsulation.

public class Fridge {
  private List objects;
  private Date warranty;

  /** How the warranty is stored internally is a detail. */
  public Fridge( Date warranty ) {
    // The Fridge can set its internal warranty, but it is not re-exposed.
    setWarranty( warranty );
  }

  /** Doesn't expose how the fridge knows it is empty. */
  public boolean isEmpty() {
    return getObjects().isEmpty();
  }

  /** When the fridge has no more room... */
  public boolean isFull() {
  }

  /** Answers whether the given object will fit. */
  public boolean canStore( Object o ) {
    boolean result = false;

    // Clients may not ask how much room remains in the fridge.
    if( o instanceof PhysicalObject ) {
      PhysicalObject po = (PhysicalObject)o;

      // How the fridge determines its remaining usable volume is a detail.
      // How a physical object determines whether it fits within a specified
      // volume is also a detail.
      result = po.isEnclosedBy( getUsableVolume() );
    }

     return result;
  }

  /** Doesn't expose how the fridge knows its warranty has expired. */
  public boolean isPastWarranty() {
    return getWarranty().before( new Date() );
  }

  /** Doesn't expose how objects are stored in the fridge. */
  public synchronized void store( Object o ) {
    validateExpiration( o );

    // Can the object fit?
    if( canStore( o ) ) {
      getObjects().add( o );
    }
    else {
      throw FridgeFullException( o );
    }
  }

  /** Doesn't expose how objects are removed from the fridge. */
  public synchronized void remove( Object o ) {
    if( !getObjects().contains( o ) ) {
      throw new ObjectNotFoundException( o );
    }

    getObjects().remove( o );

    validateExpiration( o );
  }

  /** Lazily initialized list, an implementation detail. */
  private synchronized List getObjects() {
    if( this.list == null ) { this.list = new List(); }
    return this.list;
  }

  /** How object expiration is determined is also a detail. */
  private void validateExpiration( Object o ) {
    // Objects can answer whether they have gone past a given
    // expiration date. How each object "knows" it has expired
    // is a detail. The Fridge might use a scanner and
    // items might have embedded RFID chips. It's a detail hidden
    // by proper encapsulation.
    if( o implements Expires && ((Expires)o).expiresBefore( today ) ) {
      throw new ExpiredObjectException( o );
    }
  }

  /** This creates a copy of the warranty for immutability purposes. */
  private void setWarranty( Date warranty ) {
    assert warranty != null;
    this.warranty = new Date( warranty.getTime() )
  }
}

When should we stop work and make tool

I "make tools" when one of these is true:

The task is annoying me
The risk of human error in the task is too big

The "risk" for the 2nd option doesn't have to be huge - the cost of building one small tool is usually small, so if all you save is the risk of running a 10-minute build again once a week, it will usually repay itself very fast.

I try to make tools as small as possible - just make the task a little bit easier now, and maybe improve again next time.

This means you only fix the biggest pain each time, and not creating fixes to problems that don't really hurt you.