Mandelbug

Sometimes I really wish I had the ability to downvote. But never more have I wanted it until this totally asinine comment.

People like you are the whole reason the US' media is complete shit.

Sounds like an easy default is to keep the profile private until the user chooses to "create" the profile.

Honestly I have never really found a situation where I wanted to exactly (or even slightly) mean reduce by 10%. It is too specific of a definition to be truly useful.

I find it much more convenient, and useful, to have a word that means the current modern definition of decimate. Perhaps decimate is a poor choice to represent that, but honestly not every word has to sound or have roots that directly relate to the definition of the word. It is more important words are used, rather than languish or die in history books.

Interestingly, asking Google to define "decimate" returns a modern definition, "kill, destroy, or remove a large percentage or part of", and a historical one, "kill one in every ten of (a group of soldiers or others) as a punishment for the whole group".

The English language has apparently moved on.

I tried in both FF and Chrome, no issues with performance noticed. Do you have a lot of plugins with FF?

I actually had an opposite problem, the game was incredibly generous with its imprecise collision. I could rotate twice and catch two rectangles falling at the same time on the same paddle and finish a group. I was overwhelmed by the number of sides I had to simultaneously defend and the number of different falling pieces. The animations, I don't think, made much difference in difficulty or ease. Mostly I wound up surprised that I had cleared a group, rather than the opposite problem you described.

Funny we both had very opposite experiences.

IANAL, and yes, you can not copyright game mechanics or ideas. This is why so many clones of every game exists. Because no one owns the rights to "a tower defense".

What? Of course the apparent affect matters. If the underlying physical principles can be understood, there is a possibility of increasing its efficiency for larger throughput. And if the underlying process isn't understood, there is no way to rule out something that isn't actually producing thrust or some other fluke.

Finally, the whole point of science is to discover things. Not make magic :|

In those studies that show removing a lane can improve traffic flow or adding a lane can worsen traffic, that is only true of particular lanes/roads in different areas. In fact, it is more than likely that removing any one lane from any road is more likely to worsen traffic than it is to improve it.

It is entirely dependent on the network patterns of the traffic flow itself, not the roads.

The latter isn't used because it sounds cooler, it is literally rooted in the "kill" command on UNIX systems of old. The kill command is still used today, but can be used to send signals to running applications aside from "please exit immediately".

If you want to get really nitpicky, halt isn't as absolute and precise as kill. Halt can mean that the app's activity is simply paused, but its resources are still held and it can in the future be resumed from its original position. Kill very much and in no uncertain terms means to immediately terminate the execution of an application without further processing of the current task.

They really aren't interchangeable terms. If you are talking about interchangeability to an end-user who doesn't have such knowledge, I would argue even then some users may understand the different between not using an app and actually terminating it. Such as halting a video vs closing the window. If you are looking for analogies of proof of understanding, people say to "kill the engine" or other mechanical devices. So again, the term "kill" used in reference to terminating things isn't that weird.

The individual who was surprised to hear of killing an app could have been surprised for a variety of reasons, but not in such a way that I think "halt" should be used over kill.

Unfortunately, while showing what we would consider "intuitively bad data" may seem like a bad idea, only actually empirically testing it can we measure and quantify the exact impact that bad data (either shown purposefully or accidentally, or unknowingly) will have on users.

It may have in fact turned out that what we intuitively think as bad data results in better matches or better experiences. I think experimenting is worthwhile, so long as it is done in the open as they have been doing.

Have you actually used and looked into AWS? There are dozens of services that do a lot more than just what people generally think of as "the cloud".

I think it is much more likely that businesses are readjusting for the new reality of customer expectations regarding media: cheap, on demand, and cheap. Customers don't care about how much royalties an artistic creator might get, and if they did they wouldn't have supported the music or book publishing industries, which gave authors tiny royalties for each book sold. Customers only care about price. And if piracy and large abundance of media is any indicator, the sheer volume of work being created along with a greater entitled feeling among customers is the primary downwards force for price.

While your frustration is understandable and disappointing, the customers are far more to blame than any one company.

The analogy is ok, but mostly fails because as a developer, we are not paid commission for each line of code written. Whereas taxi drivers have a very strong profit motive to act efficiently and quickly. I think your examples of why they would deviate from this believed behavior is pretty solid on its own.

Regardless of its "technical" or "economic" definition, to the layman and all its users, Bitcoin is treated, traded, and consumed as money.

The exact origins of Bitcoin do not change its utility, which is as a unit of exchange, which is what money is in its most general and flexible definition.

Actually, from your basic set of requirements, you just feature creeped your design to death.

Let me take a shot at it:

Learn enough HTML to make a GET request. Know enough PHP to receive the GET request, and then update a textfile of entries on disk. Use a second file to store the top ten clicks. Return the second text file.

Thats it. In your example, you did what is generally expected of today's current "web trends": you take a super simple use case, and demand it be highly scalable for millions of users with instant and immediate feedback. And why are we using CSS at all? Its a button and some text, no styling is needed. And why are we using a database? Do you expect millions of concurrent users? Hundreds? Your requirements didn't say that. What do you mean package/deploy/whatever to the server? Sure, there are some basic routing needs and maybe Apache, but those take minutes or less to setup. Also, right in the middle of your solution, you changed the requirement "If I want the interface to update immediately...", right there, you are adding complexity.

While at the face of it, I understand what you are trying to say, but I have to point out that you are the primary cause of the increase of complexity, not the technologies involved. I actually think deploying a simple counter website like this is easy. But as soon as you want immediate feedback? Alright, more complexity. Millions of stored records? Alright maybe some large memory cache, like Memcache (or a large array). Persistent records? Alright, fine, get a DB. Millions of concurrent users? Alright, we are going to need some more complexity to handle throttling. Thousands of requests per second? Even more complexity, maybe we have a distributed system.

In the end, you took a simple problem, and turned it into an awfully complex one. Yes, designing an application for that kind of load is complex, because it is actually a complex task. Doing all the things we want to do today is hard because there isn't some turn key solution, not because we are working with tools that are too complex.

As an unfair little poke at your solution, there are in fact turn-key solutions, like Yahoo webhosting, where you just design really high level basics and it does the rest.

Feature creep is bad. Identify it, and kill it.

I would like to point out that all of your examples are of expanding industries, not industries that underwent large societal, cultural, and legal transformations into entirely different industries. Society, culture, and laws are made for expanding industries, they have to be evolved and rewritten for industries of change.

So I am going to have to disagree, 25 years would have to be the most optimistic kind of prediction, assuming that all players are willing and pro-active, rather than passive and resistive (both in society and legally speaking).

The general literature on deflation is that deflation is much much worse in the long run. In particular, borrowing becomes significantly more difficult and those who have loans are trapped with them, as their wages are pushed downwards by deflationary forces but the nominal loan remains the same.

While run-away inflation and run-away deflation are both awful, an economy which slowly inflates is better than one that slowly deflates.

http://www.nytimes.com/2010/10/17/world/asia/17japan.html?pa...

http://www.businessweek.com/magazine/content/11_06/b42140145...

http://www.bis.org/publ/bppdf/bispap70c.pdf

http://www.kyotobank.co.jp/houjin/report/pdf/201305_02_e.pdf

http://www.nber.org/digest/jun05/w10938.html