5 ms·

> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. You should worry. If you don't want

> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? It's pretty difficult to implement reliable, readable and proven design patterns if you're just passing around dictionaries of dictionaries and lists. It's more difficult to test. I'm not saying everything needs to be a class, they're a nice tool to have in your toolbox. Use when needed.

olliesaunders 14y ago
Really depends on the kind of programming.
gridaphobe 14y ago
> I'm not saying everything needs to be a class, they're a nice tool to have in your toolbox. Use when needed. That's exactly what he said.
- jonathanwallace 14y ago
  It sounds like they would differ on which circumstances would justify OOP. 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.
mangala 14y ago
Take it down a notch. This is a blog post about modern programming, not a tech interview.
untog 14y ago
Can you imagine going into a programming interview and saying something like this? 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.
irahul 14y ago
>> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. > 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/ http://norvig.com/design-patterns/ https://www.youtube.com/watch?v=0vJJlVBVTFg https://www.youtube.com/watch?v=0vJJlVBVTFg http://designpatternsinruby.com/ http://designpatternsinruby.com/
darkarmani 14y ago
> You should worry. If you don't want your server or your app to run slow, you should worry about these things. You mean if you are memory or cpu-bound and not IO bound?
jerf 14y ago
It seems like someone always pops up when a dadgum.com article comes up that is anything less than 100% focused on performance, and I once again find myself recommending that you review the sidebar. Anyone who has programmed games on the Super Nintendo, a machine with specs that would be inadequate for a USB bus controller nowadays, understands performance just fine. It's just that he's also come to understand when it doesn't matter, something that some of his fellow assembler programmers don't always end up working out.
btilly 14y ago
You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? 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".
- zanny 14y ago
  Cache coherency matters, and making sure a large data structure fits in memory is important too. If you can't fit it, at least make it nicely match up to page boundaries. If you don't understandt he implementation of your choice array / set / map / tuple data structure that you are throwing around all over the place, you could be missing plenty of performance just from TLB misses or some other hardware voodoo.
  - Evbn 14y ago
    This matters if you are Google, serving gigabytes of data per user for free. This matters less for sites whose compute budget is 10% of their human budget, where trying to cut from 2x to 1x on compute isn't worth the human cost.
    - justincormack 14y ago
sea6ear 14y ago
From other reading on this blog, he has a past doing assembly based game programming. It's clear from those other posts that he could care if he wanted to. 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.
deleted 14y ago
[deleted]

olliesaunders 14y ago

Really depends on the kind of programming.

gridaphobe 14y ago

> I'm not saying everything needs to be a class, they're a nice tool to have in your toolbox. Use when needed. That's exactly what he said.

jonathanwallace 14y ago
It sounds like they would differ on which circumstances would justify OOP. 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.

mangala 14y ago

Take it down a notch. This is a blog post about modern programming, not a tech interview.

untog 14y ago

Can you imagine going into a programming interview and saying something like this? 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.

irahul 14y ago

>> I use lists and strings and arrays with no concern about how many elements they contain or where the memory comes from. > 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/ http://norvig.com/design-patterns/ https://www.youtube.com/watch?v=0vJJlVBVTFg https://www.youtube.com/watch?v=0vJJlVBVTFg http://designpatternsinruby.com/ http://designpatternsinruby.com/

darkarmani 14y ago

> You should worry. If you don't want your server or your app to run slow, you should worry about these things. You mean if you are memory or cpu-bound and not IO bound?

jerf 14y ago

It seems like someone always pops up when a dadgum.com article comes up that is anything less than 100% focused on performance, and I once again find myself recommending that you review the sidebar. Anyone who has programmed games on the Super Nintendo, a machine with specs that would be inadequate for a USB bus controller nowadays, understands performance just fine. It's just that he's also come to understand when it doesn't matter, something that some of his fellow assembler programmers don't always end up working out.

btilly 14y ago

You should worry. If you don't want your server or your app to run slow, you should worry about these things. Can you imagine going into a programming interview and saying something like this? 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".

zanny 14y ago
Cache coherency matters, and making sure a large data structure fits in memory is important too. If you can't fit it, at least make it nicely match up to page boundaries. If you don't understandt he implementation of your choice array / set / map / tuple data structure that you are throwing around all over the place, you could be missing plenty of performance just from TLB misses or some other hardware voodoo.
- Evbn 14y ago
  This matters if you are Google, serving gigabytes of data per user for free. This matters less for sites whose compute budget is 10% of their human budget, where trying to cut from 2x to 1x on compute isn't worth the human cost.
  - justincormack 14y ago

sea6ear 14y ago

From other reading on this blog, he has a past doing assembly based game programming. It's clear from those other posts that he could care if he wanted to. 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.

deleted 14y ago

[deleted]