| Charles Hottel 2007-03-14, 9:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:55p388F25hik9U1@mid.individual.net...
> Many people working in COBOL on both mainframe and Client/Server systems
> deal with queries against relational data every day.
>
> Over the years we have become adept with it and can usually get it to do
> whatever we want. Most of us are satisfied we have this particular base
> covered.
>
> But, there are severe limitations in the "imperative programming" approach
> as implemented by COBOL and other languages where we embed SQL.
>
> If you are interested in where SQL is going, WHY the current approaches
> will not be suitable for emerging architecture, and getting some
> straightforward conceptual information from the horse's mouth, you may
> find this video interview of interest..
>
> http://wm.microsoft.com/ms/msdn/vis...Anders_0001.wmv
>
>
> Functional programming represents the extension of the OO paradigm into
> the next dimension. The interview with Anders Hejlstrom (who invented C#,
> among other impressive credentials) is in plain English, and most
> programmers from any background will be able to follow it.
>
> (If you at least understand OO terminology it is helpful, but not
> essential. There are a number of references to "IL"; this is "Intermediate
> Language" and, for the purposes of this discussion, can be considered as
> you would "machine code")
>
> I have stopped using the "embedded SQL" approach with cursors and
> seqential processing for some months now (mainly since I moved to C#,
> where the alternatives are preferred and actually easier to implement...)
> and operate instead on datasets, result sets, data and table adapters. I
> did this originally because it meant less connect time and allowed
> connections to databases to be shared and pooled in a much better way.
> (Also, queries operate much better when they are directed at in-memory
> objects than when they are directed at external disk files). After viewing
> the above interview a couple of times I am now understanding why it is
> important to break away from embedded SQL.
>
> This is NOT the end of SQL!! (If you haven't already, start learning it...
> :-)) It is the end of "embedded SQL" as we currently understand it...
>
> Data that can be in any format, from any source, is what the future "SQL"
> must deal with, and it must be capable of dealing with it concurrently
> across multiple cores.
>
> Can it be done? Hejlstrom thinks it can.
>
> I'd be interested to hear what people here think.
>
> Pete.
>
>
>
I found it very interesting. Their enthusiasm was catching. I read the
book "The Little LISPer" a very long time ago (sometime in the mid 1970s I
think) so I am not totally unfamiliar with functional programming and lambda
expressions. I have a book on Scheme that I have not read yet and a whole
shelf of AI books I have not got to yet. Anyway I thought that long ago
reading was not a loss after all. I remember getting up to a FunctionMaker
function that could create new functions. After that it got so highly
recursive I could not follow as I had not a LISP interpreter.
Back to the video. It sounded similiar to a just-in-time compiler that
creates expression trees and can concatenate them and do other manipilations
on them. The expression trees are represented as an object and the program
deals with a reference to that object. Then there would be back-end programs
that procees the expression trees and convert them to whatever you want,
XML, SQL, in-memory objects, IL etc. I guess there would be a separate
backend for each thing. It can also break the processing up into multiple
concurrent processes/tasks/thread, which is becoming more important with
multiple processors.
I can see how this might work on a single computer but it is less clear how
it would work in client server applications over the internet. As far as I
know C# only runs on PCs with MS Windows. I would not hold my breath
waiting for it to covert the expression tree to java byte-code. How can it
know how many processors are avaiable on a remote computer? Also the
operating system on the remote computer controlls the mult-processing. Will
it support all the favors of SQL? Will you be able to send a query to a
remote computer? I don't know, just some questions that spring to my mind.
I would like it better if I could use C# on any computer under any operating
system. I am sure it is possible to do that but I do not think Microsoft is
interested in it running anywhere except under Windows.
<<below is off-topic>>
I would like to learn C# sometime. I am concentrating on Java because of
work but I fear it may be all in vain. I told my project leader that I felt
left out and he said "well we all do". If he is to be believed our only
input is to the specification process and the development will all be done
by contractors. I do not know who will maintain it. I am an odd duck as
almost all programmers here are contractors and most all government people
are something other than programmers. I am a government programmer. I do
not know if I would be involved in maintaining the new system or what.
However our system will be done last and the next to last is scheduled now
for production sometime in 2011, and they are already talking of that
slipping. As more and more stuff goes into production I see more and more
maintainence problems listed on the w ly systems availability report.
There was an inch thick specification on his desk that he was reviewing and
inside were a lot of still incomplete pages. The cover said it was number
three of 23 such reports. My mind boggles. I may retire in 2014 without our
stuff ever being completed and without ever using java. This happened
before when I took two classes in C++ and they later dropped that approach.
|