Monday, November 10, 2008

The Attraction of Dynamic Languages.

Today, a friend asked me, "Why are you attracted to dynamic languages?".

I didn't have a ready answer. After thinking about it for a while, I can list some good reasons why I prefer to work in Python, which is a dynamic language. Lately I have been writing a lot of code in C and C# (directly re-implementing Python algorithms), so I think I am in a good place to pass comment.

  1. Python code is ~10% the size of my equivalent C# code. This means less typing, faster prototypes and less room for bugs.

  2. Dynamic languages really do promote loose coupling. There is no dependence on types. This helps the programmer write re-usable code, and actually re-use it, rather than hide it away in some dusty, forgotten SVN repository...

  3. Python works rather well with C. It's a piece of cake to convert a Python function into C code, then call them using ctypes. This fits perfectly with an incremental development method, where a prototype can slowly be converted into C code as needed.

  4. Late binding lets you do some really clever stuff, and makes things like state machines very compact and easy to code and understand.

I've also found a few things in mono.net which I wish I had in Python.

  1. A standard, OS independent socket implementation.

  2. ...hmm not much else.


Have I missed anything?

8 comments:

Anonymous said...

I think reason #1 grasps the essence why. Other points just explain how you reach it ;-)

Anonymous said...

Last week I found myself working in C# after developing a Python proof of concept.

Not only was the python code smaller but I was forced to do so many (cast)'s in C# that I seriously considered changing my name to Harry Potter.

René Dudfield said...

no semi colons.

James Thiele said...

"Have I missed anything?"

Yes.

The standard library rocks.

Anonymous said...

True multi-threading.

Anonymous said...

Did you mean that Python multi-threading drawback? In the Python 2.6 there is a solution: new multiprocessing module.

The standard library rocks, again.

Anonymous said...

@jiri :
True Multithreading would be much more convenient than Multiprocessing.

We use it (so many people recommend it without having ever used it) and it is the only viable solution for a type of architecture/pb.

Still it is inferior to True Multithreading.

Seun Osewa said...

You missed a really big one: you don't have to wait for your code to compile each time you change something. Makes a happy programmer.

Popular Posts