Sean KellyRecovery from Addiction

A taste of the Python programming language's concision and elegance from someone who once suffered an addiction to the Java programming language.

This item is part of the collection: Open Source Movies

Producer: Sean Kelly
Keywords: Python; Java; Screencast

Creative Commons license: Attribution

Write a review Reviews

Downloaded 19,856 times Average Rating:

Reviewer: carterson2 - - November 8, 2007
Subject: Embedded or Web only?

I tried python and it is dirt-easy to read.

Thats exactly what I love about it,
YOU CAN READ IT.

I worked at intellon.com and they do embedded C++ with nucleus. What a fuc-ing mess. Only one programmer there could figure it out. What job security!

Thats when I learned that NASA used python and then I looked at python code samples, and hot-damn you can actually read it! I got a networking package named scapy.py to work in a day to do extensive network testing!

C++ is the write-only language for sure. You cant modify it unless you authored it. I wonder if UML will help in maintaining C++, but its not there yet.

My only question is: Do you think it will end up in embedded devices? Sean, you mentioned that you use python on web, but I need embedded compilers. I don't know how hard to push for embedded compilers for python to augment/replace C++.

Thanks for publishing!

Reviewer: Peter Cardona - - August 8, 2006
Subject: hmm

I'm not addicted to Java. It works well for some things (and some clients) and not so well for others. However, I think your comparison is a bit off.

In particular, the benefit of encapsulation is like the benefit of defensive driving. You shouldn't need to do it, but your life is possibly better (longer?) when you do. Few people intentionally cause traffic accidents and yes, we're all consenting adults on the road too.

In any system big enough to require a team of 2 or more programmers, encapsulation helps to prevent the _accidental_ creation of defects. You thoughtfully define your interface and then implement it. No chance of someone making a mistake by going around it.

Further, your complaint that clients of the Java class would have to be updated also misses the point. If the interface changes, its clients ought to be reviewed! A client-incompatible change is a signal that the interface has changed enough that the client should get a review.

In your example, you added an exception that's thrown when the input is invalid. I think Java happens to do a great job at signalling that the client code isn't expecting that exception and thus should be reviewed.

Ultimately, on a large project, you don't always know who's using the class and how. Encapsulation (and strong typing) help by letting the class designer specify an interface. When that's done well, mistakes across class boundaries are few.