Hacker News Reader

I agree completely. Hardware has gotten orders of magnitude faster, yet the experience, as a user, hasn't changed nearly that much. You'll probably find this comparison interesting: http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_Dua...

I think the saying that programmer time is more expensive than machine time is, like the quote about premature optimisation, responsible for promoting an inherently wasteful culture in programming when people are taught to take them at face value; looking at it another way, power isn't free, and when machine time translates to user time, then the situation definitely changes. I always keep in mind that users are using the software I create to do work, and their time is just as valuable if not more so than my own, especially if there are more of them. To me, it's a question of balancing the tradeoffs --- it's not worth spending a day to optimise software that will save a few minutes across all its users over its lifetime, but it is very well worth it to spend a week to optimise something so that it may save a year or more of its users' time. Whenever a programmer complains about certain tools (e.g. compiler, IDE, etc.) being slow, I keep that in mind to mention the next time he/she flippantly dismisses a time-saving optimisation using the "my time is more expensive" excuse. Programmers are users too. :-)

"Hardware has gotten orders of magnitude faster, yet the experience, as a user, hasn't changed nearly that much."

I see what you mean, but I feel that this misses out an important fact - a lot of those speed increases are only available if you modify your code to use an optimized path. Memory I/O is a classic example - it has sped up a lot but only if you make sure that you aren't generating cache misses on every memory access. Branch-prediction-friendly code is another good example that can make a huge difference to the performance of a system.

That means that a lot of the performance gains that we have achieved (not all, certainly, but a substantial chunk) are not necessarily made available to naively-written code. It is not terribly surprising then that we sometimes struggle to achieve the speed-ups the hardware has made available to us.

This problem is only compounded by the fact that performance is one of the leakiest things going when we are talking about abstraction layers. It makes things extremely difficult to think about because you need to know intimate detail of your entire software stack, which these days is huge, if you wish to effectively optimize your code.

Found this gem in the linked article: Windows Vista demands enough real estate on your hard drive that you could easily fit 30,000 full-length novels into it.

A nitpick: a day of work, say six hours, is only 3600 minutes. If you can optimize some task to save a few minutes per user, it only takes a few thousand users to be worth it.

However, I think the worst optimizations to leave on the table are in an area many developer-types won't think about: usability. We can save much more of a user's time by creating simple, intuitive interfaces than we can checking cache misses (in most modern development).

> We can save much more of a user's time by creating simple, intuitive interfaces than we can checking cache misses (in most modern development).

And at least for regularly-used software, you can save even more user time by not optimising for the first five minutes of usage but for the long-term usage. Keyboard shortcuts are a good example for this: They are mostly not simple and certainly not intuitive per se (why does Alt+Tab switch windows in particular?), yet once you know them, they do save a lot of time.

six hours, is only 3600 minutes

You mean 360.

> Windows Vista demands enough real estate on your hard drive that you could easily fit 30,000 full-length novels into it.

That's an apples to oranges comparison if I ever saw one. It says nothing about whether Vista is bloated for the features it provides, by itself.

In terms of balancing tradeoffs, I continue to find this cheat-sheet useful whenever the topic comes up.

http://xkcd.com/1205/

Exactly How I feel. We are adding up abstraction over abstraction, backwards compatibility, hardware compatibility, software compatibility, unrelated ui/ux features, animations..

I believe modern computing has 80/20 rule in a bad way. We use 80 percent of the computing power to do unrelated 20 percent of the job.

we need to re-find Unix philosophy for modern day computing. Software should do a single task but do it well.

Also have a look at Zawinski's Law. http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law...

I wonder how much of the Unix philosophy is accidental success. 'Do one thing well' is a (relatively) easy way to make something that actually works correctly, so I guess I'm wondering if doing one thing is actually important, or if actually doing something in a consistent, reliable and predictable way is the more important aspect.

(Small programs that enable composition are great, but so is, for example, a program that can uncompress any format in place with only an option or two)

