If you're measuring a development job in terms of hours worked, you're doing it wrong. There are too many factors involved in a typical day of work for that to be a meaningful measure. 40 hour is a limit established by the Fair Labor Standards Act that assures overtime. Outside of that, it really doesn't have much meaningful context. Personally I think the 40 hour week (8 hour day) is fine, the bigger question is what you may or may not do beyond those 8 hours per day and how you break them up.
As a manager, I learned to value productivity over activity early in my career. I'm much more a fan of working smarter than harder. It's a quality many people admire, "Look how hard he/she works" but I'm not sure that applies to every job. Some jobs are more productive when you work harder, but in development there is definitely an exponential return on investment for working smarter.
Simply things like leveraging short cuts, snippets, using frameworks, learning how to troubleshoot quickly and effectively, following practices like TDD that uncover defects early in the process, all can lead to more productivity. Personally I think when people start mandating 50 hours, 60, etc. what most developers end up doing is pacing themselves or finding other things to fill the time without necessarily increasing their productivity. I've measured this on many projects and the solution is almost never to work more hours or add more people. Sure, there are sometimes "crunch times" where it makes sense but a lot of times finding the root cause for delays can be traced back to poor requirements, lack of testing, and bad technology choices.
So ... do I think 8 hours is too much? Not really, but I also think it's a meaningless measure for software productivity.