Exactly.

If you're browser-side JS developer (as opposed to something server-side like Node.JS) and you haven't worked with JQuery, then you're not really a browser-side JS developer. It's just far too widely used to pretend that it doesn't or shouldn't exist. And most of the consistency across other frameworks (like using the $ shortcut or css selectors to target elements in the DOM) comes from the popularity of JQuery to begin with.

You answered your own question:

The latter of these two was not actually permitted to be demanded by the driver, but it was still a general practice among club members

If you volunteer to give your carpool driver $10 to help with gas - it's fine.

If your driver asks for $10 to cover gas - it runs afoul of the livery laws. It's hard to enforce, but that's generally how the law is written (at least in the US).

Cabs predate the automobile by a long shot.

Even cities with incredibly good public transportation options still have cabs because there is a natural market for being able to travel *directly* from point A to point B in a more expedient manner than public transportation could ever provide.

This is a little like saying it would be handy if the compiler knew what you meant when you wrote code that attemtped to do soemthing for which there is no specifically well defined answer.

If the compiler or language has a consistent, documented behavior for the scenario, then by definition there is a specifically well-defined answer.

For certain knowledge domains and programming patterns, this would not be a hurdle but a benefit. Languages are full of these behavioral "flavors".

According to another poster elsewhere, some processors do exactly what the OP requested, and that it's doable today in machine code. Other posters have mentioned that using unsigned or floating point integer types allow this behavior in various languages.

There's no reason why it couldn't be supported by a language, and it's absolutely not impossible.

Everyone's argument about it being impossible comes from expressing things in languages where it's explicitly "undefined" or NaN, or otherwise illegal in that language. If it's a standard and predictable behavioral rule of a language, then it's definitely usable in that language.

Weak types in PHP or JS are very analogous. Sure, lots of people make mistakes with them (and there's other faults that encourage those mistakes), and most problems stem from inconsistencies in the language APIs when converting types, but if you understand how types work in those two languages you can write surprisingly complex behaviors using very simple and concise expressions. Simplicity and terseness is very important in a scripted language.

What's good for a particular algorithm buried in the code base is not necessarily good for user input which may be used a hundred other ways.

0 could be a perfectly valid user input or calculated result of multiple user inputs that could cause the algorithm to choke.

Prefixing every math operation you put in your code base with a check for 0 if the input values are unknown can be tedious, especially in obtuse languages/platforms that don't support good modularity - hence the OPs question about a globally consistent behavior.

Because in some languages and programming formats (especially ones where this kind of problem would come up frequently) it's painful to do validation checks before every mathematical operation. Jamming crap into Excel formulas comes to mind (thank God I don't have to do any real work there).

I could totally understand the desire of a language that featured this or had it as a flavor setting. I think it could allow for some interesting logical expressions and verbosity reduction if it was understood to operate in a consistent manner.

Oh so you want to use this language: http://xkcd.com/1537/

Unless of course 0 is a valid entry for the external input.

Or if two external inputs negate each other somewhere in the process.

$10 in credits, $10 in charges, net $0, what's the daily interest charge on that? Oh right, now I need to add a conditional before I do the calculation, lather, rinse, repeat all over your business logic tier.

When two different fields in different areas of your app accept 0 as a valid entry for legitimate use, its pretty dam easy to run into a divide by 0 condition or even a 0/0 condition.

The point of the original post is that it could be pretty handy to have a sane predicable default result instead getting a runtime error or having to introduce conditional logic every single time you do divide by a variable or calculated value..

Amen.

On every flight that I've been on in the last couple of years where the first checked bag was free, there has been ample overhead storage space, sometimes entirely empty bins on planes with filled seats!

And the reverse has been true. The airlines that charge for the bag (*ahem* American Airlines) have consistently had departure delays as the flight attendants spend everyone's time to convince the last few people to check their bags because the've squeezed every possible bit of room out of the overhead bins already.

Since Java isn't terribly popular in Linux, .NET has no chance.

Huh????? Most public facing Java service or site I've worked with as a developer have been running on a Linux box, normally RHEL or CentOS. Sometimes I've run into NetBSD, and occasionally HP-UX or Solaris.

I cannot fathom how you equate a (non-real) lack of Java development on Linux as a reason why .NET has no future there.

AT&T knew full well what they were doing was illegal. They couldn't just cut off the plans mid-contract (though they could and did stop offering new contracts) without giving customers the ability to break contract without penalty. Which is why they kept calling them "Unlimited" plans as they started implementing limits.

As a customer who has personally been affected by this shady practice, I like that the Government is stepping in and regulating what is clearly false advertising and deceptive business practices on the part of AT&T.

AT&T took very intentional steps here to degrade what customers were promised, with the intent to switch them over to higher-priced service plans. It also was done in a way to prevent customers escaping via escape clauses when contract terms changes.

As a customer, what are my options to avoid being screwed by a unsolicited unilateral material change to the service agreement I signed? I could buckle and pay more. I could stay with what I have and get something different than what I was sold. I could leave AT&T for one of the 3 competitors:
- Sprint, not possible at the time because network technology differences prevented bringing over your existing phone, plus poor coverage in areas I want to use the phone
- Verizon, not possible at the time because network technology differences prevented bringing over your existing phone
- TMobile, not possible since leaving the AT&T contract early leaves you with a locked phone unusable on TMobile's network, plus poor coverage in areas I want to use the phone
- Pay as you go and various 2nd-tier carriers that piggy back on the above. Exact same problems as already mentioned for switching to one of the other 3 major carriers.

When we subsidize industries and regulate them in such a way that no real competition exists, then absolutely it is the role of the Government to also regulate them to protect the customers against abuse of customer contract lock-ins and deceptive business practices.

Imagine if the power company offered you a fixed-rate 2 year contract and then halfway through it said "Switch to our new higher-price plan or we're cutting your line voltage after the first 3KWh of usage".

AT&T is/was intentional bottlenecking the traffic of "unlimited" customers if you hit 3GB in a month. On average AT&T LTE speed, you can hit that monthly chokehold in just over 10 minutes.

10 minutes of full network usage a month, and they call it "unlimited".

While simultaneously they spam you to switch to their convenient 4GB/mo plan with 1GB billing increments beyond that to avoid any speed limits.

There is no possible way that a defined cap can be construed as "unlimited". Whereas "full usage up to network availability" is a pretty reasonable definition that the average layperson would agree with.

No matter how you slice it, it's clearly false advertising and a shady way to try to force customers onto more expensive offerings without discontinuing the existing service contract.