by Michael S. Kaplan, published on 2007/11/26 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/11/26/6527833.aspx
From the introduction to The More Than Complete Hitchhiker's Guide:
The story grew in the most convoluted way, as many people will be surprised to learn. Writing episodically [as for a radio program - MSK] meant that when I finish one episode I had no idea what the next one would contain. When, in the twists and turns of the plot, some event suddenly seemed to illuminate things that had gone before, I was as surprised as anyone else.
I think that the BBC's attitude toward the show while it was in production was very similar to that which Macbeth had toward murdering people -- initial doubts, followed by cautious enthusiasm and then greater and greater alarm at the sheer scale of the undertaking and still no end in sight....
....
In the fall of 1979, the first Hitchhiker book was published in England, called The Hitchhiker's Guide to the Galaxy, It was a substantially expanded version of the first four episodes of the radio series, in which some of the characters behaved in entirely different ways and others behaved in exactly the same ways but for entirely different reasons, which amounts to the same thing but saves rewriting the dialogue.
The first part of this quote is quite relevant to the blog you are currently reading.
The second part of this quote, however, has nothing to do with this blog, but more than a little bit to do with this Blog, if you follow my meaning. I will talk about that another day, and thus that other unrelated point about this Blog will be covered not in this blog but in another blog. But it literally came right after the first bit so I included it anyway because I think it reads good.
Sometimes a post will inspire another post so it will include the link.
Other times I will write a post, realize the connection to the earlier one afterward but before posting, and I will add the link.
From your point of view (as the reader), the effect is the same, though for me as the writer the first method is easier since it saves me editing the second post after the fact. Which is what the third bit in the quotes is there for.
If you are a regular reader then you may concur with all of this. Or you may not. I honestly don't give a fig, and not just because I have no figs, but because I don't write for the kind of people who would tend to not agree with how I write since it is not really something anyone knows about other than reading what I write about it. Disagreeing with it thus makes one simply disagreeable, and while I support everyone's right to be wrong, I do it in a more passive way, and I certainly don't write for them in particular.
A hazard of reading Douglas Adams is that you find yourself writing a bit like him, only less entertaining. Sorry about that!
Anyway, on to the topic of this blog....
I have had many occasions to point out the problems with SQLCLR, that whole notion of the CLR within SQL Server, in the past. Like in posts such as String.Compare is for sissies (not for people who want SQLCLR consistency) and Not all in sync quite yet (aka SQL and the CLR and Windows and .NET), where I point out that the fact that SQL and the CLR both have very firmly embedded architectural notions of how collation should work that do not match (more or less just about all of them) and at time can openly disagree (e.g. a Windows-only culture on Vista inside of a SQL Server stored procedure).
And I have also talked about the biggest problem in deciding about how best to be consistent or compatible really depends on what one is trying to be consistent with and what one is trying to be compatible with. As I pointed out in Compatibility is inconsistent; consistency is not compatible..., defining this is a crucial first step.
If you don't have this defined and later someone has to try to describe the behavior (as documentation writers and support personnel are often required to do), there is no easy consistent way to define why things behave as they do.
So they do their best to make Microsoft not look dumb, when in a way we kind of were, since we did not plan ahead enough in the design to know how this should go.
Hell, I think we just released LINQ and with not much more in the way available that explains how any of this works. And that makes good engineering look pretty doubleplusungood, in retrospect -- whether it is true or not.
But in the midst of stewing about this, and after eating what can only be described as entirely too much five-star turkey panang curry left over from Thanksgiving, I suddenly found myself thinking about the static versions of CompareStringW and LCMapStringW that Jet Red >= 4.0 and and SQL Server >= 7.0 both use that I have written about in that weird unofficial undocumented sense in a past life and Lee Woods wrote about more officially up on TechNet in the article entitled Microsoft Jet 4.0 Sorting APIs: DBCompareStringW and DBLCMapStringW.
And then add a helping of the explanation I gave for synthetic or Windows-only cultures earlier this very month in Predictably (in retrospect), aka Where Wild^H^H^Hindows-Only Things Are, aka SHORT [on ]TIME for a LONG TIME.
And suddenly a long-term solution that would let the CLR within SQL Server do its work with SQL Server semantics became more obvious -- it could use that whole synthetic model for collation and have the CLR hosted by SQL Server depend on the SQL Server doing the hosting. So that queries and code would get the same results!
What better thing to be consistent with? What better thing to be compatible with?
Suddenly the workaround for a data management issue (the original reasons for Windows-only cultures, as I discussed previously), becomes a potential compelling architectural solution for the aforementioned SQLCLR compatibility issues, LINQ/CLR collation inconsistencies, and maybe even a more sensible/scalable solution for Mono than the one I naively suggested over two years ago in My own personal thoughts about collation in the Mono project.
Now would it be as easy to do as I imply here? Of course not. But it does allow the problem to be a tractable one, which is decidedly not what it is, today (which is why we keep shipping it, msybe?).
When yesterday's workaround becomes tomorrow's potential solution to problems, you know you were doing something right.... :-)
This post brought to you by 〇 (U+3007, a.k.a. IDEOGRAPHIC NUMBER ZERO)
# John Cowan on 26 Nov 2007 12:21 PM:
I think you do have the relevant kind of "fig", which is performed by making a fist with the thumb sticking out between the index and middle fingers. It's equivalent to "Up yours".
So saying "I don't give a fig" means "I can't even be bothered to make an insulting gesture about it."
# Michael S. Kaplan on 26 Nov 2007 1:45 PM:
I suppose I was unaware of that bit of info -- I mean it like the fruit. Like I said, I support their right to be wrong....
# Zooba on 27 Nov 2007 2:03 AM:
"A hazard of reading Douglas Adams is that you find yourself writing a bit like him, only less entertaining."
I find I do the same thing after reading Terry Pratchett. And yes, I am less entertaining than he is. Nobody can do what those two (Adams & Pratchett) can, which is how they become rich and famous.
# Shirley Humphrey on 25 Sep 2008 11:17 AM:
I thought it was humorous, I laughed several times though it. At least I was'nt bored. LOL
referenced by
2008/10/16 Shine a Little [Silver]Light
2008/09/25 You're not my type if you have no culture
2008/05/27 SQL and the CLR? (2008 edition!)