3 ms·

IMO, that quote's garbage and really "back in my day". Our resources are just more powerful today. We still run into performance issues with things like bulk

by hoka 13y ago

IMO, that quote's garbage and really "back in my day". Our resources are just more powerful today. We still run into performance issues with things like bulk updates and computation times (MapReduce / distributed computing) quite frequently.

georgemcbay 13y ago
I wouldn't say the quote is garbage, there's truth to the idea that over time we have to worry a little bit less about cleverly dealing with resources, assuming the amount of resources we care about remains static... But of course they don't. The really interesting thing about the quote is that it is from 1986 but could have been stated the same way in 1996, 2006 and likely in 2016 with the same "10 year back" qualifier and nobody would bat an eyelash. Systems are way more powerful but we're also pushing a LOT more data (in terms of depth of the data, breadth of the data, and types of data). To be fair though, these days a lot of people see "spin up 25 more AWS instances" as a perfectly valid way of solving a bottleneck when compared to months of developer time whereas back in 1986 the decision would be a no-brainer in the other direction given that the equivalent of spinning up 25 AWS instances today would be economically infeasible back then for almost any commercial entity (even if you scaled back the amount of processing needed to fit in the context of that era).
bottompair 13y ago
Ironic language given that most "engineers" today can't write code without dependency on built in garbage collectors. Do you really think developers these days are just as good at optimizing for limited system resources as they were in 1986? "We still run into..." Who? Maybe you - but most developers aren't running into map/reduce problems every day. And when they do, they certainly aren't coding a solution from scratch.
- boomzilla 13y ago
  I think what really happens is that programmer/software engineer profession have become a lot more accessible to the mass. Back in billg days when he started programming, I would bet less than 1000 kids around the country had access to a computer. In 1986, the total number of programmers would've surely been less than 10,000 and most of them worked for MS, IBM, DEC, etc. In the current time, half of SF are software engineers and entrepreneurs :) I guess my point is there are still a lot of people who work on the hard core stuff like Linux/Windows kernels where every byte counts, or JVM/LLVM where data structures/algorithms are rewritten over and over to get a bit more performance. I would say the number of programmers who have to care about the optimizing system resources may be even more than back then, it's just that there are a lot more application developers these days.
- hoka 13y ago
  I guess my original post was focused on map/reduce problems; I meant it to be more general. We take our site response time very seriously, and therefore our application code and data layer has to be very fast. Yes boxes are faster and easier to spin up. The 'downside' to that is that many website on the internet are blazingly fast: Google, Amazon, Dropbox, etc. Because they are so fast (or perceptibly fast via tricks), the rest of the web is held to that higher standard. Twenty years ago, things taking a long time on a computer screen with no updates was acceptable. Today it really isn't because there are N other websites that are selling your exact product or experience.
- erkkie 13y ago
  Maybe these days other metrics are more important to optimize for? Ultimately it is about transforming money (resources) into output (more resources) and depending on times different things bottle-neck you there.
  - peterpathname 13y ago
    optimise for maintainability, reusability, composibility
    - erkkie 13y ago
      and talent pool availability
kamaal 13y ago
>>Our resources are just more powerful today Have you ever programmed a embedded system? Every worked on a 8-bit micro controller? There are hard, very hard problems that come up which have to solved in with really limited resources.
- hoka 13y ago
  I sure have. I've written k-maps and wired a multi-bit ALU by hand. My point is that those problems aren't any harder. They're just different. (in many cases it's because the toolchains stink by modern standards--embedded systems tend to just crash with no helpful debugging information) BG and co stood on the shoulders of the guys who made their chips 'just work' just as we stand on their shoulders. To complain about how 'kids have it so easy these days' just makes you sound crotchety.
  - valarauca1 13y ago
    >My point is that those problems aren't any harder. They're just different. Not really. The problems are made a lot harder by finite memory being more in play. Even with a good tool-chain when you actually have more data then you have RAM then you'll run into problems that are completely unique to an embedded world. Code shrinks are very hard.
coldtea 13y ago
>IMO, that quote's garbage and really "back in my day". Our resources are just more powerful today. Which is the whole point if the quote. And the "back in my day" is 100% true in the field of programming. Ever heard of Moore's law? Ever tried to program with 8K RAM? >We still run into performance issues with things like bulk updates and computation times (MapReduce / distributed computing) quite frequently. Yes, we still run into "performance issues". But with MILLION times the data they ran into performance issues with. Heck, we can now do a whole computer of the time interpreted in a web browser in Javascript and still get acceptable speed to play games in it. Perspective man.
- acqq 13y ago
  To illustrate coldtea's point: http://bellard.org/jslinux/ http://bellard.org/jslinux/ You've just fully booted linux in your browser. That Linux sees 16 MB RAM for itself. If you are a web programmer, do you even try to see how much memory the browser spent for this, or any other page you click to?
- bad_user 13y ago
  Nowadays in-browser Javascript is able to execute algorithms in under 1 second that would have taken tens of minutes or hours to compute in the late eighties. Back then, even a dumb spell-checker like that one implemented by Peter Norvig in Python, would have been problematic and was considered a major feat. If a software engineer from the eighties would travel forward in time, he'd be amazed that we are carrying super-computers in our pockets.
  - pseut 13y ago
    I like the implication that these "software engineers from the eighties" are absurdly rare creatures that no longer exist. edit: but yes, it's amazing.

