Problems with data integrity always point to errors in memory handling logic.
You're thinking of what's called physical data integrity. Your statement is only right if we grant you that assumption.
However, relational database management systems are supposed to also guarantee logical data integrity. This is, in general, validity of constraints on the data (value range constraints, uniqueness constraints, foreign key constraints, all-or-nothing transactions, etc.). MySQL is correctly criticized for not enforcing this kind of data integrity.
The company that writes some application that talks to a GPLed MySQL will have to follow the GPL in distributing MySQL. They will not have to license their own code as GPL.
From GP's comment, it sounded to me like MySQL AB has argued that any application that absolutely needs MySQL to function is a derivative work of MySQL, and thus, cannot be distributed without license from MySQL AB; and that therefore, to distribute such an application, one must either license it under the GPL, or obtain a commercial license from them. The argument seems to hold that whether the application links to a GPL-licensed MySQL client library or not is irrelevant; what would matter is whether the application can be functionally severed from MySQL.
No offense, but those are reasonable assumptions for most households with guns. After all, if a condition of a gun license (much like a driver's license) is that you train with the weapon on a regular basis, then that alone would satisfy several of the conditions on your list.
California is one of the states in the USA with the strictest gun laws. To buy a handgun to keep at home, you must pass a written test, and at the point of purchase, successfully complete a safety demonstration with that gun. Firearms that do not have a state-approved safety device can only be sold to people who demonstrate ownership of a gun safe that meets certain standards. In addition, you may be guilty of a felony if a child gains access to your firearm and thereby causes death or injury to any person unless the firearm was in a secure locked container or locked with a locking device that rendered it inoperable.
That's it. There's no requirement that you have ever trained to effectively use the firearm. And again, this is California, a notoriously gun-strict state.
Most criminals breaking into houses simply to make off with expensive but easy-to-grab items won't hit an occupied house, and are relatively easily deterred by the above methods. But it's the criminals who specifically target occupied residences, either because they're after something more valuable or they wish to harm said occupants, that are the concern.
The gun in the safe at home only has a chance of being useful in burglaries where the residence is occupied, whether the burglar knows that the residents are in. The point then is twofold:
These burglaries are uncommon compared to those where the house is not occupied. Having a gun at home optimizes for the uncommon risk; the rest of the time (which will more likely be all of the time), you have to bear the risks of having a gun in the home.
A burglar who knowingly targets an occupied residence has larger commitment at using violence to get his way than his victims, and also more experience and skill at doing so. He has chosen the time and place for the act, and has the initiative. The victim is at a disadvantage in such a situation; and the gun escalates it to a lethal one.
The problem is that all of these "defend my family and home from an attacker" scenarios used to justify gun ownership systematically assume the best circumstances to justify gun ownership. They assume:
that the resident is peaceful and not prone to turn the gun against the family in a moment of passion;
that the gun is well-secured in a gun safe at all times, but yet instantaneously available when needed;
that the burglary will happen while the gun-owner is at home;
that the gun-owner will correctly assess the developing situation quicker than the burglar (unlikely!);
that the gun-owner has enough training and practice to use the gun effectively;
that the gun-owner is truly determined to shoot another human being;
that the gun-owner will correctly judge, in the heat of the moment, which uses of lethal force would not be justified in the situation;
that the gun-owner will not, by attempting to use the gun in that situation, put himself at a higher risk than in the equivalent, gun-less situation;
etc.
It's fantasy self-defense; the gun makes the gun-owner feel safer, and the scenarios are concocted as a rationalization for what the gun-owner wants.
Actually, I would recommend that every home owner buy a gun. If you shoot the guys breaking in, they won't do it again.
You're not likely to be home when they break in, because the burglars get to choose the time (broad daylight on a weekday is best). The gun then just serves two functions:
One more thing for the burglars to steal.
A useful tool for household suicide or homicide.
If you want to protect your home against burglary, the most effective thing is to fortify the entry points into your house so you slow down the burglar enough to make him choose a different target. Second most effective thing is an effective home alarm system that automatically notifies responders.
This leads us to the only part of the GPL that I think is in any way legally questionable (IANAL). I'm not sure it is entirely legally clear if the copyright holder is allowed to revoke the GPL licensing terms or not, no matter what is said in the license. (i.e. They could argue that the license is not a binding contract).
From GPLv3: "All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. " GPLv2 doesn't have this text, though.
IANAL, but my understanding is that a copyright license is not a contract in the first place, so the example argument you cite just can't work. A copyright license is the permission (hence the word "license") granted by the copyright holder to another party, allowing that party to make copies of the work in question. Granting a copyright license to somebody doesn't create any obligations for either party; it just expands the receiver's privileges.
Here's my question in all this-- if I can buy webserver bandwidth for $0.10 per GB, why does TW/Comcast/Whoever want to charge me a whole dollar for each GB I use over my monthly plan limit?
It's cheaper to provision for extra bandwidth in a colocation center than at a residence or neighborhood. Whether it's $0.90 cheaper is another question, but you certainly shouldn't judge the cost of residential bandwidth by the cost of colo bandwidth.
Re:Postgres is looking better than ever
on
Oracle Buys Sun
·
· Score: 1
I know you can match insensitively, but it boggles my mind that it's not the default. I expect "=" to mean "equals", not "closely approximates if you throw away enough information".
The case sensitivity isn't just about the equality operator; it's also about index structure and uniqueness constraint checking. Basically, if you declare a uniqueness constraint on a column with a case-sensitive collation, you're going to allow keys that differ on 'abc' vs. 'ABC', which trust me, will lead to duplicates.
From the other comments, it does seem like MySQL does have the correct solution here: per-column collations, so that "equality" stands for a user-chosen equivalence relation.
I think GP may have understood you originally as meaning that PostgreSQL was like Microsoft SQL Server, but better implemented.
Re:Postgres is looking better than ever
on
Oracle Buys Sun
·
· Score: 1
IMO it's preferable for software to not assume that "Helped my uncle Jack off a horse." and "Helped my uncle jack off a horse." are the same thing.
Case sensitivity is utterly moronic, but databases should certainly support fine control over collation. MS SQL Server works pretty fine here; you can choose collations on a per-column basis if you want (which affect what string values are equivalent for querying, indexing and constraints). Dunno what support Postgres has...
In the short term this actually serves to prop up the existing, entrenched, players. However if you look longer term, if they can't make money on it, their promotion model will eventually die too. The end result would be a level playing field.
Yeah, but the point is that over the medium term, either the labels will figure out a new distribution model, or somebody who does will take over the labels for their promotional goods.
The old distribution models no longer work. So the people losing will fight it tooth and claw. There are winners and losers in a New World Order.
You're missing the point of the essay. The author's point is that the old promotion models still work pretty damn well; this is why the top 100 on The Pirate Bay is all major label artists. So, overall, even if the major labels are suffering right now because of the breakdown of the distribution models, they're still going to come out as winners.
The assumption is that pirated music should favor the less known artists somehow?
The essay is implicitly assuming that the most popular artists are popular because they're signed to a major label. The argument seems to be that the all-too-common claims that filesharing is good for the independent artists are bunk; filesharing has done nothing to break the hold of the major labels on the promotion and marketing of musical acts. As long as they can hold on to those, they will survive, and eventually they will figure out how to take advantage of the internet to make loads of money.
In the end, we'll have advertisements embedded into the hit singles, as part of the music and lyrics.
Since more programmers are familiar with languages with Algol-derived syntax (either procedural languages like C or OO languages with similar syntax like Java), code that is written in that syntax, or in other syntax with constructs that mimic that syntax, are readily understood, while, e.g., Lisp code presents more of a barrier.
While I don't discount syntax as a factor, I'm not convinced that this is really the most important one. See below.
[...] languages which adopt constructs popularized in functional languages with non-Algol-derived syntax and present them with a syntax that is more accessible to those familiar with Algol-derived syntax (e.g., Ruby, Python, etc.) are often particularly praised for their expressiveness and clarity by people who would shun the languages from which they are adopting features.
Frankly, I find that they are most often dismissed because the constructs in question are "too complicated," even when the examples shown are more concise and flexible ways of doing things that the programmer already does all the time.
For example, all competent imperative programmers know the following two patterns very well:
Iterate over a sequence of elements to produce a second sequence that has the same number of elements as the original, in the same order, and where each element of the resulting sequence is the result of applying an operation to the corresponding element of the original sequence. For example, you have a sequence of URLs, and you want to produce a sequence of documents.
Initialize an accumulator variable to an initial value, and then loop over a sequence of elements, updating the accumulator variable in each iteration with the result of applying an operation to the current value of the accumulator and the current sequence element. So for example, you have a list of numbers, and you want to produce the sum of those numbers.
Programmers who complain about functional operations like map, fold and reduce being "too hard" or "too complicated" write what's structurally the same stupid loops, over and over, every single time they have to perform a computation of this form; they master the concepts of map, reduce and fold in practice, but insist in verbosely spelling them out at the low-level every single time, over and over. I call it BabyTalk programming; they think the program style is "clear" because they can immediately understand what each individual operation is doing; but this is only so because they're not abstracting away the most common complex patterns.
And since you brought up Python, well, Guido's comments on reduce() are a prime example of this; and Python is the reigning BabyTalk language.
You might ask yourself why the $20K'ers think that. A flat tax would be fine, if there weren't all sorts of loopholes that unfairly benefit the rich. (Buy a nice yacht for yourself, spend some money on it, be $50k, or $25M. Put a propane camp stove in it. Put a single mattress in it. Voila, you have a second home, and you get to write off the interest on your repayments as a deduction! And so on and so forth.)
You're forgetting the most important one: invest your billions in the stock market, hold it for the long term, and then sell your stocks when you need money. If you got a profit, it's taxed at 15%. If you got a loss, you deduct it from taxes.
You do realize that the tax rates on those in top 5% were higher in 1940s-1980s than today, right? Trust me, no one in the top 5% has ever worked a hard day in their life.
Other people have pointed out the problem that the 5% figure leads to in this case, and the problem that many of the ultra-rich did work pretty hard. I'll point out something different, but which I think is more important: you're implicitly assuming that how much somebody's paid should depend on how hard they work. That would be a really, really bad thing to do, because it provides a perverse incentive for working hard instead of working smart.
This is not to say that there aren't plenty of good arguments against the concentration of wealth that prevails in our society. All I mean here is that the one you're using here sucks.
Sense and Reference seems to me very similar to conceptually trying to figure out the relationship between pointers and variables in programming.
Um, no. Pointers/references are mutable reference cells, i.e., stateful objects. Sense and Reference is, roughly, about synonymy.
The most famous example sentences in Sense and Reference are "The morning star is the evening star," and "The morning star is the morning star." The reference of the expressions "the morning star" and "the evening star" is the same, namely, Venus. However, the first sentence is an astronomical discovery, while the second one is a tautology. This is because while the two expressions have the same reference, they don't have the same sense. In particular, while the reference of a name is the object it stands for, the sense is something else.
In programming language terms, the simplest example I can think of for the analogous result is that in a purely functional programming language, there can be two very different implementations of the same function (where "function" here means "mapping of arguments to results"). The two implementations have the same reference (the same function in the sense I listed), but different senses (the fact that the two implementations do the same thing is not tautological; it may require a very non-trivial proof).
I liked him when he was just doing small gigs, but once he got a whiff of fame he sold out.
Oh boy, no. I know you are joking, but Wittgenstein was crazy enough that the truth is funnier than the joke.
Wittgenstein believed that his first book, the Tractatus Logico-Philosophicus, solved all of the problems of philosophy. Therefore, since there were no more problems left to solve, Wittgenstein quit philosophy and became a grade school teacher in rural Austria.
After he lost that job (because of beating up a student), he temporarily became a gardener in a monastery he wanted to join, until the monks supposedly convinced him that he wasn't really cut out for the monastic life. (Gee, you have to wonder why they told him that.) So he then became an amateur architect to help his sister build a house she liked (which is now a historical building).
Then he started chatting with some philosophers and mathematicians once in a while and changed his mind about his book: he concluded that, after all, he had not solved all of the problems in philosophy. So he moved to Cambridge to go back to doing philosophy, and after a couple of years, he discovered that he had not solved all of the problems in philosophy because there are none. After that, he spent the next 18 years or so, nearly the rest of his life, writing and rewriting the Logical Investigations, a book that nobody has ever understood, and whose publication he only allowed to happen after his death, because his writing sucked so much he couldn't bear to subject the general public to it while he was still alive.
Oh, and his father was the richest man in Austria, but he surrendered his portion of the inheritance because he didn't believe in money...
Relational modeling assumes a break-down into categories of facts (represented by relations) that is very similar to break down into classes and instances in the least flexible implementations of the OO paradigm.
I think you're missing the point. The relational model doesn't just break down facts into categories and leave it at that. The relational model treats relations as logical predicates, and tuples as logical propositions. And the key thing about this is that propositions stand in a relation of logical consequence to other propositions. The really important thing about "facts" is how they relate to other "facts" by logical entailment; the key thing about "objects" seems to be what categories they belong to, and what attributes this entails.
Insofar as there is an impedance mismatch, its largely an artifact of implementation details in specific "relational" systems vs. specific "OO" systems, rather than a fundamental incompatibility in the models.
Well, if you asked me, I'd just say that OO just doesn't solve the more general data management problems. A custom OO model for the benefit of an individual application is probably fine, but there's just no way to generalize it to the more general problems of managing data that's important beyond the context of an individual application. There is no overarching taxonomy of categories that the objects of the world fit in, and hell, even worse, there is no such thing as the proper division of the world into "objects."
However, given multiple, seemingly different schemas for classifying and categorizing, there is very often a semantically powerful isomorphism or at least homomorphism between them, that allows representations of one kind to be systematically transformed into representations of the other. The relational model is the data management paradigm that I've seen that best reflects this, because its logical grounding allows for tons of such systematic transformations.
Thus, the supposed object-relational impedance mismatch is a fiction stemming from object-oriented modeling advocates who just don't understand relational modeling; they want to store application-specific representations in a relational database, when the database is meant for storing information in an application-agnostic fashion. If you want to store application data in a relational database, well, you should have to do some extra work to transform the application-specific representation to an application-agnostic one.
If that's your reaction to the Tractatus, then you clearly didn't read it very carefully or understand it very well.
No, Wittgenstein really was not a very good writer. Very cryptic and rambling, using very unorthodox authorial techniques that he doesn't explain at length. One thing that's very telling is that reading Wittgenstein's biography is actually very helpful in understanding his work; it's pretty clear that W. fails in giving you a lot of context that you need to more easily understand him.
On the positive side, he often made some really striking analogies.
To really sum it up: Is the world made of sets or is it made of graphs?
No, that's really just two different versions of "the world is made of facts, not things." Set theory doesn't rely on objects having essential properties; the only thing set theory assumes of the set members is that there is an identity relation on them. (Though of course, as we both know, sets really are graphs!)
In criticizing the philosophy of the Tractatus - specifically view of language as being bounded everywhere by rules - Wittgenstein thinks about languages as games, gains a valuable insight by comparing it to games like tennis. In tennis, there are rules for where you stand when serving, where you can and cannot hit the ball to have it count as a point, etc. But the game isn't bounded everywhere by rules - for example, how high can you hit the ball? So too with human language.
I think you're missing the most important point about Wittgenstein's game analogies. It's part of a critique of the classical theory of categories, which assumes that categories have necessary and sufficient conditions for membership, that language terms stand for categories, and thus, insists that terms must have definitions in terms of necessary and sufficient conditions for the applicability of the term. Thus, the term "game" stands in need of a definition that tells us what are the properties that all games share.
Wittgenstein tries to get us to see that there's no such definition to be had for "game"; as you try various candidate properties to see if they're shared by all games, you always find some game that doesn't have it. Games stand in a set of family resemblances to each other. But when you start following this idea through, you start to understand that Wittgenstein is inviting us to see instances of "language" in the same light as he's made us see the instances of games: language is a large complex of social practices that share family resemblances to each other.
The other Wittgenstinian analogy that's relevant here is that language is like a toolbox. This fits in quite nicely with the family resemblance discussion, too: what is the property shared by all tools? To quote Wittgenstein's parody of the attempt to provide such a property:
14. Imagine someone's saying: "All tools serve to modify something. Thus the hammer modifies the position of the nail, the saw the shape of the board, and so on."---And what is modified by the rule, the glue-pot, the nails?---"Our knowledge of things' length, the temperature of the glue, and the solidity of the box."-----Would anything be gained by this assimilation of expressions?---
Also, Wittgenstein's treatment of rules is quite a bit more radical than you state it here, because it's framed as a critique of the notion of rule-following: the idea that rules "guide" the behavior of people. This is probably the part of Wittgenstein that's the most relevant to computer science, and in particular, to AI (classic AI fundamentally sees intelligence as rule-following). Alas, I haven't reviewed these parts in a while.
Yes, I know this is specifically a topic about programming languages, something that the Tractatus deals with much better, being primarily about idealized languages for philosophical reasoning, but if you're going to start reading the man's work, you'd do yourself a favor by considering his earlier work in light of the critiques he presents in his later work.
It's actually controversial to what extent Wittgenstein repudiated the Tractatus. More generally, the Tractatuts might well be the book that Wittgenstein's readers most disagree about. Wittgenstein always insisted that the philosophers who most admired the Tractatus completely missed the point behind it. There's certainly a shared theme between it an the Investigations: philosophy is a kind of confusion that comes up when philosophers fail to understand the limits of language. In the Investigations, the critique of philosophers' abuse of language takes the form of an attack on the classical theory of categories (the one that the idea of family resemblances is opposed to). In the Tractatus, on the other hand, the critique is based on the extremely obscure idea that there are things that language "shows" without "saying"--an idea that the book is (arguably) supposed to "show" rather than say...
In all seriousness, however, philosophy and programming are amazingly similar. They each are about breaking down complex thoughts into atomic, logical pieces. The origin of computer theory is in philosophy.
Plenty of philosophers would disagree with you. I'll mention the late Wittgenstein as an example and leave it there.
I don't think the object-relational impedance mismatch is really fitting to expose the philosophical differences between programming languages, since the one describes behaviour and local subspace of the system state space while the other views the system as a consistent whole, being an end-state of the various local processes.
But what I meant to single out is not programming languages, but rather, data modeling; i.e., the use of computer programs to reason about the world.
However, I still think that there's a programming language philosophical difference of the sort you're interested in here, though not between OOP/relational, but rather, between imperative/functional (or more generally, imperative/declarative). Functional in this regard sounds very much like your characterization of the relational model right there--but I'd need to better unpack the very succinct point you're making here before I could comment more intelligently.
Slashdot Mirror
You're thinking of what's called physical data integrity. Your statement is only right if we grant you that assumption.
However, relational database management systems are supposed to also guarantee logical data integrity. This is, in general, validity of constraints on the data (value range constraints, uniqueness constraints, foreign key constraints, all-or-nothing transactions, etc.). MySQL is correctly criticized for not enforcing this kind of data integrity.
From GP's comment, it sounded to me like MySQL AB has argued that any application that absolutely needs MySQL to function is a derivative work of MySQL, and thus, cannot be distributed without license from MySQL AB; and that therefore, to distribute such an application, one must either license it under the GPL, or obtain a commercial license from them. The argument seems to hold that whether the application links to a GPL-licensed MySQL client library or not is irrelevant; what would matter is whether the application can be functionally severed from MySQL.
California is one of the states in the USA with the strictest gun laws. To buy a handgun to keep at home, you must pass a written test, and at the point of purchase, successfully complete a safety demonstration with that gun. Firearms that do not have a state-approved safety device can only be sold to people who demonstrate ownership of a gun safe that meets certain standards. In addition, you may be guilty of a felony if a child gains access to your firearm and thereby causes death or injury to any person unless the firearm was in a secure locked container or locked with a locking device that rendered it inoperable.
That's it. There's no requirement that you have ever trained to effectively use the firearm. And again, this is California, a notoriously gun-strict state.
The gun in the safe at home only has a chance of being useful in burglaries where the residence is occupied, whether the burglar knows that the residents are in. The point then is twofold:
The problem is that all of these "defend my family and home from an attacker" scenarios used to justify gun ownership systematically assume the best circumstances to justify gun ownership. They assume:
It's fantasy self-defense; the gun makes the gun-owner feel safer, and the scenarios are concocted as a rationalization for what the gun-owner wants.
You're not likely to be home when they break in, because the burglars get to choose the time (broad daylight on a weekday is best). The gun then just serves two functions:
If you want to protect your home against burglary, the most effective thing is to fortify the entry points into your house so you slow down the burglar enough to make him choose a different target. Second most effective thing is an effective home alarm system that automatically notifies responders.
From GPLv3: "All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. " GPLv2 doesn't have this text, though.
IANAL, but my understanding is that a copyright license is not a contract in the first place, so the example argument you cite just can't work. A copyright license is the permission (hence the word "license") granted by the copyright holder to another party, allowing that party to make copies of the work in question. Granting a copyright license to somebody doesn't create any obligations for either party; it just expands the receiver's privileges.
It's cheaper to provision for extra bandwidth in a colocation center than at a residence or neighborhood. Whether it's $0.90 cheaper is another question, but you certainly shouldn't judge the cost of residential bandwidth by the cost of colo bandwidth.
The case sensitivity isn't just about the equality operator; it's also about index structure and uniqueness constraint checking. Basically, if you declare a uniqueness constraint on a column with a case-sensitive collation, you're going to allow keys that differ on 'abc' vs. 'ABC', which trust me, will lead to duplicates.
From the other comments, it does seem like MySQL does have the correct solution here: per-column collations, so that "equality" stands for a user-chosen equivalence relation.
I think GP may have understood you originally as meaning that PostgreSQL was like Microsoft SQL Server, but better implemented.
Case sensitivity is utterly moronic, but databases should certainly support fine control over collation. MS SQL Server works pretty fine here; you can choose collations on a per-column basis if you want (which affect what string values are equivalent for querying, indexing and constraints). Dunno what support Postgres has...
Yeah, but the point is that over the medium term, either the labels will figure out a new distribution model, or somebody who does will take over the labels for their promotional goods.
You're missing the point of the essay. The author's point is that the old promotion models still work pretty damn well; this is why the top 100 on The Pirate Bay is all major label artists. So, overall, even if the major labels are suffering right now because of the breakdown of the distribution models, they're still going to come out as winners.
The essay is implicitly assuming that the most popular artists are popular because they're signed to a major label. The argument seems to be that the all-too-common claims that filesharing is good for the independent artists are bunk; filesharing has done nothing to break the hold of the major labels on the promotion and marketing of musical acts. As long as they can hold on to those, they will survive, and eventually they will figure out how to take advantage of the internet to make loads of money.
In the end, we'll have advertisements embedded into the hit singles, as part of the music and lyrics.
While I don't discount syntax as a factor, I'm not convinced that this is really the most important one. See below.
Frankly, I find that they are most often dismissed because the constructs in question are "too complicated," even when the examples shown are more concise and flexible ways of doing things that the programmer already does all the time.
For example, all competent imperative programmers know the following two patterns very well:
Programmers who complain about functional operations like map, fold and reduce being "too hard" or "too complicated" write what's structurally the same stupid loops, over and over, every single time they have to perform a computation of this form; they master the concepts of map, reduce and fold in practice, but insist in verbosely spelling them out at the low-level every single time, over and over. I call it BabyTalk programming; they think the program style is "clear" because they can immediately understand what each individual operation is doing; but this is only so because they're not abstracting away the most common complex patterns.
And since you brought up Python, well, Guido's comments on reduce() are a prime example of this; and Python is the reigning BabyTalk language.
You're forgetting the most important one: invest your billions in the stock market, hold it for the long term, and then sell your stocks when you need money. If you got a profit, it's taxed at 15%. If you got a loss, you deduct it from taxes.
Other people have pointed out the problem that the 5% figure leads to in this case, and the problem that many of the ultra-rich did work pretty hard. I'll point out something different, but which I think is more important: you're implicitly assuming that how much somebody's paid should depend on how hard they work. That would be a really, really bad thing to do, because it provides a perverse incentive for working hard instead of working smart.
This is not to say that there aren't plenty of good arguments against the concentration of wealth that prevails in our society. All I mean here is that the one you're using here sucks.
Um, no. Pointers/references are mutable reference cells, i.e., stateful objects. Sense and Reference is, roughly, about synonymy.
The most famous example sentences in Sense and Reference are "The morning star is the evening star," and "The morning star is the morning star." The reference of the expressions "the morning star" and "the evening star" is the same, namely, Venus. However, the first sentence is an astronomical discovery, while the second one is a tautology. This is because while the two expressions have the same reference, they don't have the same sense. In particular, while the reference of a name is the object it stands for, the sense is something else.
In programming language terms, the simplest example I can think of for the analogous result is that in a purely functional programming language, there can be two very different implementations of the same function (where "function" here means "mapping of arguments to results"). The two implementations have the same reference (the same function in the sense I listed), but different senses (the fact that the two implementations do the same thing is not tautological; it may require a very non-trivial proof).
Oh boy, no. I know you are joking, but Wittgenstein was crazy enough that the truth is funnier than the joke.
Wittgenstein believed that his first book, the Tractatus Logico-Philosophicus, solved all of the problems of philosophy. Therefore, since there were no more problems left to solve, Wittgenstein quit philosophy and became a grade school teacher in rural Austria.
After he lost that job (because of beating up a student), he temporarily became a gardener in a monastery he wanted to join, until the monks supposedly convinced him that he wasn't really cut out for the monastic life. (Gee, you have to wonder why they told him that.) So he then became an amateur architect to help his sister build a house she liked (which is now a historical building).
Then he started chatting with some philosophers and mathematicians once in a while and changed his mind about his book: he concluded that, after all, he had not solved all of the problems in philosophy. So he moved to Cambridge to go back to doing philosophy, and after a couple of years, he discovered that he had not solved all of the problems in philosophy because there are none. After that, he spent the next 18 years or so, nearly the rest of his life, writing and rewriting the Logical Investigations, a book that nobody has ever understood, and whose publication he only allowed to happen after his death, because his writing sucked so much he couldn't bear to subject the general public to it while he was still alive.
Oh, and his father was the richest man in Austria, but he surrendered his portion of the inheritance because he didn't believe in money...
I think you're missing the point. The relational model doesn't just break down facts into categories and leave it at that. The relational model treats relations as logical predicates, and tuples as logical propositions. And the key thing about this is that propositions stand in a relation of logical consequence to other propositions. The really important thing about "facts" is how they relate to other "facts" by logical entailment; the key thing about "objects" seems to be what categories they belong to, and what attributes this entails.
Well, if you asked me, I'd just say that OO just doesn't solve the more general data management problems. A custom OO model for the benefit of an individual application is probably fine, but there's just no way to generalize it to the more general problems of managing data that's important beyond the context of an individual application. There is no overarching taxonomy of categories that the objects of the world fit in, and hell, even worse, there is no such thing as the proper division of the world into "objects."
However, given multiple, seemingly different schemas for classifying and categorizing, there is very often a semantically powerful isomorphism or at least homomorphism between them, that allows representations of one kind to be systematically transformed into representations of the other. The relational model is the data management paradigm that I've seen that best reflects this, because its logical grounding allows for tons of such systematic transformations.
Thus, the supposed object-relational impedance mismatch is a fiction stemming from object-oriented modeling advocates who just don't understand relational modeling; they want to store application-specific representations in a relational database, when the database is meant for storing information in an application-agnostic fashion. If you want to store application data in a relational database, well, you should have to do some extra work to transform the application-specific representation to an application-agnostic one.
No, Wittgenstein really was not a very good writer. Very cryptic and rambling, using very unorthodox authorial techniques that he doesn't explain at length. One thing that's very telling is that reading Wittgenstein's biography is actually very helpful in understanding his work; it's pretty clear that W. fails in giving you a lot of context that you need to more easily understand him.
On the positive side, he often made some really striking analogies.
No, that's really just two different versions of "the world is made of facts, not things." Set theory doesn't rely on objects having essential properties; the only thing set theory assumes of the set members is that there is an identity relation on them. (Though of course, as we both know, sets really are graphs!)
Um, or the fact that the type system of languages like O'Caml and Haskell is an elaboration of Russell's type theory, for that matter.
I think you're missing the most important point about Wittgenstein's game analogies. It's part of a critique of the classical theory of categories, which assumes that categories have necessary and sufficient conditions for membership, that language terms stand for categories, and thus, insists that terms must have definitions in terms of necessary and sufficient conditions for the applicability of the term. Thus, the term "game" stands in need of a definition that tells us what are the properties that all games share.
Wittgenstein tries to get us to see that there's no such definition to be had for "game"; as you try various candidate properties to see if they're shared by all games, you always find some game that doesn't have it. Games stand in a set of family resemblances to each other. But when you start following this idea through, you start to understand that Wittgenstein is inviting us to see instances of "language" in the same light as he's made us see the instances of games: language is a large complex of social practices that share family resemblances to each other.
The other Wittgenstinian analogy that's relevant here is that language is like a toolbox. This fits in quite nicely with the family resemblance discussion, too: what is the property shared by all tools? To quote Wittgenstein's parody of the attempt to provide such a property:
Also, Wittgenstein's treatment of rules is quite a bit more radical than you state it here, because it's framed as a critique of the notion of rule-following: the idea that rules "guide" the behavior of people. This is probably the part of Wittgenstein that's the most relevant to computer science, and in particular, to AI (classic AI fundamentally sees intelligence as rule-following). Alas, I haven't reviewed these parts in a while.
It's actually controversial to what extent Wittgenstein repudiated the Tractatus. More generally, the Tractatuts might well be the book that Wittgenstein's readers most disagree about. Wittgenstein always insisted that the philosophers who most admired the Tractatus completely missed the point behind it. There's certainly a shared theme between it an the Investigations: philosophy is a kind of confusion that comes up when philosophers fail to understand the limits of language. In the Investigations, the critique of philosophers' abuse of language takes the form of an attack on the classical theory of categories (the one that the idea of family resemblances is opposed to). In the Tractatus, on the other hand, the critique is based on the extremely obscure idea that there are things that language "shows" without "saying"--an idea that the book is (arguably) supposed to "show" rather than say...
Plenty of philosophers would disagree with you. I'll mention the late Wittgenstein as an example and leave it there.
But what I meant to single out is not programming languages, but rather, data modeling; i.e., the use of computer programs to reason about the world.
However, I still think that there's a programming language philosophical difference of the sort you're interested in here, though not between OOP/relational, but rather, between imperative/functional (or more generally, imperative/declarative). Functional in this regard sounds very much like your characterization of the relational model right there--but I'd need to better unpack the very succinct point you're making here before I could comment more intelligently.