Thursday, May 20, 2004 - Posts
Taken out today:
Cubavera
# of referenced posts by category: Blogging: 4; Development: 1; Other: 3; SQL: 3; WILY: 1
Line of the day:
So that's two fundamental shifts on the radar: the end of exponential CPU
performance increases, and a possible rule-of-thumb-destroying improvement
in the response time of your mass persistent storage. Exciting times...
Post of the day: As Beta 2 approaches...
Ye-ha, I'm writing This by hand on a Tablet PC and posting with Visual
Blogger 2004.
So far, So groovy! watch out Tech ED, here we Come
Just in time for TechEd, I have posted an article about using YukonSQL Server 2005 T-SQL, the Date data type and FOR XML EXPLICIT to generate an amortization schedule.
The other day I asked cyberspace what interesting yet practical mathematical problems they had written programs for. The answers varied widely, but one that reminded me of my own experiences was generate an amortization schedule. You would use such a schedule to show the progression of some significant loan where periodic interest is charged and payments are made. A common use of an amortization schedule is a mortgage -- a loan commonly associate with the purchase of real estate like your house. The math for such a schedule itself is fairly easy and the programming involved is trival.
Unless you decide you want to write it in T-SQL, that is.
This may resurface in the future as a SQLJunkies feature article, but I wanted to get this version off to you now.
Your comments welcomed, of course.
Or a Time.
I'm talking these data types in YukonSQL Server 2005, of course.
I am sad to remind my faithful readers of something I hope they already knew: The Date and Time CLR-based types have been cut from SQL Server 2005 after β1. I say remind because these deletions were mentioned long ago according to the PM team. I missed that, I guess. I wasn't aware of that change until after I had already invested some time in writing a post extolling their virtue.
These additions immediately struck me as being rather useful: there really are times when you want one or the other, but not both. Neither struck me as particularly hard to use, either. But I guess somebody saw it the other way. And they said so loudly enough.
I'm interested in how you feel about this. Was this the right thing to do? Does it matter much to you? Why or why not?
These aren't strictly rhetorical questions, though. Yes, the toothpaste may be out of the tube. But I think the product team both needs and wants to hear from you -- their customers -- how you feel about it. Lets not let a few voices speak for all of us here.
I'm generating ideas for my next speech, which is "organize your speech." One in particular seems to have the highest gravity: "You really aren't listening to me."
In at fairly low level, this isn't that difficult or dangerous. It's simply making, then explaining, a comparison of how we as humans encoding, transmit and decode words to communicate desired action with how we the same task with people. My goal is simple: to demonstrate the tactics we choose when coding might be used to the organize speeches. My thesis is also simple: you aren't really listening to me because you not going to decode what I am because of how I encoded and transmitted it. However, there are three techniques that apply
- Don't abstract, decompose
- Encode at the most atomic level
- Pick the simplest encoding possible
I have no doubt that these methods work.
But is this potentially poisonous. I'll be stuck with two paradoxes going forward. The first is that this an indirect assault on the purpose of ToastMasters. These are methods for become better communicators, but not better speakers. A good speaker, at least as far as I'm concerned, relies on the abstraction that this method tells you to abandon. Truly great speakers don't just communicate facts, they share visions. That's impossible if my thesis is correct, but we know it happens, so my thesis must be wrong. But we know my that thesis is right in the physical world.
I'm also saying that object-oriented programming -- which I firmly believe is -- in an ineffective way to communicate with the computer. The same reasons that I can truly express myself to the computer are the same reasons I cannot truly express myself to another person. We can communicate facts, we cannot truly share vision.
I see the ghost of the protagonist character Zen and the Art of Motorcycle Maintenance silently telling me not to do this, but the only way I can evict my personal Phaedrus is to do exactly that.