> You should worry. If you don't want your server or your app to run slow, you should worry about these things.

I am pretty sure he is saying he doesn't have to manually allocate and free memory and worry about off by one errors when iterating. He is comparing equivalents; he isn't saying since I am using Python I can shove 1 billion numbers in a list.

> Can you imagine going into a programming interview and saying something like this?

The only occasion when programming interviews have any significance is when you are seeking a job. Using them as a benchmark for anything else is flawed.

> It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing around dictionaries of dictionaries and lists.

Translating proven, classical design patterns to Python or Ruby will result in shitty code. The proven design patterns don't have to be the same for all languages. It's idiomatic to use dictionaries/list in place of classes where applicable.

http://norvig.com/design-patterns/

https://www.youtube.com/watch?v=0vJJlVBVTFg

http://designpatternsinruby.com/

Depends what the job is for. Honestly, 90% of the web sites being made out there work just find with dictionaries and lists. It's a reality of the times that the largest employment market is for relatively simple code right now.

You sound like someone who doesn't really understand performance very well. Lists and strings and arrays as implemented in any scripting language can implement virtually any algorithm with only a constant factor performance and memory penalty. (Try to come up with a counter-example to that statement, I dare you.) Switching from language to language comes with similar factors. If you discover that you've got a problem that requires you to worry about data structures at that level, worry about it then. Possibly you should use a more efficient language.

But for most apps and websites, those constant factors are really not a big deal. Basic algorithm mistakes are a different story.

For the exceptional cases, you should build working code first, then use a profiler to figure out where your problems are. You should only worry about performance after identifying actual bottlenecks.

If I interview with a company that uses a scripting language and does not understand all of that, that's a pretty good sign that I don't want to work there. Because their opinions on performance are clearly misguided, and I don't want to have to work with what they thought would be "optimized code".

But in 10 years of Python programming, I see 2 repeated performance anti-patterns:

1) Writing quadratic loops and not realizing it, then it blows up on a biggish data set. This is quite easy to do in Python because people don't realize that "in" on a list and .remove() and so forth do a linear search.

2) Writing Python like Java, where you have tons of indirection, which is slow. People somehow feel naked when they only have to type 10 characters rather than banging out a bunch of boilerplate for a mundane task.

When you're just using basic data structures in an idiomatic way, Python is fast. I think there were some dictionary-heavy benchmarks I saw awhile ago where Python is faster than Go, because its dictionaries are so highly tuned.

I've actually just introduced one of my younger colleagues (and pretty new to Python, but knowledgeable in C# and Java) to this 8-year old article: http://dirtsimple.org/2004/12/python-is-not-java.html

I remember reading that article back in the day, I had only begun to do stuff in Python for a year or so, and everything seemed so well explained but here I am now instead still spreading the word :) At least some part of it I hope it's done for good, such as "XML is not the answer", which actually brings back "horrific" memories of Zope3.

But how about substring search? Using Python's string.find instead of something like a suffix tree certainly carries more than a constant time penalty (Obviously for memory complexity it's the other way around in this case). The same goes for blindly using a standard Python list when you plan to insert lots of items in the middle.

Not knowing the complexity of operations on standard data structures inevitably leads to "basic algorithm mistakes". How would you choose a good algorithm without knowing the datastrucure it's operating on?

But in general, it is best to just try to be reasonably sane and not worry about it until you have a proven problem. A surprising fraction of the time, a "reasonably sane" approach is not that far off from optimal. And setting the bar there helps development speed.

Which, of course, is what you care about when you choose to use a scripting language. If you care more about computer time than developer time, then using a more efficient language makes sense.

(I don't think Google are stupid, I think their ratio probably has shifted to the point where their hardware budget is comparable to their salary budget. Which makes them a very unusual case)

That's exactly what he said.

FWIW, I agree with both. Use when needed but you need to understand the abstraction layers that high level languages bring you and when to not use them. And why.

You mean if you are memory or cpu-bound and not IO bound?

But having done his own analysis of the tradeoffs, he doesn't find if valuable to worry about performance overly for the kinds of problems he now works on.