by hoka 13y ago

georgemcbay 13y ago

I wouldn't say the quote is garbage, there's truth to the idea that over time we have to worry a little bit less about cleverly dealing with resources, assuming the amount of resources we care about remains static... But of course they don't. The really interesting thing about the quote is that it is from 1986 but could have been stated the same way in 1996, 2006 and likely in 2016 with the same "10 year back" qualifier and nobody would bat an eyelash. Systems are way more powerful but we're also pushing a LOT more data (in terms of depth of the data, breadth of the data, and types of data). To be fair though, these days a lot of people see "spin up 25 more AWS instances" as a perfectly valid way of solving a bottleneck when compared to months of developer time whereas back in 1986 the decision would be a no-brainer in the other direction given that the equivalent of spinning up 25 AWS instances today would be economically infeasible back then for almost any commercial entity (even if you scaled back the amount of processing needed to fit in the context of that era).

bottompair 13y ago

Ironic language given that most "engineers" today can't write code without dependency on built in garbage collectors. Do you really think developers these days are just as good at optimizing for limited system resources as they were in 1986? "We still run into..." Who? Maybe you - but most developers aren't running into map/reduce problems every day. And when they do, they certainly aren't coding a solution from scratch.

boomzilla 13y ago
I think what really happens is that programmer/software engineer profession have become a lot more accessible to the mass. Back in billg days when he started programming, I would bet less than 1000 kids around the country had access to a computer. In 1986, the total number of programmers would've surely been less than 10,000 and most of them worked for MS, IBM, DEC, etc. In the current time, half of SF are software engineers and entrepreneurs :) I guess my point is there are still a lot of people who work on the hard core stuff like Linux/Windows kernels where every byte counts, or JVM/LLVM where data structures/algorithms are rewritten over and over to get a bit more performance. I would say the number of programmers who have to care about the optimizing system resources may be even more than back then, it's just that there are a lot more application developers these days.
hoka 13y ago
I guess my original post was focused on map/reduce problems; I meant it to be more general. We take our site response time very seriously, and therefore our application code and data layer has to be very fast. Yes boxes are faster and easier to spin up. The 'downside' to that is that many website on the internet are blazingly fast: Google, Amazon, Dropbox, etc. Because they are so fast (or perceptibly fast via tricks), the rest of the web is held to that higher standard. Twenty years ago, things taking a long time on a computer screen with no updates was acceptable. Today it really isn't because there are N other websites that are selling your exact product or experience.
erkkie 13y ago
Maybe these days other metrics are more important to optimize for? Ultimately it is about transforming money (resources) into output (more resources) and depending on times different things bottle-neck you there.
- peterpathname 13y ago
  optimise for maintainability, reusability, composibility
  - erkkie 13y ago
    and talent pool availability

kamaal 13y ago

>>Our resources are just more powerful today Have you ever programmed a embedded system? Every worked on a 8-bit micro controller? There are hard, very hard problems that come up which have to solved in with really limited resources.

hoka 13y ago
I sure have. I've written k-maps and wired a multi-bit ALU by hand. My point is that those problems aren't any harder. They're just different. (in many cases it's because the toolchains stink by modern standards--embedded systems tend to just crash with no helpful debugging information) BG and co stood on the shoulders of the guys who made their chips 'just work' just as we stand on their shoulders. To complain about how 'kids have it so easy these days' just makes you sound crotchety.
- valarauca1 13y ago
  >My point is that those problems aren't any harder. They're just different. Not really. The problems are made a lot harder by finite memory being more in play. Even with a good tool-chain when you actually have more data then you have RAM then you'll run into problems that are completely unique to an embedded world. Code shrinks are very hard.

coldtea 13y ago

>IMO, that quote's garbage and really "back in my day". Our resources are just more powerful today. Which is the whole point if the quote. And the "back in my day" is 100% true in the field of programming. Ever heard of Moore's law? Ever tried to program with 8K RAM? >We still run into performance issues with things like bulk updates and computation times (MapReduce / distributed computing) quite frequently. Yes, we still run into "performance issues". But with MILLION times the data they ran into performance issues with. Heck, we can now do a whole computer of the time interpreted in a web browser in Javascript and still get acceptable speed to play games in it. Perspective man.

acqq 13y ago
To illustrate coldtea's point: http://bellard.org/jslinux/ http://bellard.org/jslinux/ You've just fully booted linux in your browser. That Linux sees 16 MB RAM for itself. If you are a web programmer, do you even try to see how much memory the browser spent for this, or any other page you click to?
bad_user 13y ago
Nowadays in-browser Javascript is able to execute algorithms in under 1 second that would have taken tens of minutes or hours to compute in the late eighties. Back then, even a dumb spell-checker like that one implemented by Peter Norvig in Python, would have been problematic and was considered a major feat. If a software engineer from the eighties would travel forward in time, he'd be amazed that we are carrying super-computers in our pockets.
- pseut 13y ago
  I like the implication that these "software engineers from the eighties" are absurdly rare creatures that no longer exist. edit: but yes, it's amazing.