The Casimir Effect

The Casimir effect: a force from nothing (September 2002) - Physics World - PhysicsWeb

Subversion branching

Ned Batchelder: Subversion branching quick start

The most important thing about Python is that it is Pythonic.

I recently spammed my friends and co-workers with a success story and commented about how Python could be the salvation of a certain project with a particularly gnarled PHP based front end.

I was cautioned by a wise and pragmatistic friend:

Why not suggest Lisp?
http://www.paulgraham.com/avg.html

Latching on to a single language / platform / religion does not guarantee success or salvation.

I appreciate the good advice, but I don't honestly believe that Python is a magical panacea. In fact I don't want to latch on to Python as a single language or platform. Python has been described as "the ultimate glue language" in that it is well suited to tie various other languages and platforms together. What I do want is to explore Python and convince as many people as I can (who I need or want to work with) that Python is currently the best candidate for the default language to use when implementing solutions to the problems we need to solve.

Lisp is the language which forced me to learn a new way of thinking about representing a problem's solution in code and I am a better programmer for it. It introduced me to the concepts of Functional Programming and non-imperative languages.

• Imperative Programming describes an algorithm in terms of how a processor will execute it. Processor friendly.
  
• Functional Programming describes an algorithm in terms of the mathematical relationship between the problem and the solution. Problem friendly.
  
• Declarative Programming describes an algorithm in terms of logical assertions and rules. Human friendly.
  

Lisp is a very very powerful language. It is probably the most prolific implementation of a Functional language. Learning Lisp also made me realize just how powerful a fully dynamic language could be. I've come to think of Lisp as perhaps the most powerful language.

All languages are equally powerful in the sense of being Turing equivalent, but that's not the sense of the word programmers care about. (No one wants to program a Turing machine.) The kind of power programmers care about may not be formally definable, but one way to explain it would be to say that it refers to features you could only get in the less powerful language by writing an interpreter for the more powerful language in it

--Paul Graham http://www.paulgraham.com/avg.html

Ok, so what? Any dynamic language meets this definition power. Perl, Ruby, Python, maybe even PHP (just to list a few of the popular kids). What makes one any more desirable than the others? Religion?

Yes, religion. I'm using a particularly specific definition of religion and I'm using it loosely:

Religion: The collective customs and traditions of a body of people that have formed an organization or an institution to pursue the study of a specific teaching or belief.

Perl has a underlying philosophy: "There's more than one way to do it" (Which Ruby has adopted).

PHP's underlying philosophy is less of a philosophy and more of an excuse:

PHP is not about purity in CS principles or architecture, it is about solving the ugly web problem with an admittedly ugly, but extremely convenient solution.

--Rasmus Lerdorf (the creator of PHP)

The nearest thing Lisp has to a philosophy may be the koan-like description, "The programmable programming language."

Python's underlying philosophy is all about "One obvious way to do it". The Pythonic philosophy.

The Python community ensures that the language represents a collection of a carefully chosen solutions to common problems. Whenever I am about to code in Python there is one question I ask myself (which is the question I was taught to always ask before ever implementing any solution): "Has someone already solved this problem"? I look at the docs for Python's included modules and if I find one I use it. Any problem that can be solved by simply stringing several python modules together can be solved trivially. Solutions like that start to look more and more like Declarative Programming. When i need to take the next step and actually code a solution myself, again, I turn to the community and look for the pythonic way to code the it. I know this will make my code easier to understand for the python programmers who will need to reuse or maintain it later (quite possibly, me!).

Python is a not magical. Python is not an "end-all-be-all" solution. It's simply the "glue" that allows me to mash pre-existing solutions together to form a solution to even larger problems. I've been pretty happy with most Python implementations but that's just a bonus because the implementation is not the language, it's just the interpreter. In turn the language is just a contract between a software developer and a solution. For me, the most important thing about Python is the philosophy. For me Python is the contract between a great philosophy and the community that follows it.

Stuff that has been bothering me

I've been called a whiner. It is true, and I'd like to apologize right now. I'm not sorry I'm a whiner, but I am sorry that my vocal nature isn't positive more often than it's negative.

