It sounds like you're just getting the benefit of having a set of libraries that you like and know well. There's certainly nothing wrong with that. I might look at the Zend stuff again if I end up doing any more large PHP projects.

Maybe the problem here is the definition of "framework". In my mind the whole point of a framework is to impose itself on the programmer. Typically along the lines of:

• there shall be three tiers to your application;
• we'll call them model, view, and controller even if your app just provides an API and doesn't require a "view";
• we'll make using stored procedures really difficult;
• we'll wrap SQL with an ORM that's less powerful, slower, takes just as long to learn, and isn't used anywhere else in the industry;
• we'll replace mod_rewrite with our own request router that's less powerful, slower, takes just as long to learn, and isn't used anywhere else in the industry;

I feel the frustration level rising just remembering all this. But it sounds like you get my point quite well and, like I said, I'll take a second look at Zend based on your comments - thanks.

This has gone off-topic, but... the various caching solutions don't always work. Since PHP discards all of its data with each request, complex data-structures that are slow to assemble but fast to access aren't possible. In this case I've suggested C or Java (or even Python) because the data can be loaded into RAM and pumped out at a high rate by traversing some carefully constructed data structures. Something like memcache can help a bit, but traversing the a large linked data structure still ends up being slow. Memcache helps when you can look up your result using a single key - it doesn't do much to speed up complex multi-index queries.

This is obviously an edge case - SQL stored procedures or one of the caching solutions will do the trick for most applications - but really this job would be far easier with a different choice of tools. This complaint is only tangentially related to frameworks, though. The frameworks aren't the problem here, but more the one-size-fits-all attitude that seems to come with them.

The patterns are really the crux of the problem. Design patterns are an excellent tool, but applying the same design pattern to every problem doesn't make sense. They need to be selected to match the problem. That's where the frameworks go wrong. At least the ones I've seen attempt to wedge everything an MVC pattern on the server side, which really leads to a lot of confusion (and enough misunderstanding of what MVC means that the term no longer means anything).

