Even more effective than the programmer that avoids writing code by writing efficient code is the programmer that writes code which allows his coworkers to write less code. If you've got someone who's good at this sort of thing, the best use for them is to write the tools that improve everyone's efficiency.
Except that these fees are not new or exceptional to the Droid. The data plan prices cited in the article are what Verizon has been charging for at least a year, for any data-capable phone. I know because I paid exactly that much for the privilege of tethering my phone during a two-week driving vacation last year.
I think that the data plans are too expensive, especially given the caps. I was willing to pay the fees temporarily for access to the very good coverage that Verizon provides. But I've also seen people speculate that AT&T is charging too little, resulting in network congestion.
"... because functional programming is seen as very pure and simple, there is a myth that Scheme programs do not need much documentation."
This sits alongside the myth that Scheme is a functional language, and the one that equates a lack of manifest variable typing with functional programming.
More importantly, the notion that manifest types provide all the documentation that you need to understand returned values or argument requirements is also a myth. For non-trivial code, there's no substitute for informative comments, regardless of language.
It's completely absurd to let phone companies own and control the wires, and yet be allowed to string wires wherever they want with no compenstation to the property owners or the state.
I think that's overstating the reality, or at least oversimplifying. A right of way, although often taken via eminent domain, is often paid for -- to the initial owner who is forced to grant it. After that, the loss of property value is presumably built into the price. (I know that whenever I've considered land for purchase, I have checked carefully -- myself -- for rights-of-way, and taken them into consideration.) Whether compensation is generally fair or not probably varies -- in fact, most of the details probably vary a lot state to state. The utilities do pay for the equipment and its upkeep.
I don't think anyone is or was working towards publically-owned equipment. At least I don't ever remember hearing of any community proposing to pay a company to buy the equipment. What is generally done in the U.S. is to pretend that the utilities are private companies while regulating the use of their assets as if we, the public, owned them. It's a fundamentally screwed up and morally dishonest system that naturally leads to lousy companies and unhappy consumers. One entity representing consumers dictates -- with absolute power -- how to use assets and price product, while another entity, which is trying to make a profit for its shareholders, is responsible for owning, maintaining, and (hopefully) expanding those assets. What a joke. California's electrical system gave a wonderful example of how well this works.
Most of cases of truly publically-owned utilities that hear of -- community-owned electric or phone companies, for instance -- sound like they work out fairly well. However, I haven't heard of any cases where the community owned and operated the pipes and leased them to suppliers. It would be interesting to hear if this has been tried, and how it worked out.
Libertarian capitalism, like communism, looks good on paper but fails utterly in reality.
The problem being that it usually seems to fail due to government interference. It's hard these days in the U.S. to find an industry where the government hasn't interfered significantly via protective legislation or subsidies in various forms. Abroad, it's hard to find a free market economy that wasn't hobbled at inception by a too-rapid transition from a prior system, resulting in a lack of adequate financial and legal infrastructure. Admittedly, legislative stupidity is part of the 'reality' that a market model has to deal with, but at least in this country it's an aspect of reality that we could influence.
There are numerous things wrong with our current telecomm infrastructure in the U.S. It seems to me that there are two long-term directions we could take that would improve it. We could be honest about wanting government control over the pipelines, and pay for them. Perhaps communities could use the recent despised (rightly so, IMO) liberalization of eminent domain laws to buy the pipelines -- poles, wires, associated rights-of-way -- and lease use back to the telecomm companies. (Wouldn't be fun to turn liberalized eminent domain against the large corporations that wanted it?) We would have to be willing to pay the taxes necessary for the purchases and upkeep. This would be much more honest than the current situation.
Alternately, liberalize it, continuing in the current direction. These effective monopolies won't last in the face of improving wireless communications and other technologies. If prices go up, there'll be more incentives and money available to develop alternatives. Prices will eventually come down again.
Neither path should be pursued by sudden changes in the legislative environment, because it's the transitions that cause hardship. But we, as a nation, or at least as individual communities, need to figure out which alternative we prefer and stick to it. The current waffling back and forth is what causes a lot of grief.
I understand the similarity that this has with in-band signalling. But part and parcel of this is that the special values are, by definition, no longer considered "in-band". You have to take steps to treat the special values as special, and not confuse them with "real" data.
It's simple: A type defines a set of possible values. So you define the set of values for a field to include a valid range, plus some special values, and you define how these interact. The fact that the special values are represented in a way that's similar to the other values is a physical consideration, not a logical one.
BTW, what the heck is the "domain of a tuple"?
And NULLs are not values, which is the entire point of the discussion. SQL couldn't properly define operations on it, because it's a lack of something, not a something. If you replace NULL with a special *value*, you'll have exactly what I'm describing.
That's the way that Codd went in second version of the relation model. But it just makes even more of a mess out of what *should* be simple two-state predicate logic. Personally, I'm firmly in the "no NULL" camp. I like it when boolen logic operators do what they're supposed to.
This description of Date's approach to NULLs is incomplete. The far simpler method that he recommends is to set aside a special value to replace NULL. For instance, an empty string is often a good choice to mean "unknown" in a string column. You can also set aside multiple special values to mean different things -- for instance, "N/A" for Not Applicable. This is more flexible than NULLs, and doesn't suffer from multi-valued logic problems, since these special values really are values. I haven't yet seen a case where it was a problem to set aside a few values out of the range of a field type for these purposes.
Choosing the special values carefully can make queries simple, too: Consider how the special values are ordered compared to non-special values. For instance, I've set aside two special date values to represent "infinite past" or "infinite future"; the former is a value that sorts before all valid non-special values, the latter sorts after them. Use the former to mean "we don't have a specific date, but consider this event to have happened already". The latter is used to mean "we don't have a specific date, but consider this event as never having occurred".
This approach is quite practical and gives you a lot of flexibility.
It would be perfectly possible in a relationally complete language that includes a relational MINUS operator, without NULLs entering into it at all. And Tutorial D, on which the object of this article is based, does of course include such an operator.
Whether NULLs are desirable or not is a matter of ongoing raging debate. I've found them easy to avoid, and queries of all sorts easy to understand without them.
The Gnus package in (X)Emacs does this, via the Expire feature. It's not everyone's cup of tea, but if you're an Emacs user, it's nice to be able to read mail and news while having access to the editing environment that you're used to.
Nice review. This book is also one of my all-time favorites. In fact, I just re-read it a few weeks ago, after buying the, umm, fourth copy, I think. (All the others got lent out and never came home.)
To the guy that didn't like Deepness in the Sky: IMO, there's no comparison between the two books. Although I liked that book too, A Fire Upon the Deep was far more engrossing.
I also recommend Vinge's Across Realtime. Interesting stories spun around a neat technology, starting in the near future.
Yikes. I saw this movie when I was in college, at a theater just off campus. It was the only movie I've ever attended where more than half of the audience left voluntary before the movie was half over. The only reason I sat through to the end was because I kept hoping to find some value in it somewhere. But alas, it was either entirely pointless, or the point passed me by. And it was utterly gross.
This one has long been at the very *bottom* of my movie list, just below "A Wedding".
I'm also using doxygen at work, generating HTML and occasionally RTF. I'm very pleased with it. It has a few rough edges, but ongoing development is very active. Each release brings bug fixes and improvements.
Slashdot Mirror
Thank you.
... I feel sorry for the people that get really sick.
On behalf of my wife, who has mast cell disease, thank you for the sentiment.
This sort of frivolous pollution absolutely should be made illegal. What a monumental lack of common sense or consideration for others.
Even more effective than the programmer that avoids writing code by writing efficient code is the programmer that writes code which allows his coworkers to write less code. If you've got someone who's good at this sort of thing, the best use for them is to write the tools that improve everyone's efficiency.
Except that these fees are not new or exceptional to the Droid. The data plan prices cited in the article are what Verizon has been charging for at least a year, for any data-capable phone. I know because I paid exactly that much for the privilege of tethering my phone during a two-week driving vacation last year. I think that the data plans are too expensive, especially given the caps. I was willing to pay the fees temporarily for access to the very good coverage that Verizon provides. But I've also seen people speculate that AT&T is charging too little, resulting in network congestion.
"... because functional programming is seen as very pure and simple, there is a myth that Scheme programs do not need much documentation." This sits alongside the myth that Scheme is a functional language, and the one that equates a lack of manifest variable typing with functional programming. More importantly, the notion that manifest types provide all the documentation that you need to understand returned values or argument requirements is also a myth. For non-trivial code, there's no substitute for informative comments, regardless of language.
Thanks for that link. A much, much better summary.
It's completely absurd to let phone companies own and control the wires, and yet be allowed to string wires wherever they want with no compenstation to the property owners or the state. I think that's overstating the reality, or at least oversimplifying. A right of way, although often taken via eminent domain, is often paid for -- to the initial owner who is forced to grant it. After that, the loss of property value is presumably built into the price. (I know that whenever I've considered land for purchase, I have checked carefully -- myself -- for rights-of-way, and taken them into consideration.) Whether compensation is generally fair or not probably varies -- in fact, most of the details probably vary a lot state to state. The utilities do pay for the equipment and its upkeep. I don't think anyone is or was working towards publically-owned equipment. At least I don't ever remember hearing of any community proposing to pay a company to buy the equipment. What is generally done in the U.S. is to pretend that the utilities are private companies while regulating the use of their assets as if we, the public, owned them. It's a fundamentally screwed up and morally dishonest system that naturally leads to lousy companies and unhappy consumers. One entity representing consumers dictates -- with absolute power -- how to use assets and price product, while another entity, which is trying to make a profit for its shareholders, is responsible for owning, maintaining, and (hopefully) expanding those assets. What a joke. California's electrical system gave a wonderful example of how well this works. Most of cases of truly publically-owned utilities that hear of -- community-owned electric or phone companies, for instance -- sound like they work out fairly well. However, I haven't heard of any cases where the community owned and operated the pipes and leased them to suppliers. It would be interesting to hear if this has been tried, and how it worked out.
Libertarian capitalism, like communism, looks good on paper but fails utterly in reality.
The problem being that it usually seems to fail due to government interference. It's hard these days in the U.S. to find an industry where the government hasn't interfered significantly via protective legislation or subsidies in various forms. Abroad, it's hard to find a free market economy that wasn't hobbled at inception by a too-rapid transition from a prior system, resulting in a lack of adequate financial and legal infrastructure. Admittedly, legislative stupidity is part of the 'reality' that a market model has to deal with, but at least in this country it's an aspect of reality that we could influence.
There are numerous things wrong with our current telecomm infrastructure in the U.S. It seems to me that there are two long-term directions we could take that would improve it. We could be honest about wanting government control over the pipelines, and pay for them. Perhaps communities could use the recent despised (rightly so, IMO) liberalization of eminent domain laws to buy the pipelines -- poles, wires, associated rights-of-way -- and lease use back to the telecomm companies. (Wouldn't be fun to turn liberalized eminent domain against the large corporations that wanted it?) We would have to be willing to pay the taxes necessary for the purchases and upkeep. This would be much more honest than the current situation.
Alternately, liberalize it, continuing in the current direction. These effective monopolies won't last in the face of improving wireless communications and other technologies. If prices go up, there'll be more incentives and money available to develop alternatives. Prices will eventually come down again.
Neither path should be pursued by sudden changes in the legislative environment, because it's the transitions that cause hardship. But we, as a nation, or at least as individual communities, need to figure out which alternative we prefer and stick to it. The current waffling back and forth is what causes a lot of grief.
I understand the similarity that this has with in-band signalling. But part and parcel of this is that the special values are, by definition, no longer considered "in-band". You have to take steps to treat the special values as special, and not confuse them with "real" data. It's simple: A type defines a set of possible values. So you define the set of values for a field to include a valid range, plus some special values, and you define how these interact. The fact that the special values are represented in a way that's similar to the other values is a physical consideration, not a logical one. BTW, what the heck is the "domain of a tuple"? And NULLs are not values, which is the entire point of the discussion. SQL couldn't properly define operations on it, because it's a lack of something, not a something. If you replace NULL with a special *value*, you'll have exactly what I'm describing.
That's the way that Codd went in second version of the relation model. But it just makes even more of a mess out of what *should* be simple two-state predicate logic. Personally, I'm firmly in the "no NULL" camp. I like it when boolen logic operators do what they're supposed to.
Choosing the special values carefully can make queries simple, too: Consider how the special values are ordered compared to non-special values. For instance, I've set aside two special date values to represent "infinite past" or "infinite future"; the former is a value that sorts before all valid non-special values, the latter sorts after them. Use the former to mean "we don't have a specific date, but consider this event to have happened already". The latter is used to mean "we don't have a specific date, but consider this event as never having occurred".
This approach is quite practical and gives you a lot of flexibility.
It would be perfectly possible in a relationally complete language that includes a relational MINUS operator, without NULLs entering into it at all. And Tutorial D, on which the object of this article is based, does of course include such an operator. Whether NULLs are desirable or not is a matter of ongoing raging debate. I've found them easy to avoid, and queries of all sorts easy to understand without them.
The Gnus package in (X)Emacs does this, via the Expire feature. It's not everyone's cup of tea, but if you're an Emacs user, it's nice to be able to read mail and news while having access to the editing environment that you're used to.
Nice review. This book is also one of my all-time favorites. In fact, I just re-read it a few weeks ago, after buying the, umm, fourth copy, I think. (All the others got lent out and never came home.) To the guy that didn't like Deepness in the Sky: IMO, there's no comparison between the two books. Although I liked that book too, A Fire Upon the Deep was far more engrossing. I also recommend Vinge's Across Realtime. Interesting stories spun around a neat technology, starting in the near future.
Yikes. I saw this movie when I was in college, at a theater just off campus. It was the only movie I've ever attended where more than half of the audience left voluntary before the movie was half over. The only reason I sat through to the end was because I kept hoping to find some value in it somewhere. But alas, it was either entirely pointless, or the point passed me by. And it was utterly gross. This one has long been at the very *bottom* of my movie list, just below "A Wedding".
Also, wallboard contains a lot of binders. It is a major and long-term source of formaldehyde outgassing.
I'm also using doxygen at work, generating HTML and occasionally RTF. I'm very pleased with it. It has a few rough edges, but ongoing development is very active. Each release brings bug fixes and improvements.