My company is, apparently, looking for web-developers. I think we need software developers regardless of web experience. Most web developers have bad habits that are hard to break. I don't think we should be in the business of programming web pages. We should be programming tools for building web pages. We should be hiring web-designers who can be trained to use the tools that our software team develops and our software team should be watching and listening to the needs of our web-designers.

When I see how fast we turn projects around, I'm not unhappy but, I'm not satisfied. When I see the code that we produce I think, "This isn't so great. Man, we could do so much better". This code comes mostly from juniors but also from our seniors (this includes myself). Most of our code is most often seen only by the author until it needs to be fixed or reused.

When I make an implementation choice and I ask peers for feedback I sometimes get "That sounds good, lets do that". Other times I hear "Well, why don't you do it this way..." and we have a discussion (usually very productive). The prior is not due to my ability to produce flawless design, but more usually due to the peer's overloading or lack of investment in the details of that particular project. The later is something that should happen to every implementation decision made by every coder.

I know I'm not the greatest tester (most developers are terrible testers) but I get frustrated when fixing the most basic of bugs that weren't found until weeks or months after the fact. I get especially frustrated when they are bugs in my own code and more so again when it was my own testing that didn't catch it.

I really do think we have the potential to be the best at what we do. All we need is to just do it, and do it right!

>>> import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Seven deadly sins of programming

• Sin #7 - Excessive Coupling
  
• Sin #6 - Inappropriately Clever Code
  
• Sin #5 - Deferred Refactoring
  
• Sin #4 - Premature Optimization
  
• Sin #3 - Overuse of Virtual
  
• Sin #2 - Overuse of Inheritance
  
• Sin #1 - Premature Generalization
  

Programming Rules

1. Always write code to be reusable (or re-write code to be re-usable). Never encode the same logic twice.
2. Always make data referenceable. Never encode data within logic or infrastructure.
3. Use meaningful Names with words who's definition fits the concept you are representing. Use a Dictionary or Thesaurus. Avoid plurals and grammatical sugar, stick with root words and descriptive adjectives. (A list of users is a UserList not Users)
4. Everything changes. (Static is good. Dynamic is better.)
5. Everything has scope. (Nothing is global but everything is accessable). (see 2)
6. Code is data. (see 5)
7. If a change to the system can be represented in code, keep the code! (see 6)
8. Everything should be as human readable as possible.
9. Never delete anything. Archive, deactivate, omit or ignore unwanted data. (see 7)
10. Always track data redundancy. Never create redundancy indiscriminately. (see 1)

Define: Game

• a single play of a sport or other contest; "the game lasted two hours"
• a contest with rules to determine a winner; "you need four people to play this game"
• an amusement or pastime; "they played word games"; "he thought of his painting as a game that filled his empty time"; "his life was all fun and games"
• the game equipment needed in order to play a particular game; "the child received several games for his birthday"
• animal hunted for food or sport

Once upon a time there was a not so wise Man.

This Man was sitting atop a mountain, legs in lotus position, palms gently resting towards the sky, in quiet meditation. If you asked this Man what he was doing he would respond, at great length, about the nature of his mediation. He would tell you that his mediation was of a truly zen nature. He would tell you that his meditation gave him terrific mental powers. He would tell you that his mediation gave him memory beyond memory.

Many years ago this Man's memory was said to be quite awful. Many people said this about him, at many times, in many places. After many years of forgetting many things, he decided to change for the better. He began meditation upon this mountain.

If, by some magical ability, you were able to go up that mountain and go to that Man and, without interrupting his meditation, enter his very mind, you would immediately be struck by his inner monologue: "... don't forget the mayonnaise... don't forget the mayonnaise... don't forget the mayonnaise...".

I know this Man.

M.

Imagine this.

You live in suburbia. You have a bomb shelter. You have a neighbour. You see your neighbour mowing his lawn. You see a blinding flash of light. You see a mushroom cloud in the distance. You rush to your shelter and bunker in for the long haul.

Years later, you emerge and what do you see? ... You see your neighbour mowing his lawn. It's the same guy! Mowing the same lawn!!!

M.

Don't expect much.

What do you want from me?