I'm not saying that privatization caused the tiger escape.
So how is the tiger attack "an example of the tragedy of privatization"?
The definition of "example" is: "one (as an item or incident) that is representative of all of a group or type" ( http://www.m-w.com/ ). Other similar definitions involve words like "pattern" or "rule".
So, if the tiger attack is "an example of the tragedy of privatization", then the tiger attack needs to fit into some group, type, rule or pattern such that it excludes public ownership, but includes private ownership.
You said previously "the tiger escape is part of a pattern", but you have yet to define this pattern (even though I asked very specifically).
is yet another example of them screwing up
It is at least as much of an example of the publicly owned zoo screwing up. It's purely by chance that the attack happened when the zoo was under private ownership. In fact, it appears to be more of an example of the publicly owned zoo screwing up, since they built the wall in violation to begin with.
The fact that the inspectors signed off on it is a little suspicious since it clearly violates the guidelines.
It is suspicious, but you haven't presented any reason this is unique to the time it was under private ownership.
I'm saying the tiger escape is part of a pattern that has occurred ever since the zoo was privatized.
Part of what pattern, precisely? The cause of the tiger escape was that the wall was too short (primary cause), and that no safety audit ever caught the violation (secondary cause). I challenge you to state the pattern you're referring to in such a way that:
(a) the pattern is responsible for one of the aforementioned causes of the tiger escape; and
(b) the pattern includes private ownership; and
(c) the pattern excludes public ownership
The building of the wall was clearly not the fault of private ownership. The safety audits are equally guilty under public and private ownership.
Even if your criticisms of the free market are accurate, this tiger escape is not a good example of that, at all. The exact same dangers existed under public ownership; in fact, the primary cause (building of a tiger enclosure that violated accepted rules of safety) occurred under public ownership.
You aren't helping your cause by assertively displaying your tenuous grasp on logic.
Well, except the guy who got killed, and the people Mauled.. but those are just the "negative externalities" some people have to bear in a free market.
Why was the tiger more likely to jump over the wall after the zoo became private? It's not like they sold the top half of the wall as soon as they bought the zoo.
I'm saying they probably knew and did nothing about it.
There is a disconnect in your logic somewhere. Wouldn't the above statement be as likely to be true when it was a public zoo? In fact, if it was indeed built as a public zoo, then they had to know. The private company might have not noticed (not saying that they did, not saying that they didn't), but there is no way to not notice the height of an enclosure as you're building it.
This is really more of an argument for privatization than against it. It is in the best interests of a private company to avoid a lawsuit. But a public entity doesn't care: the taxpayers always pay it.
Like many other "this vs. that" wars, neither micro- nor monolithic-kernel architectures are best for all tasks.
Like many other "this vs. that" wars, people will use arguments like yours as a cop-out to avoid any serious analysis of the design tradeoffs and the implications of those tradeoffs.
It is quite hollow to say that something is not the "best for all tasks," without some analysis as to when it is the best option, or which option has the most promise in the long term (such that it might be a good field of research).
From the study of C and Java I can say that for 90% of the tasks I've taken on I've needed no more than Java (and Java would in fact be overkill).
The point of academia is that new problems are rare, and old problems are common but take on many forms. Java does automatic garbage collection for many objects correctly.
But what about when your resource is something other than a few bytes of memory? What if your resource is shared among many processes, like a file, shared memory, some kind of protocol state, database connection, or session data? It's no longer good enough to just use a garbage collector, because that was only intended to collect certain types of garbage. You need to write your own, which is simple enough if you already know how existing systems work, but you are likely to make many mistakes if you go at it alone without understanding the trade-offs involved in the different garbage collection strategies.
So just because someone writes a library, tool, or what-have-you doesn't mean that the entire class of problems disappears, it means that one manifestation of the problem has disappeared, but it will probably resurface in another form somewhere else. If you have the education to back it up, you will quickly recognize the problem and solve it. If not, you will surely make all the mistakes that people have already made in the past, and from which you never took the time to learn.
If anything, simplifying CS courses will assist potential employers in identifying those who aspire to excellence in the field and those who are merely pursuing a career.
This is essentially an argument against any kind of formal education, implying that self-taught people are the most qualified. I think formal education provides an opportunity to smart people to learn foundational knowledge which they might never get otherwise. Even smart people don't necessarily seek this knowledge out, and you can't count on finding it in the industry. So where are they supposed to find it?
I think the most important thing formal education provides is the intellectual humility to realize that most ideas you have have already been considered and analyzed. It allows you to recognize whether an idea is fundamentally new (very rare), or if not, what previous ideas have been combined and what the consequences of those ideas have been.
I recently wrote a program in a functional language, and many things surprised me. I think the most important things that I learned were: (1) Programming could be fun again. (2) Pointers (or references, as some languages call them) are not all there is to programming. There is another way.
I wonder how many self-taught programmers decide to learn functional programming? Or OS design? Or computational theory? Or the relational model?
Re:To NULL or not to NULL
on
Sun Buys MySQL
·
· Score: 1
The only thing I would add is that there are certain times when even the rules I have argued need to be broken.
As long as you understand the costs of breaking the rules, in addition to the benefits you see.
The time completed may be NULL if the job hasn;t completed yet because we don't know yet when the job will complete.
You are describing a possible representation of the information that you'd like to store. Just because you can store information in a given manner, doesn't mean that it's good. Inapplicable fields are a sign of bad design.
So the question is, what do you give up? You have mixed your predicates. That means that you can no longer make inferences set-at-a-time, and so you can no longer reason at the level of sets. So what do you intend to do? Does each tuple have its own predicate? How many predicates does a table that contains NULLs have? How complex are those predicates?
Unfortunately the current RDBMS's are not designed to handle these situations well because (IMHO) Codd made a minor and forgivable error in giving NULLs an ambiguous meaning.
In my opinion the error was not minor, and NULLs are worse than ambiguous. NULLs are basically a way for the person inserting data to make up new predicates as they go -- the antithesis of a relational database.
But the idea of "uniqueness" is not as well defined in relational theory.
It's a problem with three-valued logic (3VL, i.e. TRUE/NULL/FALSE), not relational theory. 3VL and uniqueness don't fit well together, because the intuitive definition of uniqueness is based on 2VL (two-valued logic, i.e. TRUE/FALSE). 3VL has similar problems with other operators and constraints, because people generally reason in 2VL, and many transformations (changing one expression into a distinct, but equivalent expression) that are legal in 2VL are illegal in 3VL.
Relational theorists are well aware of these problems, and many suggest abandoning 3VL completely (or any n-VL where n > 2). Out of the remainder, probably not many agree with SQL's odd version of 3VL.
Please reconcile the following two statements for me:
1. And I assert: "People who design things should be *forced* to work on them!"
2. No he doesn't have to actually build the bridge
he should have a good understanding of what will be involved or required to actually build what's been designed
Which can be provided by education, and cannot be provided by experience alone. One person in his lifetime cannot possibly amass enough knowledge to "have a good understanding of what will be involved or required to actually build [the bridge that's] been designed" without a substantial amount of education (and it's highly unlikely that it can be done without advanced education).
Just as education is not a good substitute for experience, experience is not a good substitute for education.
What's the right way to build a bridge? Just build it the same way you built the last bridge? Or should you actually perform the calculations and determine what will stand up to the new conditions at the new site?
My point was: if you live in a landslide state, individual voters should naturally vote for the parties that they really want in power (because they won't affect the current election regardless), until their state is no longer a landslide state (due to enough voters following that advice). Then, magically, their state will have more power.
It is [a waste of their vote]. The British system is much like the US system in that regard, it has been won by the same two parties for so long that it has become ingrained in the British psyche that these are the only two choices.
Many people in the U.S. live in a state in which their electors' party is already a foregone conclusion. That means that it's no more of a waste of vote to vote for a third party than it is to vote for a Democrat or Republican: either way your vote is highly unlikely to influence the results of the election.
In actuality, voting for a third party increases your voting power. It's no more likely to influence the results of the current election, but the next time around the third party you voted for will be stronger.
I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be very easy for a Perl programmer looking for something new to learn Ruby.
That's what I thought at first, but now I would disagree strongly with that statement. I learned perl, then python, then ruby, in that order.
Ruby appears very superficially similar to perl, but it's very different. There are many things perl is great at ruby is horrible at, and it's really hard for a perl programmer to get past that (at least for those problem domains).
For instance, perl has great documentation for almost everything you could want to do, particularly for CPAN modules. Even if something is not "officially" documented well, you can almost always find examples in abundance from google, and that makes the turnaround time on a working product very fast (and a lot of the reason people love perl). Additionally, there are many available modules, and they are often well-designed. In Ruby, documentation is sparse, often incorrect, and modules are often unstable or poorly designed.
This isn't meant to mean that perl is better than ruby, I really like ruby. I'm just saying that it's very hard for a perl or python programmer to accept those shortcomings. Once I realized that, I was able to start using ruby for the things it's great at. I think the ruby language is good enough that it could be great in many problem domains, but that will require a huge amount of focus on quality, stability, and documentation for a wide range of modules.
the idea of a virtual file system that would replace the file/folder metaphor with something resembling the filing system of email clients
That kind of thing works fairly well for email, because most (not all, but most) of the metadata about emails comes from the email itself (e.g. headers). Tags, labels, and other user-supplied metadata are helpful in some situations, but much more limited than it might appear at first. Few people want to spend the time to accurately supply all the correct metadata about each email they receive, because it's largely a waste of time. Also, it's unreliable: usually many of the emails that might fit a certain label don't have that label attached, even if the user is diligent.
File tagging schemes fail because there's no easy way to extract enough useful metadata from an arbitrary file. File tagging systems might work for certain types of files, like emails (hence the success of email clients' organizational schemes), MP3s (because the creator of the file carefully fills out the information according to the ID3 structure); or even text files (which might usefully be indexed for searching).
The environmental movement is unable to acknowledge tradeoffs. If you ask an environmentalist to choose between coal and nuclear, they will say "neither". But that strategy does nothing except maintaining the status quo... and in this case the status quo (coal) is environmentally worse than nuclear.
How about nuclear? Fairly cheap, doesn't take the energy away from other systems, and the pollution is concentrated and contained in convenient waste barrels.
Slashdot Mirror
Sorry if I wasn't clear. I meant the SF Zoo was the example.
Fair enough.
I'm not saying that privatization caused the tiger escape.
So how is the tiger attack "an example of the tragedy of privatization"?
The definition of "example" is: "one (as an item or incident) that is representative of all of a group or type" ( http://www.m-w.com/ ). Other similar definitions involve words like "pattern" or "rule".
So, if the tiger attack is "an example of the tragedy of privatization", then the tiger attack needs to fit into some group, type, rule or pattern such that it excludes public ownership, but includes private ownership.
You said previously "the tiger escape is part of a pattern", but you have yet to define this pattern (even though I asked very specifically).
is yet another example of them screwing up
It is at least as much of an example of the publicly owned zoo screwing up. It's purely by chance that the attack happened when the zoo was under private ownership. In fact, it appears to be more of an example of the publicly owned zoo screwing up, since they built the wall in violation to begin with.
The fact that the inspectors signed off on it is a little suspicious since it clearly violates the guidelines.
It is suspicious, but you haven't presented any reason this is unique to the time it was under private ownership.
I'm saying the tiger escape is part of a pattern that has occurred ever since the zoo was privatized.
Part of what pattern, precisely? The cause of the tiger escape was that the wall was too short (primary cause), and that no safety audit ever caught the violation (secondary cause). I challenge you to state the pattern you're referring to in such a way that:
(a) the pattern is responsible for one of the aforementioned causes of the tiger escape; and
(b) the pattern includes private ownership; and
(c) the pattern excludes public ownership
The building of the wall was clearly not the fault of private ownership. The safety audits are equally guilty under public and private ownership.
Even if your criticisms of the free market are accurate, this tiger escape is not a good example of that, at all. The exact same dangers existed under public ownership; in fact, the primary cause (building of a tiger enclosure that violated accepted rules of safety) occurred under public ownership.
You aren't helping your cause by assertively displaying your tenuous grasp on logic.
Well, except the guy who got killed, and the people Mauled.. but those are just the "negative externalities" some people have to bear in a free market.
Why was the tiger more likely to jump over the wall after the zoo became private? It's not like they sold the top half of the wall as soon as they bought the zoo.
I'm saying they probably knew and did nothing about it.
There is a disconnect in your logic somewhere. Wouldn't the above statement be as likely to be true when it was a public zoo? In fact, if it was indeed built as a public zoo, then they had to know. The private company might have not noticed (not saying that they did, not saying that they didn't), but there is no way to not notice the height of an enclosure as you're building it.
This is really more of an argument for privatization than against it. It is in the best interests of a private company to avoid a lawsuit. But a public entity doesn't care: the taxpayers always pay it.
but one must deal realistically with the animal to prevent future innocent victims.
I think in this case it had more to do with immediate danger than any kind of calculated execution.
the guy 400 yards away
So a tiger is on the loose, and the police had time to set up a sniper? Where did you read that? I thought the police were much closer to the tiger.
So if a driver is in kernel, it can directly access kernel memory buffers. If it is user-mode, it must copy data where the kernel will read it safely.
Why not map the memory-mapped I/O regions to a user-mode device driver? Then it can directly access the device.
Like many other "this vs. that" wars, neither micro- nor monolithic-kernel architectures are best for all tasks.
Like many other "this vs. that" wars, people will use arguments like yours as a cop-out to avoid any serious analysis of the design tradeoffs and the implications of those tradeoffs.
It is quite hollow to say that something is not the "best for all tasks," without some analysis as to when it is the best option, or which option has the most promise in the long term (such that it might be a good field of research).
One of the main issues with microkernels is that of performance,
Do you have information that a microkernel is inherently slower than a monolithic kernel?
Just wait 'til you see 8.3... the performance improvements are amazing.
From the study of C and Java I can say that for 90% of the tasks I've taken on I've needed no more than Java (and Java would in fact be overkill).
The point of academia is that new problems are rare, and old problems are common but take on many forms. Java does automatic garbage collection for many objects correctly.
But what about when your resource is something other than a few bytes of memory? What if your resource is shared among many processes, like a file, shared memory, some kind of protocol state, database connection, or session data? It's no longer good enough to just use a garbage collector, because that was only intended to collect certain types of garbage. You need to write your own, which is simple enough if you already know how existing systems work, but you are likely to make many mistakes if you go at it alone without understanding the trade-offs involved in the different garbage collection strategies.
So just because someone writes a library, tool, or what-have-you doesn't mean that the entire class of problems disappears, it means that one manifestation of the problem has disappeared, but it will probably resurface in another form somewhere else. If you have the education to back it up, you will quickly recognize the problem and solve it. If not, you will surely make all the mistakes that people have already made in the past, and from which you never took the time to learn.
If anything, simplifying CS courses will assist potential employers in identifying those who aspire to excellence in the field and those who are merely pursuing a career.
This is essentially an argument against any kind of formal education, implying that self-taught people are the most qualified. I think formal education provides an opportunity to smart people to learn foundational knowledge which they might never get otherwise. Even smart people don't necessarily seek this knowledge out, and you can't count on finding it in the industry. So where are they supposed to find it?
I think the most important thing formal education provides is the intellectual humility to realize that most ideas you have have already been considered and analyzed. It allows you to recognize whether an idea is fundamentally new (very rare), or if not, what previous ideas have been combined and what the consequences of those ideas have been.
I recently wrote a program in a functional language, and many things surprised me. I think the most important things that I learned were:
(1) Programming could be fun again.
(2) Pointers (or references, as some languages call them) are not all there is to programming. There is another way.
I wonder how many self-taught programmers decide to learn functional programming? Or OS design? Or computational theory? Or the relational model?
The only thing I would add is that there are certain times when even the rules I have argued need to be broken.
As long as you understand the costs of breaking the rules, in addition to the benefits you see.
The time completed may be NULL if the job hasn;t completed yet because we don't know yet when the job will complete.
You are describing a possible representation of the information that you'd like to store. Just because you can store information in a given manner, doesn't mean that it's good. Inapplicable fields are a sign of bad design.
So the question is, what do you give up? You have mixed your predicates. That means that you can no longer make inferences set-at-a-time, and so you can no longer reason at the level of sets. So what do you intend to do? Does each tuple have its own predicate? How many predicates does a table that contains NULLs have? How complex are those predicates?
Unfortunately the current RDBMS's are not designed to handle these situations well because (IMHO) Codd made a minor and forgivable error in giving NULLs an ambiguous meaning.
In my opinion the error was not minor, and NULLs are worse than ambiguous. NULLs are basically a way for the person inserting data to make up new predicates as they go -- the antithesis of a relational database.
But the idea of "uniqueness" is not as well defined in relational theory.
It's a problem with three-valued logic (3VL, i.e. TRUE/NULL/FALSE), not relational theory. 3VL and uniqueness don't fit well together, because the intuitive definition of uniqueness is based on 2VL (two-valued logic, i.e. TRUE/FALSE). 3VL has similar problems with other operators and constraints, because people generally reason in 2VL, and many transformations (changing one expression into a distinct, but equivalent expression) that are legal in 2VL are illegal in 3VL.
Relational theorists are well aware of these problems, and many suggest abandoning 3VL completely (or any n-VL where n > 2). Out of the remainder, probably not many agree with SQL's odd version of 3VL.
Please reconcile the following two statements for me:
1. And I assert: "People who design things should be *forced* to work on them!"
2. No he doesn't have to actually build the bridge
he should have a good understanding of what will be involved or required to actually build what's been designed
Which can be provided by education, and cannot be provided by experience alone. One person in his lifetime cannot possibly amass enough knowledge to "have a good understanding of what will be involved or required to actually build [the bridge that's] been designed" without a substantial amount of education (and it's highly unlikely that it can be done without advanced education).
I didn't say that experience replaces education.
Then I misunderstood what you meant by "trumps".
And I assert: "People who design things should be *forced* to work on them!"
So you want a bridge designer to build the bridge he designed? You're neglecting specialization entirely, on which all modern economies are based.
experience almost always trumps education
Just as education is not a good substitute for experience, experience is not a good substitute for education.
What's the right way to build a bridge? Just build it the same way you built the last bridge? Or should you actually perform the calculations and determine what will stand up to the new conditions at the new site?
I don't understand your point.
My point was: if you live in a landslide state, individual voters should naturally vote for the parties that they really want in power (because they won't affect the current election regardless), until their state is no longer a landslide state (due to enough voters following that advice). Then, magically, their state will have more power.
It is [a waste of their vote]. The British system is much like the US system in that regard, it has been won by the same two parties for so long that it has become ingrained in the British psyche that these are the only two choices.
Many people in the U.S. live in a state in which their electors' party is already a foregone conclusion. That means that it's no more of a waste of vote to vote for a third party than it is to vote for a Democrat or Republican: either way your vote is highly unlikely to influence the results of the election.
In actuality, voting for a third party increases your voting power. It's no more likely to influence the results of the current election, but the next time around the third party you voted for will be stronger.
I think Ruby is really an evolution of Perl. There are a lot of Perlisms in its syntax, and I bet it'd be very easy for a Perl programmer looking for something new to learn Ruby.
That's what I thought at first, but now I would disagree strongly with that statement. I learned perl, then python, then ruby, in that order.
Ruby appears very superficially similar to perl, but it's very different. There are many things perl is great at ruby is horrible at, and it's really hard for a perl programmer to get past that (at least for those problem domains).
For instance, perl has great documentation for almost everything you could want to do, particularly for CPAN modules. Even if something is not "officially" documented well, you can almost always find examples in abundance from google, and that makes the turnaround time on a working product very fast (and a lot of the reason people love perl). Additionally, there are many available modules, and they are often well-designed. In Ruby, documentation is sparse, often incorrect, and modules are often unstable or poorly designed.
This isn't meant to mean that perl is better than ruby, I really like ruby. I'm just saying that it's very hard for a perl or python programmer to accept those shortcomings. Once I realized that, I was able to start using ruby for the things it's great at. I think the ruby language is good enough that it could be great in many problem domains, but that will require a huge amount of focus on quality, stability, and documentation for a wide range of modules.
I disregarded python for the same reason... until I actually tried it.
the idea of a virtual file system that would replace the file/folder metaphor with something resembling the filing system of email clients
That kind of thing works fairly well for email, because most (not all, but most) of the metadata about emails comes from the email itself (e.g. headers). Tags, labels, and other user-supplied metadata are helpful in some situations, but much more limited than it might appear at first. Few people want to spend the time to accurately supply all the correct metadata about each email they receive, because it's largely a waste of time. Also, it's unreliable: usually many of the emails that might fit a certain label don't have that label attached, even if the user is diligent.
File tagging schemes fail because there's no easy way to extract enough useful metadata from an arbitrary file. File tagging systems might work for certain types of files, like emails (hence the success of email clients' organizational schemes), MP3s (because the creator of the file carefully fills out the information according to the ID3 structure); or even text files (which might usefully be indexed for searching).
The environmental movement is unable to acknowledge tradeoffs. If you ask an environmentalist to choose between coal and nuclear, they will say "neither". But that strategy does nothing except maintaining the status quo... and in this case the status quo (coal) is environmentally worse than nuclear.
How about nuclear? Fairly cheap, doesn't take the energy away from other systems, and the pollution is concentrated and contained in convenient waste barrels.