Exactly. He ignored the spec, made whatever changes seemed okay to him, and produced a non-standards-conforming document. With that kind of "I don't have time to read the spec" attitude you have to wonder how he came to care about international standards at all. It's actually a *good thing* (in the long run) for programs to reject clearly nonconformant documents instead of attempting to render them.
That's not the only way to interpret his point. A more charitable reading would be the following: he's arguing that the standard, because it's based too closely on the legacy representations and algorithms used by Excel, is more complicated than it ought to be.
Of course, if that's what he's doing, then he certainly ought to say so more clearly, and even better, explain how the whole thing could be simplified, or illustrate some other document format that does it better.
I agree with all that, but I think you're missing something very fundamental: the purpose of a document format is to encode what the user did and what it means. This is the reason why the details of binary floating point arithmetic are irrelevant in this context, and their use in the file a flaw: if the user typed "1234.1234" in the document, the user meant 1234.1234, and the file better guarantee me, author of a program that reads it, that I can find out for sure that the user meant 1234.1234. The trivial way to do that, of course, is to store precisely what the user is shown on the screen, because it is the thing that the user manipulates until it looks right to them, i.e., until they judge that the thing that they see in the screen is what they mean.
This doesn't apply just in spreadsheets, of course; it applies everywhere.
The whole problem with putting a return statement in the middle of a function is that when you do so, you actually have to read the code carefully to figure out what the control flow is. Try reading code in a language without return statements: you can figure out the control flow much faster, just from the syntax of the code you're reading. (Lisp variants are pretty good in this regard, as are most functional languages.)
They/can/ be a signal for bad code, but they/can/ make certain types of code much clearer, e.g. iy you have a long list of test cases that you wish to test in turn - exiting any one if it fails.
I guess I wasn't as clear as I could've. If you write a function that's a big if-then-else statement with many clauses, it's ok to have return statements as the consequents of the clauses, even if they're "in the middle" of the function. This code is readable because it's clear what the structure is: it's a sequence of parallel conditional clauses. You can see from a quick look that in any one invocation, only one of the conditions will ever be successful. Also, if all the consequents return from the function call, this is an example of parallel structure, which is something that tends to make both text and code more readable. (Comparing this to the way Lisp does this is instructive; in Lisp, you'd use a single multi-clause conditional expression like COND; from seeing COND in the code, you immediately know that the outer layer of the logic is a multi-clause conditional, and that only one of the clauses will succeed.)
The key point I'm trying to make is more or less your point: the complaints about return "in the middle" of a function is really a complaint about code that doesn't make its flow control evident.
Closely related to using return "in the middle" of a function, another code smell is using a lot of if-then statements where you could have used a single if-then-else statement. If-then-else is good, because it makes it visually clear from just looking at the code that only one consequent will be executed in any call, and therefore, means that to understand the function, you may not need to consider cases where more than one of the blocks of code is executed. To use a bad example, if you have a long if-then-else statement with 8 clauses, the syntax of the language guarantees that only one of the consequents is run each time, for a total of 8 possibilities; if you have the equivalent without the else clauses, there are, in principle, 256 different combinations of consequents that could get called, and the only way you can figure out that 248 of these can never happen is by reading the code carefully.
(define (outer-loop loop-state failure-continuation) ;; The failure-continuation argument is just a function that gets ;; called if the condition that breaks the loop is met. (if (end-condition? loop-state) loop-state ;; The function inner-loop will call us back in tail position. ;; Since tail calls compile down to gotos, this will be the same ;; native code as any low-level loop. (inner-loop loop-state failure-continuation)))
(define (inner-loop loop-state failure-continuation) (cond ((end-condition? loop-state) ;; If we come to the condition that ends the inner loop, we ;; tail-call the outer loop (our "success continuation") (outer-loop loop-state failure-continuation)) ((break-condition? loop-state) ;; If the break condition is met, we just call the failure ;; continuation, which "exits the loop." Since this is a ;; tail-call, again, this compiles down to a goto into the ;; code for failure-continuation (failure-continuation loop-state)) (else ;; If neither condition is met, then we just use tail ;; recursion to loop. (inner-loop (produce-next-state loop-state)))))
If you're still writing C in 2007, I guess you're kind of stuck: the language provides no syntactic abstraction. so hacks like that are ubiquitous.
It's the same in pretty much every mainstream language out there. You've hit one nail in the head when you point out the lack of syntactic abstraction problem. There's a couple of additional lack of abstraction problems, though: you can't use functions as values, which is another way of abstracting looping logic, using higher order functions like map or filter; also, the language doesn't provide high-level flow control, like combinations or such.
I usually program in Scheme, and I suspect that the way I'd do whatever GP is doing is by using explicit continuation-passing style. The functions in question would take as an argument a function that does the thing that's supposed to happen when the condition fails: the "failure continunation." Then you do your looping using tail recursion:
((define (outer-loop loop-state failure-continuation) ;; The failure-continuation argument is just a function that gets ;; called if the condition that breaks the loop is met. (if (end-condition? loop-state) loop-state ;; The function inner-loop will call us back in tail position. ;; Since tail calls compile down to gotos, this will be the same ;; native code as any low-level loop. (inner-loop loop-state failure-continuation)))
(define (inner-loop loop-state failure-continuation) (cond ((end-condition? loop-state) ;; If we come to the condition that ends the inner loop, we ;; tail-call the outer loop (our "success continuation") (outer-loop loop-state failure-continuation)) ((break-condition? loop-state) ;; If the break condition is met, we just call the failure ;; continuation, which "exits the loop." Since this is a ;; tail-call, again, this compiles down to a goto into the ;; code for failure-continuation (failure-continuation loop-state)) (else ;; If neither condition is met, then we just use tail ;; recursion to loop. (inner-loop (produce-next-state loop-state)))))
Yeah, the word "continuation" sounds scary, but this is not using call-with-current-continuation or anything that complicated. All you're doing is using tail call optimization to implement the nested loops and the break with nothing other than conditionals and tail calls.
It drives me crazy the number of coders who still, in 2007, have a bee in their bonnet about goto statements (they're just evil apparently) or return statments in the middle of a function body - often prefering the alternative of umpteen nested if statements indented right off the the screen.
Return statements in the middle of the a function body are usually a good signal of bad code; they make the flow of the code more obscure. However, they usually come hand in hand with a clearer signal: functions that are too long.
Spend a couple of months programming in a language like Scheme, where there is no return statement, and you'll see what I mean; the logic of the code is much more evident.
The price should be driven by the cost of producing, marketing and distributing it, divided by the estimated number of copies that will be sold over the period of time where the seller hopes to achieve the profit that the market is willing to yield them for bearing those costs.
I'm sorry, but that's not how the market works. You sell your wares at whatever price results in the greatest profit, regardless of how much it cost to develop them.
You forgot the part where competition between sellers means that the product will sell at the lowest price for which the sellers can make a profit (if they make a profit at all), how that price will be determined by production costs and elasticity of the demand for the product. My formulation is not mistaken, because the whole point of markets is to allocate the economy's resources efficiently, which means that a market should enforce a cap on how much profit a seller can make, based on the cost of producing the goods, and their value to the market.
Or in shorter terms: the greatest profit that a producer can obtain is set by the buyers, and I said that in the post you criticize ("the profit that the market is willing to yield them for bearing those costs"; emphasis added).
IIRC, Google has a policy of not using metadata to rank search results, because (a) it's easy to abuse, (b) it's easy to use incorrectly or inconsistently in ways that are unhelpful, and more importantly, (c) it's not information that's visible to the users of the page, and therefore, it tends to be irrelevant to whether the users will find the page useful.
Your ad-hoc rule sounds useful in a "gee, wiz" kind of way, but you don't know if it actually helps at all, or whether it actually harms in some situations.
The point of the model is pretty simple. It consists of pretending that the supply of copies of digital music files is actually limited, and then pricing the copies based on the variable demand for them.
The problem with the model is that the premise is false. The price of a copy of a digital music file shouldn't be driven by demand, because the demand is limitless. The price should be driven by the cost of producing, marketing and distributing it, divided by the estimated number of copies that will be sold over the period of time where the seller hopes to achieve the profit that the market is willing to yield them for bearing those costs.
It does follow from this that music that's expected to sell more copies, everything else being equal, should sell for less, because there will be more people to buy it over a shorter term. Also, music whose sales has already recouped its initial production costs should sell for less.
These two consequences do hold to some degree in the CD market. Go to a record store, and you'll see that the music of very highly popular artists often sells for a few dollars less than obscure artists, that reissues of old classic albums are often much cheaper than recent albums (look for stickers like "The Nice Price" on CDs), and that best-of compilations of popular older artists and styles are also cheap.
Put the money that you pay as insurance into something like property or in stock in some fast growing market and you may infact have more money to deal with medical emergencies than what your insurance company would pay out.
You're making a big financial mistake there: you're thinking about investments in terms of uncertain future returns, without accounting for risk. Whatever return you receive for those investments, if they don't fail, is nothing more and nothing less than the payment you receive for bearing the risk that they will fail. Insurance works the other way around: when you take out an insurance policy, you pay another party so that they will bear some risk that would otherwise be yours.
What you propose is to increase the amount of risk you bear, by bearing your healthcare expenditure risks and the oversized risks of an emerging market. This is the opposite of what insurance is supposed to do for you.
You're also forgetting some basic financial and investment advice: the reason you keep a liquid emergency fund, and buy insurance to cover your personal risks, is so that you don't have to pull money from your investments in the case of a personal disaster. I.e., you pay out money to neutralize risks that don't pay, so as to guarantee continuity of exposure to the risks that do pay.
Seems reasonable... we charge people with poor driving records more for auto insurance. People who live in flood plains pay more for home insurance. Why shouldn't people at higher risk of health problems pay more for health insurance?
Two reasons:
Because we judge that people have control over how they drive or where they live, but not over whether they get multiple sclerosis.
Because health insurance that cover only the healthy is useless for both the healthy and the unhealthy. It is only useful for the insurance company, who gets to keep all the money that subscribers pay in, without having to pay out anything. This means that unless some mechanism is put into place for forcing people to subscribe (e.g., companies making it a requirement of employment), nobody would buy into it.
Charging drivers with more accidents higher rates for auto insurance?
That's risk-based pricing, as applied to insurance. Now, the argument is that risk-based insurance prices are appropriate for some things, but not for others. For things over which the insured has control, there isn't really much of an objection: you can choose to drive more carefully, you can choose to buy a safer car, etc. (It's nowhere near black and white, though: being a male between ages 16 and 25 is not something you choose.)
On the other hand, risk-based pricing becomes very unfair when people are penalized for things that they have no control over. Plenty of medical conditions are things that people cannot reasonably be expected to be able to opt out of, like congenital diseases. (Though again, there are exceptions and gray areas: it is arguably fair to charge smokers more for health insurance.)
So the point you're attempting to make is that we should treat women DIFFERENTLY in the work place by automatically trusting and respecting their skills in a way that we would not do for a fellow male coworker, because she MIGHT be the target of some form of possible harassment?
What I find amusing or ridiculous--take your pick--is that many women's groups think women should make as much as men even if they have a family, don't work or work part-time. This is nothing but a sense of entitlement. And if women are single and working full time in the cities, then decide to have a family and move to small towns and work part-time or not at all, of course their wages will go down. That is called a trade-off, not necessarily discrimination.
You forgot the key assumptions to this argument: that childrearing is a task that should rest primarily on the shoulders of women, as uncompensated labor. What the women's groups in question that you criticize really think is that the burden of bringing up children should be born by men and women equally.
Then hire three uberdevelopers instead of 10 mediocre developers.
Then your three guys go out for lunch in the same car one day, and they get hit by a bus.
You're missing the point. GP proposed a reductio of the claim that an überdeveloper is really 10 times as productive as a mediocre developer, based on the logic that if this were really so, they would command 10 times as much pay. However, there are sound reasons why the productivity might be 10x, but the pay less than that--higher risks inherent in hiring fewer people, and imperfect information about how good developers actually are.
No matter how you do the math, as you add more developers with no unique or rare skills, you tend to reduce the risks associated with the loss of any one of them. The real questions here what is the business' capacity and taste for risk, and which staffing decisions meet the desired risk profile. Saying "get 3 good guys instead of 10 mediocre ones" doesn't even begin to address the issue.
There are two different meanings for the word "respect". Women should certainly be respected as in, not treated condescendingly, not being treated as a potential mate more than as a coworker, etc.
But "respect" as in, "I respect his/her coding skills." or "I respect the way he/she can motivate his/her underlings." must be earned, regardless of one's sex.
So, what do you plan to do about the countless times where disrespect that is framed in terms of #2 is really a disguise for #1?
You're talking as if people's motivations and attitudes were transparent. They're not so, not even to themselves.
If there really is such a thing as the über-programmer, who is literally 10 times more efficient than his average [median] colleague, THEN BY ALL MEANS he ought to be paid 10 times as much in salary - maybe even more.
In a market with perfect information, by all means, yes. In a market where buyers don't have perfect information, however, irrational stuff happens.
There's also another potential flaw in your logic: failing to account for risk. If you hire one über-developer to do all your work, you're screwed if a bus hits the guy. Hiring 10 mediocre guys instead diversifies away a number of risks. A riskier asset must sell at a steeper discount of the profit that you hope to make out of it, compared to a safer one. (None of this is to imply that the IT jobs market is pricing risks correctly, however.)
As a generalist programmer, originally trained in cognitive science, who has formerly worked in several disparate industries, was a systems administrator, programs in half a dozen languages (including perl), etc, etc...Apparently I'm supposed to be making twice my salary. Goddamnit!
See The Market for Lemons. The existence of tons of bad programmers, and the inability of employers to tell them apart from good ones, drives the salaries of all programmers towards that of the average programmer.
Collective nouns in English trigger agreement either in singular in plural, and the rate at which they trigger the latter is greater in the UK than in the USA, though it still happens in the USA. The choice of agreement actually corresponds to a very subtle semantic distinction: the collective noun can be interpreted as a reference to a single entity (the group), or as a reference to the aggregate of its members. This semantic distinction hardly ever matters, but there are examples where it does: you can say The committee were pleased, because the members of the committee were pleased, but you can't say The committee were formed, because what was formed was the committee itself, not its members.
Same thing happens with constructions like a group of people or a dozen of books, to different degrees.
Since ATMs are opaque and you cannot see the contents of the money bins until you have taken money out, you have to do the "crime" before you can know that the ATM is misconfigured. Thus you are already a criminal.
Incorrect. Simply using an ATM and getting extra money out of it isn't the crime. The crime is realizing that you were given extra money and keeping it anyways.
You're missing GP's point. There's a reason there are square quotes around "crime" the first time around in that quote; it's a reductio argument, in favor of precisely the conclusion you're "correcting" GP towards.
You've also missed GP's bigger point:
But going back for seconds, after having noticed the mistake... now you're talking criminal intent.
Now I bet you that is the real issue here behind the possibility of prosecution. If you knowingly, with premeditation and planning, withdraw money from an ATM that's dispensing too much money, well, that's clearly theft, and the cops sure better try to see if they can catch and prosecute.
And TFA certainly suggests this is what's happened:
Annette Parker, a supervisor at Eagle's Truck Stop, said she unplugged the machine after overhearing conversations about the excess payments.
"The next morning when we had come back in, someone had plugged it back up," she said.
Morris said someone who did not work at the truck stop may have rigged the machine, which keeps records of when the money was taken and by who.
Morris said charges could be brought against the people who got more money than they were debited for.
So, the suspicion is that somebody went out of their way to go to that ATM acting on the knowledge that it was handing out excess money, with the intent to take advantage of this fact; and that somebody may have rigged the machine, too.
The people who used this ATM during the time in question will be checked out. The cops's first priority will be to find the ones that carried out a relatively clear theft as described above. Threats of prosecution may be made towards some who didn't, in order to get them to spill the beans about telling their pals to come take advantage of the ATM. Most of the people who used the ATM will probably not be worth prosecuting for anything more than a misdemeanor, if at all.
And after 50 years of trying to make computers understand language, we can say for sure that a baby isn't going to learn language in three years unless there is some degree of "hard-wiring" in the brain to give them a head start.
But you're missing the point of the debate in linguistics, which isn't whether humans have "hard-wiring," but rather, whether any of it is "specific" to language.
Even more cool: children can learn to speak grammatical language (Creoles) even when they have parents who don't speak grammatically, and structurally Creoles all have the *same* grammar.
That's just false on about every count. There are no good reasons to believe any of the following, given what we know:
That creoles develop in a single generation, and therefore, that there is every such a generation of children as your comment requires. (The idea that creoles develop in a single generation is a central component of Derek Bickerton's model of creole genesis, which he argued about on the basis of Hawaiian Pidgin English; however, recent studies of the history of its development simply don't support it.)
That parents of the putative first creole-speaking generation "don't speak grammatically." For all we know, these parents are native speakers of some language, and their children (i.e., the putative "first generation" creole speakers) know some of their parents' language to some extent. For all the talk about how the slaves in plantation colonies were brought from many different places and spoke many different languages, some of these language families had to have been reasonably represented. The survival of many very specific elements of indigenous African cutures in the New World is an example that.
That all creoles structurally have "the same grammar." No. Hell no.
Closely related to the previous two points: that creole grammars, because they follow universal patterns, do not have significant substrate influence. There's plenty of research documenting precisely such influences.
That the term "creole" really does pick out a well-defined set of languages.
It's a joke about a logician, not about a linguist.
A logic professor is giving his lecture, and at one point, he tells his students: "Always remember, two negatives always make a positive, but two positives never make a negative."
So the guy in the back of the room goes: "Yeah, yeah."
The professor, enraged, asks him: "Young man, are you contradicting me?"
IAAL (I am a linguist), and I believe you are correct. Language is a colligation of sound and meaning, but this technology merely distinguishes sounds: it is a vastly simplified model, not of how children acquire language, but of how children pick up phones. The phone is the most basic unit of the physical (sound) aspect of language, so if this technology is to have any use at all, it has a very long way to go.
IAAL, and although not a child language specialist, I will say one thing: children make plenty of meaningless sound before the start making sense, and more interestingly, they become able to tell their future native language apart from other languages quicker than they become able to understand it. (And I'll even be as daring to suggest that it simply has to be this way; you need to be able to tell signal from noise before you can decode a signal.)
I also think that by calling this a "technology," you're fundamentally misunderstanding it. It's a computer program being used as a test of a model of phonological learning.
How about this: as soon as their program can distinguish allophones, I will be impressed.
I think you've got it exactly backwards here. The whole point this is demonstrate a model that loses the ability to tell allophones apart. I.e., that makes the jump from perceiving a speech stream as a continuous sequence of sounds laid out on a continuous acoustic space, to perceiving it as a sequence of discretely distinct segments.
Of course, a major disclaimer: I haven't seen the actual research, so I don't know to what extent they've met these goals.
Slashdot Mirror
That's not the only way to interpret his point. A more charitable reading would be the following: he's arguing that the standard, because it's based too closely on the legacy representations and algorithms used by Excel, is more complicated than it ought to be.
Of course, if that's what he's doing, then he certainly ought to say so more clearly, and even better, explain how the whole thing could be simplified, or illustrate some other document format that does it better.
I agree with all that, but I think you're missing something very fundamental: the purpose of a document format is to encode what the user did and what it means. This is the reason why the details of binary floating point arithmetic are irrelevant in this context, and their use in the file a flaw: if the user typed "1234.1234" in the document, the user meant 1234.1234, and the file better guarantee me, author of a program that reads it, that I can find out for sure that the user meant 1234.1234. The trivial way to do that, of course, is to store precisely what the user is shown on the screen, because it is the thing that the user manipulates until it looks right to them, i.e., until they judge that the thing that they see in the screen is what they mean.
This doesn't apply just in spreadsheets, of course; it applies everywhere.
The whole problem with putting a return statement in the middle of a function is that when you do so, you actually have to read the code carefully to figure out what the control flow is. Try reading code in a language without return statements: you can figure out the control flow much faster, just from the syntax of the code you're reading. (Lisp variants are pretty good in this regard, as are most functional languages.)
I guess I wasn't as clear as I could've. If you write a function that's a big if-then-else statement with many clauses, it's ok to have return statements as the consequents of the clauses, even if they're "in the middle" of the function. This code is readable because it's clear what the structure is: it's a sequence of parallel conditional clauses. You can see from a quick look that in any one invocation, only one of the conditions will ever be successful. Also, if all the consequents return from the function call, this is an example of parallel structure, which is something that tends to make both text and code more readable. (Comparing this to the way Lisp does this is instructive; in Lisp, you'd use a single multi-clause conditional expression like COND; from seeing COND in the code, you immediately know that the outer layer of the logic is a multi-clause conditional, and that only one of the clauses will succeed.)
The key point I'm trying to make is more or less your point: the complaints about return "in the middle" of a function is really a complaint about code that doesn't make its flow control evident.
Closely related to using return "in the middle" of a function, another code smell is using a lot of if-then statements where you could have used a single if-then-else statement. If-then-else is good, because it makes it visually clear from just looking at the code that only one consequent will be executed in any call, and therefore, means that to understand the function, you may not need to consider cases where more than one of the blocks of code is executed. To use a bad example, if you have a long if-then-else statement with 8 clauses, the syntax of the language guarantees that only one of the consequents is run each time, for a total of 8 possibilities; if you have the equivalent without the else clauses, there are, in principle, 256 different combinations of consequents that could get called, and the only way you can figure out that 248 of these can never happen is by reading the code carefully.
(define (outer-loop loop-state failure-continuation)
;; The failure-continuation argument is just a function that gets
;; called if the condition that breaks the loop is met.
;; The function inner-loop will call us back in tail position.
;; Since tail calls compile down to gotos, this will be the same
;; native code as any low-level loop.
(if (end-condition? loop-state)
loop-state
(inner-loop loop-state failure-continuation)))
(define (inner-loop loop-state failure-continuation)
(cond ((end-condition? loop-state)
;; If we come to the condition that ends the inner loop, we
;; tail-call the outer loop (our "success continuation")
(outer-loop loop-state failure-continuation))
((break-condition? loop-state)
;; If the break condition is met, we just call the failure
;; continuation, which "exits the loop." Since this is a
;; tail-call, again, this compiles down to a goto into the
;; code for failure-continuation
(failure-continuation loop-state))
(else
;; If neither condition is met, then we just use tail
;; recursion to loop.
(inner-loop (produce-next-state loop-state)))))
It's the same in pretty much every mainstream language out there. You've hit one nail in the head when you point out the lack of syntactic abstraction problem. There's a couple of additional lack of abstraction problems, though: you can't use functions as values, which is another way of abstracting looping logic, using higher order functions like map or filter; also, the language doesn't provide high-level flow control, like combinations or such.
I usually program in Scheme, and I suspect that the way I'd do whatever GP is doing is by using explicit continuation-passing style. The functions in question would take as an argument a function that does the thing that's supposed to happen when the condition fails: the "failure continunation." Then you do your looping using tail recursion:
Yeah, the word "continuation" sounds scary, but this is not using call-with-current-continuation or anything that complicated. All you're doing is using tail call optimization to implement the nested loops and the break with nothing other than conditionals and tail calls.
Return statements in the middle of the a function body are usually a good signal of bad code; they make the flow of the code more obscure. However, they usually come hand in hand with a clearer signal: functions that are too long.
Spend a couple of months programming in a language like Scheme, where there is no return statement, and you'll see what I mean; the logic of the code is much more evident.
You forgot the part where competition between sellers means that the product will sell at the lowest price for which the sellers can make a profit (if they make a profit at all), how that price will be determined by production costs and elasticity of the demand for the product. My formulation is not mistaken, because the whole point of markets is to allocate the economy's resources efficiently, which means that a market should enforce a cap on how much profit a seller can make, based on the cost of producing the goods, and their value to the market.
Or in shorter terms: the greatest profit that a producer can obtain is set by the buyers, and I said that in the post you criticize ("the profit that the market is willing to yield them for bearing those costs"; emphasis added).
IIRC, Google has a policy of not using metadata to rank search results, because (a) it's easy to abuse, (b) it's easy to use incorrectly or inconsistently in ways that are unhelpful, and more importantly, (c) it's not information that's visible to the users of the page, and therefore, it tends to be irrelevant to whether the users will find the page useful.
Your ad-hoc rule sounds useful in a "gee, wiz" kind of way, but you don't know if it actually helps at all, or whether it actually harms in some situations.
The point of the model is pretty simple. It consists of pretending that the supply of copies of digital music files is actually limited, and then pricing the copies based on the variable demand for them.
The problem with the model is that the premise is false. The price of a copy of a digital music file shouldn't be driven by demand, because the demand is limitless. The price should be driven by the cost of producing, marketing and distributing it, divided by the estimated number of copies that will be sold over the period of time where the seller hopes to achieve the profit that the market is willing to yield them for bearing those costs.
It does follow from this that music that's expected to sell more copies, everything else being equal, should sell for less, because there will be more people to buy it over a shorter term. Also, music whose sales has already recouped its initial production costs should sell for less.
These two consequences do hold to some degree in the CD market. Go to a record store, and you'll see that the music of very highly popular artists often sells for a few dollars less than obscure artists, that reissues of old classic albums are often much cheaper than recent albums (look for stickers like "The Nice Price" on CDs), and that best-of compilations of popular older artists and styles are also cheap.
You're making a big financial mistake there: you're thinking about investments in terms of uncertain future returns, without accounting for risk. Whatever return you receive for those investments, if they don't fail, is nothing more and nothing less than the payment you receive for bearing the risk that they will fail. Insurance works the other way around: when you take out an insurance policy, you pay another party so that they will bear some risk that would otherwise be yours.
What you propose is to increase the amount of risk you bear, by bearing your healthcare expenditure risks and the oversized risks of an emerging market. This is the opposite of what insurance is supposed to do for you.
You're also forgetting some basic financial and investment advice: the reason you keep a liquid emergency fund, and buy insurance to cover your personal risks, is so that you don't have to pull money from your investments in the case of a personal disaster. I.e., you pay out money to neutralize risks that don't pay, so as to guarantee continuity of exposure to the risks that do pay.
Two reasons:
That's risk-based pricing, as applied to insurance. Now, the argument is that risk-based insurance prices are appropriate for some things, but not for others. For things over which the insured has control, there isn't really much of an objection: you can choose to drive more carefully, you can choose to buy a safer car, etc. (It's nowhere near black and white, though: being a male between ages 16 and 25 is not something you choose.)
On the other hand, risk-based pricing becomes very unfair when people are penalized for things that they have no control over. Plenty of medical conditions are things that people cannot reasonably be expected to be able to opt out of, like congenital diseases. (Though again, there are exceptions and gray areas: it is arguably fair to charge smokers more for health insurance.)
Hmm, great question. Lemme re-read my comment.
*re-reads*
Ah, ok, I can answer now: no.
You forgot the key assumptions to this argument: that childrearing is a task that should rest primarily on the shoulders of women, as uncompensated labor. What the women's groups in question that you criticize really think is that the burden of bringing up children should be born by men and women equally.
Then your three guys go out for lunch in the same car one day, and they get hit by a bus.
You're missing the point. GP proposed a reductio of the claim that an überdeveloper is really 10 times as productive as a mediocre developer, based on the logic that if this were really so, they would command 10 times as much pay. However, there are sound reasons why the productivity might be 10x, but the pay less than that--higher risks inherent in hiring fewer people, and imperfect information about how good developers actually are.
No matter how you do the math, as you add more developers with no unique or rare skills, you tend to reduce the risks associated with the loss of any one of them. The real questions here what is the business' capacity and taste for risk, and which staffing decisions meet the desired risk profile. Saying "get 3 good guys instead of 10 mediocre ones" doesn't even begin to address the issue.
So, what do you plan to do about the countless times where disrespect that is framed in terms of #2 is really a disguise for #1?
You're talking as if people's motivations and attitudes were transparent. They're not so, not even to themselves.
In a market with perfect information, by all means, yes. In a market where buyers don't have perfect information, however, irrational stuff happens.
There's also another potential flaw in your logic: failing to account for risk. If you hire one über-developer to do all your work, you're screwed if a bus hits the guy. Hiring 10 mediocre guys instead diversifies away a number of risks. A riskier asset must sell at a steeper discount of the profit that you hope to make out of it, compared to a safer one. (None of this is to imply that the IT jobs market is pricing risks correctly, however.)
See The Market for Lemons. The existence of tons of bad programmers, and the inability of employers to tell them apart from good ones, drives the salaries of all programmers towards that of the average programmer.
Collective nouns in English trigger agreement either in singular in plural, and the rate at which they trigger the latter is greater in the UK than in the USA, though it still happens in the USA. The choice of agreement actually corresponds to a very subtle semantic distinction: the collective noun can be interpreted as a reference to a single entity (the group), or as a reference to the aggregate of its members. This semantic distinction hardly ever matters, but there are examples where it does: you can say The committee were pleased, because the members of the committee were pleased, but you can't say The committee were formed, because what was formed was the committee itself, not its members.
Same thing happens with constructions like a group of people or a dozen of books, to different degrees.
You're missing GP's point. There's a reason there are square quotes around "crime" the first time around in that quote; it's a reductio argument, in favor of precisely the conclusion you're "correcting" GP towards.
You've also missed GP's bigger point:
Now I bet you that is the real issue here behind the possibility of prosecution. If you knowingly, with premeditation and planning, withdraw money from an ATM that's dispensing too much money, well, that's clearly theft, and the cops sure better try to see if they can catch and prosecute.
And TFA certainly suggests this is what's happened:
So, the suspicion is that somebody went out of their way to go to that ATM acting on the knowledge that it was handing out excess money, with the intent to take advantage of this fact; and that somebody may have rigged the machine, too.
The people who used this ATM during the time in question will be checked out. The cops's first priority will be to find the ones that carried out a relatively clear theft as described above. Threats of prosecution may be made towards some who didn't, in order to get them to spill the beans about telling their pals to come take advantage of the ATM. Most of the people who used the ATM will probably not be worth prosecuting for anything more than a misdemeanor, if at all.
But you're missing the point of the debate in linguistics, which isn't whether humans have "hard-wiring," but rather, whether any of it is "specific" to language.
That's just false on about every count. There are no good reasons to believe any of the following, given what we know:
It's a joke about a logician, not about a linguist.
A logic professor is giving his lecture, and at one point, he tells his students: "Always remember, two negatives always make a positive, but two positives never make a negative."
So the guy in the back of the room goes: "Yeah, yeah."
The professor, enraged, asks him: "Young man, are you contradicting me?"
To which the guy responds: "No, no!"
IAAL, and although not a child language specialist, I will say one thing: children make plenty of meaningless sound before the start making sense, and more interestingly, they become able to tell their future native language apart from other languages quicker than they become able to understand it. (And I'll even be as daring to suggest that it simply has to be this way; you need to be able to tell signal from noise before you can decode a signal.)
I also think that by calling this a "technology," you're fundamentally misunderstanding it. It's a computer program being used as a test of a model of phonological learning.
I think you've got it exactly backwards here. The whole point this is demonstrate a model that loses the ability to tell allophones apart. I.e., that makes the jump from perceiving a speech stream as a continuous sequence of sounds laid out on a continuous acoustic space, to perceiving it as a sequence of discretely distinct segments.
Of course, a major disclaimer: I haven't seen the actual research, so I don't know to what extent they've met these goals.