If you can really use the Zend libraries without pulling in all the other cruft than that's great. Choose them if they suit the task. Then you're really just doing what I suggested to begin with - selecting the best libraries for the job. (My impression was that this wasn't possible, but I didn't dig very deeply into Zend - by the time I looked at it I'd already developed a deep hatred of frameworks.)

Apache is generic knowledge in that you can apply it to a wider range of problems, and since every installation needs a web server, it's not something "extra". You have the tool already - learn to use it. Same with Nginx or one of the SQL servers. Every component you add has a cost in maintenance and complexity, so don't add more components until you've fully exploited the existing ones.

My main complaint with frameworks isn't efficiency. But you have touched on another problem. I know one poor sucker whose life is now devoted to trying to optimize an all-php solution, when a few weeks of investment in a Jave or C component would speed up his application 100-fold. Alas, try convincing a project manager that you need to invest a few weeks optimizing without producing any new features. He'll be stuck tuning that app and trying to squeeze performance out of Memcache until he burns out.

As long as your application domain is very close to what the framework was built for, yes. That's why I made the exception for slapping together quick, form-based, database apps.

For other cases, you're trying to make a design that works well for one case fit another. Better to invest the time learning to apply more general tools that you can adapt to your problem.

... unless you're in the business of throwing together form-based database apps quickly.

That's really all they do well, and there area lot of form-based database applications in the real world, so that's not a small niche.

But for anything that's a little different, you end up spending a lot of time learning the framework, and then even more time working around its limitations. The better approach is to look at your problem and find a set of libraries that are well suited to the task at hand, well documented, well supported, and modular.

Also, take the time to learn your tools properly and exploit them to the fullest. Learning a framework takes time. So does learning about Apache modules and SQL stored procedures. The difference is that the time invested in the framework isn't generally applicable to other problem domains, while Apache and SQL are everywhere, and are worth learning well.

The global menu is the problem for a significant number of people.

I could learn to live with just about every other Unity change, but the global menu drives me bonkers. When my visual focus is on an app window on my second display, I expect to be able to go to that window in order to work with the app. I don't expect to have to click on the window first, then move my mouse to the other display in order to access a menu that (oddly ) isn't located anywhere near my application window.

I've never understood why Apple sticks with this setup. It made sense with the original Mac, which had a tiny screen and didn't really support multi-tasking. It's a huge usability problem for modern desktops with multiple, large displays.

This is the crux of the issue. My understanding (and I guess also Google's understanding) of copyright law is that the copyright is only for the "creative" element of the work, and explicitly excludes things required for interoperability.

So if you take out all the comments, organize the remaining header in a completely non-creative way (ie. sorted by subject area, and then alphabetically), and remove any lingering "private" parts that aren't strictly part of the API, what remains should not be subject to copyright.

It may be true that this has never been tested in court, so I don't know were I got the idea that this is how things worked, but if I'm wrong then I've been under this delusion for at least ten years or so.

I'm sorry you don't trust your government, but it's just a fact that they're the only organization that can verify your identity. A private third party (like Verisign or some hypothetical non-profit) will rely on government ID to establish your identity as well. Given that these private groups don't add any real value, it's silly to pay them money for something the government can do more efficiently.

If you don't trust your government to perform this service, then you've got bigger problems. If the government wants to impersonate you, they can make some fake ID, get credit cards, SSL certificates, etc. in your name, and even arrange it so that your real identity looks like the fake one.

And to be honest, I think even in the U.S., your government is more trustworthy than the likes of Verisign.

These are oganizations that we already deal with and are in the business of establishing our identities and securing transactions.

When you're paying money on-line, you (or your browser) should sign the payment authorization using your own bank account's private key (provided for free with your account) and the encrypted with the public key for the destination account. The recipient will submit the signed authorization to his bank for payment.

For SSL protection of your web site, the government should issue SSL certificates as a free option whenever they are confirming your identity anyway. For people the obvious touch-points are when you get a social security card, driver's license, passport, or birth certificate. For companies, the certificate should be part of your company registration.

Yup, this is happening.

I live in Finland and have friends/contacts/etc. who are involved in MeeGo both professionally and as a hobby.

Shortly after the Microsoft announcement, Intel spread the work among Nokia MeeGo people, and held a huge recruiting event. In the meantime, third-party subcontractors who were doing a lot of MeeGo work for Nokia are now getting contracts from Intel.

It makes sense, if you think about it. Intel desparately needs to make inroads into the mobile market. MeeGo was a part of that strategy, and suddenly it was undercut by Nokia. Hiring a few hundred developers to keep that strategy alive is peanuts for a company the size of Intel, and well worth the investment.

I don't have a strong opinion on the one/two-party law issue, but it doesn't appear to be much of a factor in this case anyway.

The ACLU pdf says that, even in Maryland, you only need permission if there is an expectation of privacy, and the Attorney General gave a legal opinion previously that people who are passing an arrest that is being recorded by the police don't have an expectation of privacy.

If an uninvolved passerby doesn't have an expectation of privacy, then it's hard to imagine how somebody directly involved in the incident has an expectation of privacy.

I seriously doubt anybody will get more than a slap on the wrist.

This is a problem pretty much everywhere. When law enforcement does nasty stuff they're rarely punished. If a private citizen pulled a gun on a motorist, then broke into his home, kidnapped him for 26 hours, and stole this computers, there would be serious prison time, but when cops do this there are no real consequences.

I think that it would probably help the majority of decent, competent cops to do their jobs if the bad ones (and their superiors) were fired and punished when they pulled this sort of crap, but whenever anybody calls for bad cops to be held accountable, police unions raise a stink.

Telling somebody what they've done to violate terms-of-service shouldn't be a problem. You don't need to give away how you caught them, just what it is you think they did wrong. Surely a one-liner along the lines of "we believe you're using your Groups account for spam" should be ok, it would make the whole experience a lot less Kafkaesque.

I'm not sure if you're following this (as I'm slow to respond - different time zone and not online all day)... but...

Hmm. Can you point out the "constitutional preference for free markets" in the actual constitution? Actually, doesn't really matter. The consensus around the world is a preference for free markets, so that's not really unique to the U.S.

But most people (including most people in the U.S., as near as I can tell) acknowledge that free markets have limitations. In this case, the key elements for a well functioning market that are missing are competition and an informed consumer. People are simply very poor at judging risk, so they don't know what insurance is really worth to them. They also don't understand the legalese of insurance contracts, so they might not be purchasing what they think they are. A competitive market in insurance is difficult to maintain because economies of scale are so important in the insurance industry - the more customers you have, the better you can spread risk. So you can open up markets to interstate competition (not a bad idea as long as it's properly regulated), but that will just end up with consolidation - the insurance companies will just buy each other up until there are only two or three left.

I fail to see how any of the measures in the U.S. health care bill, or for that matter any of the real "socialized" health care systems in the world, affect incentives for R&D. You're making the assertion that the bill goes "WELL beyond just changing the way health care is delivered", but as I understand it, the bill doesn't change how health care is delivered at all. The change is limited to how health care is paid for (consumer-side rather than supply-side).

To make you case convincing you need to demonstrate that somehow the American health INSURANCE industry encourages R&D. The evidence that you brought before, that so much medical R&D happens in the U.S., doesn't really make your case.

I could just as easily argue the opposite. If the 30% or so (from memory - but I can try to find a link if you like) of overhead that goes to the insurance industry in the U.S. were spent on health care, then there would be more money for actual treatment and more of that money could go into research.

Ack. Hard to read your post because it's all one paragraph. But you start with an assertion that's demonstrably false, so it tends to undermine anything else you say that might have merit.

First, the biggest funder of medical research in the U.S. and throughout the world is government. That's not likely to change regardless of how health care is provided.

Second, even the Cato study (which you're probably referring to) found that 40 percent of what they termed "innovations" happened in countries with "socialized medicine". Now I haven't researched the details of the study (though I tend to be very suspicious of anything Cato writes), but I think it's plausible that the U.S. contributes more than its fair share to medical science. I would need evidence aside from Cato, but I wouldn't be all that surprised if it were true.

But even if I were to accept that, it doesn't follow that this is due to the American health care system. There are at least two confounding factors that I can think of right off the top of my head:

1. The market for medical research is global. American companies that do R&D sell their products all over the world. While the U.S. is a huge market, it's still only a fraction of the global market, so there's no reason to believe that Americans paying less for health care would significantly reduce investment in R&D.

2. While Americans do pay more than anybody else for health care, most of that goes into insurance industry overhead. It would be interesting to know how much of the additional money paid by Americans for health care actually goes into research, but it's clearly not a huge amount.

From what I gather following the debate from Europe, Americans seems to be unable to look at this issue realistically. Free markets are good, in general, but they have problems. If you assume that free markets are always the best solution then you're taking an idealogical position when what's really called for is a careful examination of the actual problem at hand.