The Unix Philosophy is an attitude not a philosophy. Unix doesn’t have a philosophy: it has an attitude. An attitude that says a simple, half-done job is more virtuous than a complex,well-executed one. An attitude that asserts the programmer’s time is more important than the user’s time, even if there are thousands of users for every programmer. It’s an attitude that praises the lowest common denominator

• Small is beautiful.

• 10 percent of the work solves 90 percent of the problems.

• When faced with a choice, do whatever is simpler.

Which sounds good until realize that these comments mean the exact same thing.

• A small program is more desirable than a program that is functional or correct.

• A shoddy job is perfectly acceptable.

• When faced with a choice, cop out.

And when you need to glue lots of things together that do just a single task, you end up spending much more (development and run) time at the joints, as in, constantly converting and parsing data again.

Unix pipes are very effective I believe.

Serializing and deserializing heavily structured data in order to fit over a unix pipe takes a lot of effort - I'm often doing things where the reading and writing data takes up more code and processing time than the actual processing, which is simple once the data is in a sane data structure, not in a stream.

If your data structure is "a line of text, repeated x times" or "a blob representing an image", then unix pipes are very effective. For most everything else, they're not.

right, because you don't have to parse data coming over a pipe. :rolleyes:

> It's year 2014 and you have to wait for your computer. It's so much faster than you, but you are waiting for it!

The same is also evident on the web. In so many cases you need to wait for content, maybe couple of KB of text, to load even with our tens of Mb/s at last mile and tens of Gb/s at datacenter.

http://en.wikipedia.org/wiki/Wirth%27s_law

This is just due to the ridiculous way the development ecosystem for the web has grown. Nobody seems to care about fast languages anymore.

Check out this website. http://forum.dlang.org/

Notice how amazingly fast it is. It's written in D.

Oh, but I forgot, the bottleneck is in the database so feel free to waste millions of cycles every request chasing pointers around and around the vast quantities of memory that your dynamic language consumes.

People don't even know what speed is anymore.

Just because it is written in D doesn't automatically make it fast. If you were to run that program on an underpowered host with a database system that has to constantly swap, with not enough CPU time available it would be slow too.

And that is the bigger problem, people are running their websites on underpowered hardware in the first place. The limit should be the network connection, not the page rendering time... but unfortunately that isn't always the case.

Perhaps its because some people are more productive with dynamic languages and they value productivity over speed.

That's exactly it (and it's a message we've been hearing over and over for the past decade at least -- "worry about being productive, if it's slow, Moore's law will fix it for you in a few years").

The thing is, in some cases, all the productivity ends up costing a lot more. For small shops it will not be evident, but for bigger ones trying to scale, it'll be a major area of improvement (to use less cycles).

And that's OK... comes down to using the right tool for the right job, matching the skills of your developers with the challenge, how fast you want things delivered, etc, etc, etc.

I think the major issue people see is that when all of that slow programs are looked from a 10,000 feet view as a single thing, it looks like a damn waste of resources. Thus comments like "computing (as a whole) in the last X years has been terrible", etc. We can delve into programmer culture, lack of skills, people not caring about wasting resources, etc, etc, etc.

I think the solution is better tooling. Let the programmer be productive, deliver things fast, etc, but build something more intelligent that will strip it down to only the necessary bits and deploy.

I find this hard to believe. Any time people write systems in a dynamic language, they inevitably run into issues as they scale, ending up wasting money (computers, electricity) and a lot of user time. This usually results in rewriting things over and over.

Performance is always important. If you can solve a problem in 10% more time using a performant language, then it makes sense to do so, and I've seen few problems that I can express in Python or Ruby (painfully slow) that I cannot express in C++ (highly performant) or Scala (moderately performant) in roughly that amount of extra time.

Time is not perfectly fungible. The only way to save time early on (prototyping and delivering products early on) may result in spending a lot of time later on.

