On rapid iteration

I think that one of the great strengths of interpreted languages like Python is the ability to iterate rapidly, due to the lack of a compilation step.

I've been reading Richard Feynmann's fascinating reminiscences in Surely You're Joking, Mr. Feynmann. The entire text is available online.

One passage that really struck me was where he described the cyclotrons at Princeton, MIT, and Cornell:

It reminded me of my lab at home. Nothing at MIT had ever reminded me of my lab at home. I suddenly realized why Princeton was getting results. They were working with the instrument. They built the instrument; they knew where everything was, they knew how everything worked, there was no engineer involved, except maybe he was working there too. It was much smaller than the cyclotron at MIT, and "gold-plated"? — it was the exact opposite. When they wanted to fix a vacuum, they'd drip glyptal on it, so there were drops of glyptal on the floor. It was wonderful! Because they worked with it. They didn't have to sit in another room and push buttons! (Incidentally, they had a fire in that room, because of all the chaotic mess that they had — too many wires — and it destroyed the cyclotron. But I'd better not tell about that!)

(When I got to Cornell I went to look at the cyclotron there. This
cyclotron hardly required a room: It was about a yard across — the diameter of the whole thing. It was the world's smallest cyclotron, but they had got fantastic results. They had all kinds of special techniques and tricks. If they wanted to change something in the "D's" — the D-shaped half circles that the particles go around — they'd take a screwdriver, and remove the D's by hand, fix them, and put them back. At Princeton it was a lot harder, and at MIT you had to take a crane that came rolling across the ceiling, lower the hooks, and it was a hellllll of a job.)

Princeton and Cornell had inferior equipment, but they got superior results partly because of the quick iteration loop, eliminating the step of waiting on the engineers to make changes. Scientists at these schools could very quickly try something, make adjustments, and try again, where at MIT the same adjustments took a lot of time.

Shuji Nakamura, inventor of the blue LED, said something similar about his work:

I had a very, very small budget and had to make everything I needed myself. I even made my own reactors—the furnaces needed to do the crystal work.

Nakamura succeeded in creating a blue LED, working by himself, when huge multinationals were pouring hundreds of millions of dollars into R&D without results. Elsewhere, he commented that the ability to make adjustments to his equipment quickly, without getting engineers involved, was one of the secrets to his success.

It struck me that this is one of the reasons why I get better results with Python than with compiled languages like C and C++. With Python, there's no compiler in the loop, so the iteration cycle is very fast — rarely more than 10 seconds to run all the unit tests.

This affects every part of the development cycle. Development itself is a lot faster, so you get more done. With a faster cycle, refactoring code in small steps is also quick and painless, so it's easier to evolve code. The cost of trying out new ideas is low, so you're encouraged to prototype lots of designs to get the best ones.

I think that in just about any kind of creative endeavor, the ability to rapidly iterate between creation and feedback gives a tremendous boost to productivity. This is one of the reasons why I'm so much more productive with Python.

3 comments to On rapid iteration

  • Mameha

    You can also apply it to translation.

    I co-ordinate translations from English to other languages so we can run our website in 7 languages. 4 of the translators give me work back within a week, 2 of the others need chasing and take about 2 months, and the final language often doesn’t come back at all. As a result, sometimes I have to come back to a job (e.g. making an illustration with text on it, or a flash animation) 2 months after I started on it – by which time I have forgotten the concept and where the source files are kept, and I have to go through this time consuming period of getting all relevant info into my short term memory.

  • @Mameha

    I agree. Just about any creative endeavor benefits. Your case also demonstrates that you get more done when you can hold the entire problem in your head, rather than having to keep loading it in chunks over time. That’s why it’s productive to break a problem into sub-problems, not mix layers of abstraction, modularize, etc.

  • Most definitely, I’ve developed my application with Python and dread to go back to any compiled languages due to that waiting stage. From Ecilpse I hit F5 and my program is there, anything with Java results in me twiddling my fingers, especially if it required database connections.

    It wouldn’t be too much of an issue at the moment if my program wasn’t in Python due to its small size, but working for some large program for a company…ugh! I can only imagine.

    I feel with python and wxpython I just produce so much functionality from so little code. Or, if I do make a mess of things by needing large volumes of code I can always go back and refactor eazily

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>