Ease of use and good user experience are not always synonymous. In most cases they are, but if you're making it easy to do something that can't be easily undone, someone will do that accidentally and then have the frustration of fixing that. For example, I was recently working on allowing some software to interface with a connected scale. One of the things you can do through that interface is tare the scale, but after implementing that I decided that it was too easy to accidentally hit the tare button instead of the weigh button with the consequence that the person using the software would then have to re-tare the scale and re-weigh to get the correct measurement. So I took the tare button out figuring that people would generally rather do that at the scale itself anyway. I'll probably put it back in at some point, but it will be a little harder to hit that accidentally when I do. Your example is too vague to say who is right in your particular case.
And here's another from 2006: http://en.wikipedia.org/wiki/Painstation
Yes and no. The signals and slots mechanism is still there and it's still using moc, but there's a new connection syntax available that's a lot more C++ like, allows C++11 lambdas in place of slots, and offers compile-time checking of connections that previously would just fail at run time. Won't please the purists, but it's a step in the right direction.
The fraud detection heuristics must be very strange. In my case I've never had a problem using a card traveling in foreign countries (and I never tell them I'm going aside from usually having purchased the plane ticket months in advance), no problem buying industrial equipment, but attempting to buy groceries at a place I frequently buy groceries? Yeah, that's suspicious and worth declining the transaction and shutting down the card until I call to have it reactivated. I've never had a true positive detection and wish they'd just give up trying with me and instead let me tell them if something is wrong.
Note that in a lot of cases the caffeine in pain killers come from coffee. Depending on how a coffee is decaffeinated, the caffeine can be removed from the binding agent, sold to pharmaceutical companies, and added to your pain killers. I wouldn't be surprised if that's a common source of caffeine for drinks with caffeine added. Tea, of course, produces its own caffeine as do several other plants.
I'd say keep telling your doctor you don't drink coffee (or take up coffee drinking) but mention the pain killers separately.
What the sales tax pays for probably varies depending on where you are, but one of the things I keep seeing in these sorts of stories are the assumption that it pays for infrastructure used by businesses not paying the tax. Is that really the case? It didn't match with my recollection on the matter so I did a bit of research. Anybody interested in doing similar should be able to find the information in the comprehensive annual financial reports from their state department of revenue.
In Wisconsin, sales tax makes up about 30% of the general purpose revenue for the state (about 18% of total state government revenue). This is used to fund several programs, most notably school aids, shared revenue paid to municipalities, medical assistance programs, the University of Wisconsin system, prisons, property tax credits, community aids, tax relief to individuals, other public assistance, and WI technical college system aids.
Since a big chunk of that is money paid to local governments, I then went to the budget for my city to see where that was going. It's paying for public safety (fire and police department), public works (planning, surveying, mapping, city engineering, emergency management, building inspection, trash removal, snow removal, bridge and street maintenance, weed cutting, street lighting, traffic signs), parks, recreation, and cultural services (several area parks, community centers, a museum, the zoo), and general administration. That public works section is about 16% of the city budget and street maintenance is about 23% of that, or about 3% of the total city budget. Looking at revenue for the city, shared revenue from the state would fall under intergovernmental revenue, making up a portion of 42% of city revenues.
So, while it's certainly possible that some sales tax money ends up funding local roads, the vast majority of that is paid for from a different fund through, for example, fuel taxes. Don't misunderstand me. There's a lot of good stuff that sales tax money goes to, but the suggestion that it's largely going to infrastructure that out of state businesses rely on doesn't seem to be true, at least where I am. YMMV.
I wouldn't hold it up as any kind of example of great code (so there are certainly opportunities to improve it and it is still under active development), but another open source (MIT licensed) literate C++ program you can add to the list is some software I've written for data logging/record keeping in commercial coffee roasting facilities. I've tried to keep the generated source documentation reasonably easy to read and understand and the program is used daily at several coffee firms throughout the world.
It seems as though at least some airports are moving away from these things anyway. (warning, anecdotal evidence coming up) A few weeks ago I flew from Chicago to Houston. When going through security on the way out I didn't so much as see a porn scanner (there was one for the flight out of that airport I had taken before, but I went through a different security line this time). I also kept an eye out when leaving the secure area on the way back and again failed to notice one. Flying out of Houston, the security line split in two and I was free to choose either the long slow line with the porn scanner at the end of it (which was scanning everybody who chose that line) or the short fast line without it. I chose the short fast line, didn't get a groping, and was rather amazed at how many people chose the longer, slower line (I suspect most didn't notice the other line was available).
The sooner we stop wasting money on these things (and better yet, get them out of the airports so we can have room for more fast lines to get through security) the better.
To be fair, it does make a lot of sense to do something like that if you're going to be getting a large number of small dollar amount donations. There are costs associated with processing a donation and it's a lot cheaper for the charity to process a single $2M donation than 1M $2 donations. A retailer collecting that along with a purchase will have most of those costs to make the sale anyway. Doing it this way also provides a way to do that charitable donation as something like an impulse purchase, probably resulting in a lot of people donating who might not have considered doing it otherwise.
Now, I'd also say no because I'm not a huge fan of * awareness charities and the dirty look is bad service, but I fail to see the problem with the rest of it.
A while back I got an email from Nokia letting me know about the Qt Ambassador program. So, I sent them some information on a program that I wrote using Qt and someone there must have thought it was neat since they sent me a very nice gift.
I'm sure that's on the roadmap, right after proper Unicode support.
What I've read on the matter is that the astrologers agree with your assessment. Nobody changed signs. Still sucks for the newborns who will be unable to record a high score in Gradius.
The economic realities of the global coffee market are not as simple as you are making them out to be. Some historical perspective:
There was once a time when coffee was trading at high prices. Demand was increasing, supplies were not increasing as much, and there were countries capable of producing coffees that weren't. Getting people to plant coffee in these non-traditional producing areas was seen as a way to develop economies. This idea was not without precedent. Brazil was largely built on coffee money, after all. Now, it takes a few years from the time coffee is planted until it produces its first crop. Coffee isn't a crop where you plant it, harvest it a few months later, and know what you've got. It takes about 10 years before you really know what you have with coffee. All of the sudden you have a huge increase in global coffee production. Making the problem worse, these new coffee producers were exporting coffees of such poor quality that more established producers never allowed on the global market. Now, coffee does not really fit the definition of a commodity, but it was usually sold with contracts that specify a differential above or below the NYBOT C price with those differentials based on several factors such as the quality of the coffee (coffee better than exchange grade selling for more, worse coffee selling for less) and the producing country (a comparative advantage model doesn't really work because a specialty grade coffee from Panama isn't going to taste anything like a specialty grade coffee from Tanzania).
Up until this point, the NYBOT C was cyclical. Sometimes it would go bust, but it would recover. This time it was different. There had been a fundamental change in the market which kept prices depressed for a long period of time and the differentials weren't keeping up. Simply letting quality producers go out of business wasn't going to be good for the producers and it wasn't going to be good for buyers either because someone who wanted to buy a nice coffee from Mexico wasn't going to be interested in some garbage from Vietnam. By setting a floor price for some coffees, Fair Trade did a lot of good in keeping those producers in business. You might find it interesting to look into the details of some Fair Trade producers and see what they're doing with those premiums. In many cases they're using them to improve the quality of the coffee and diversify the local economy, both things which reduce long term reliance on the Fair Trade premium, which seems to be exactly what you're advocating (though you suggest doing that before getting the capital needed to undertake such projects).
Now we're back into a period of higher prices for coffee (NYBOT C is over 200 as I write this and the differentials aren't dropping quickly which is a big part of why many coffee firms either have or soon will be announcing price increases) and this is due to many factors. Looking at the fundamentals, this is cyclical and prices will drop again, but probably not substantially within the next 18 months. We also have a lot more diversity in price discovery mechanisms for coffee which is a positive development, particularly for producers of high quality coffees. Any Fair Trade cooperative ought to be looking into getting out of Fair Trade in the long term exactly because that's not a long term sustainable model. Some cooperatives have already made that jump, others will follow, but to argue that Fair Trade was not beneficial in the long term simply is not supported by fact.
I only need two keystrokes to get a division sign (option/) so I'm not really sure what you're going on about there. That said, I don't think it matters so much in terms of writing the code. As others have pointed out, we've been down that road with APL. Where this sort of idea really shines, however, is in reading the code. One of the comments on the article touched on this, so I'll quote the relevant bit:
Robert Melton | Mon, 01 Nov 2010 02:11:13 UTC
What an odd combination of criticisms... first and foremost, I think you already hit on the correct solution... custom syntax and creation mechanisms are best explored as layers on top of existing tools, not a fundamental part of a new tool. I believe to try to integrate your ideas would have crippled Go, and given it nearly no advantages, at the cost of a huge degree of developer mind share. Bootstrapping a language is hard enough without giving yourself new disadvantages. I have never seen Guido van Rossum claim anything other the "readability" and that it was the natural flow as foreseen by Knuth (1974)
The problem here, however, is a cultural one. I suspect that most of the people who write software have never read through a non-trivial program and come out of it with an understanding of the program (contrast this with novelists reading novels) and most software is written in such a way that reading the code for understanding is more like assembling a puzzle from diverse bits scattered all about.
We already have pretty much all of these presentation niceties with CWEB. I frequently write my programs in literate C++ and can use goofy characters with subscripts if I want. TeX markup in comments is very nice. Especially useful is having something a bit more visually distinctive separating assignment from equality testing, but the big gain here is that it makes it easier to write programs as code narratives which humans can read to gain an understanding of the program. Once you have someone reading the program, how the code is represented starts to matter. Granted, this is another example from the pile of ideas that never really caught on.