Do you have any actual data to back your wild assertions? Entire domains of computer science are dedicated to productivity languages and many are widely used with great success and little or no overhead relative to C. (edit: for example scipy)

I was stating an opinion based on my experience. I don't deny that tools like SciPy are very useful for experimental programming. However SciPy and Matlab are exceptions, where the end-user of the program is also the programmer, so the developer experience IS the user experience.

In most cases, when you are a professional developer, you are not the end-user of your product. In these cases, deliberately choosing a less performant language for the sake of developer productivity can mean you end up penalizing the end user.

Good point, and I think that that's why languages like Java and C# are very popular these days - they hit a good balance between performance and developer productivity.

The danger with the "speed doesn't matter" attitude is that you end up with a 10x slowdown due to language choice, and then another 10x slowdown due to inefficient implementation, and you end up with a 100x slowdown, which might actually be significant even in situations where speed doesn't matter that match.

The sentiment you just wrote is one of the chief inspirations for the TechEmpower Framework Benchmarks project that I'm part of. Today, we routinely see huge amounts of computational horsepower evaporated in the name of developer efficiency. Yet the modern web development ecosystem is so plentiful and diverse that there are myriad high-productivity platforms and frameworks that exploit computational horsepower rather than squander it.

My opinion is that investing the modest effort to select a high-performance platform and framework gives you the freedom to write inefficient application code first and to optimize later. It is the process that allows you to avoid the most expensive kind of premature optimization I've seen by postponing optimization until well after an application's concept has been vetted by its first several thousand users.

To me, one of the really mind boogling things in terms of waste is how we today basically create piles of complete systems just to run a single application. The system used to run a single application is filled with other applications, libraries and functions that are never used.

And the application being run is probably using shared lib and other complex mechanisms designed for shared environments when no sharing will in fact happen.

Yes, these servers are virtual and just part of a file. But the overhead in space and energy is still mind boggling.

Do you know what would make people instantly realise how fast computers are?

Reaction: a program that reads a camera and reacts to some user action instantly moving a robot arm. Add to that an ultra-slow-motion camera so we can see what happened afterwards.

There's a passage in Stephen Levy's book "Hackers" where he talks about a robot built by some students at MIT that could catch a ping pong ball thrown to it by a human. I don't recall what year this project was done, but I do recall what computer they used: a PDP-6.

So a computer built 50 years ago is already fast enough to pass your instant-reaction test. (Well, admittedly, maybe it didn't respond instantly, but if it could catch a thrown ping pong ball, it was probably pretty quick).

This comment isn't meant to scoff at your suggestion -- far from it -- I think an instant-reaction-bot will still impress most people (and rightfully so). I just wonder if we, as programmers and scientists and engineers, haven't been taking as much advantage of Moore' law as we ought to.

This demo about sketchpad is pretty impressive, too. http://www.youtube.com/watch?v=USyoT_Ha_bA You look at what they were able to accomplish, and it just seems like we lost a lot of steam somewhere.

yayitswei posted a link to a robot that produces the effect I meant. A modern version of the catcher that could outperform a human would be nice too. Or the knife trick by the robot in Aliens.

Also I saw some news about a spanish uni developing one robot arm to catch space debris.

The thing is we still don't realize how fast they really are. We say all the time that computers are dumb. The perception is somewhat distorted for most people.

Moore's law has been almost completely eaten by the screen growth. That's the easiest least imaginative way.

Reminds me of the robot that wins rock-paper-scissors every time: http://www.theguardian.com/technology/video/2013/nov/06/japa...

The computers are fast point really strikes a cord with me. Because so much of what programmers do seems to be about using abstractions and infrastructure to achieve things that are too slow when written naively in actual code. Just try plotting some 3D data using python. Should I use matplotlib, or a game engine, or maybe OpenGL? Each option could be too slow, even though the machine can easily process the raw data almost instantly.