Re: The Lambda lambada...Why embedded SQL is becoming irrelevant and why you should start looking at functional programming.

Thanks for your comments, Charles...

Some discussion below...


"Charles Hottel" <chottel@xxxxxxxxxxxxx> wrote in message
news:N50Kh.127543$_73.11354@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:55p388F25hik9U1@xxxxxxxxxxxxxxxxxxxxx
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/visualcsharp/anders_2007_01/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.

C# is tied to the DotNET framework, not to Windows. Vista comes with DotNET
version 3 installed and it is likely that future MS OSes will also lever
this framework.

I believe there is current development (outside MS) to implement DotNET on
non-MS platforms. Mono is an Open Source project that is doing this...but,
it is a work still in progress...

http://www.mono-project.com/GtkSharp

In the same way that the DotNET framework levels the playing field regarding
which language you use for development, by JITing the IL from any compliant
language compiler into CLR, all that is required to run on ANY platform is a
JIT interpreter and a CLR implementation for that platform.

Currently implementations for both Linux and Unix are under way.

http://dev.mainsoft.com/Default.aspx?tabid=45&gclid=CJqH4rfD9YoCFQM8YQodqGSYjg

It will therefore be possible to develop code in any of the DotNET compliant
compilers (including COBOL, if you have deep pockets...), and run it on ANY
platform.

As C# is free, easy to learn and use, has HUGE support from MS, and is fun
to develop and debug with, it is a logical choice for DotNET development.


I would not hold my breath waiting for it to covert the expression tree to
java byte-code.

I doesn't need to do that; it is already in "byte code" as IL.

How can it know how many processors are avaiable on a remote computer?

It doesn't need to. The "pipelined" code will use as many as are available
(including one only...)


Also the operating system on the remote computer controlls the
mult-processing.

Yes, but it responds to requests from applications... :-)

Will it support all the favors of SQL?

If Lambdas are used, it won't need to. They are checked at compile time for
syntax. Whatever flavour you use for your expression will be checked long
before it ever gets to run. (I perceive this as similar to the OO Repository
which enables compile time compliance checking for referenced objects.)


Will you be able to send a query to a remote computer?

As you can right now, and given that DotNET incorporates support for DCOM
and the newer "remote object", SOAP (in it's latest form, it is much more
powerful), and Web Services technologies, the answer has to be, "Yes".


I don't know, just some questions that spring to my mind.

And good questions too... :-)


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.


Absolutely not true. Like many people who suffer from "tall poppy syndrome",
you may be letting your distrust of MS blind you to what is actually
happening, and demonstrably true. The source for DotNET has been made
publicly available by MS since it was first developed. The vision is exactly
what you described above: "...use C# on any computer under any operating
system." (It applies to VB.NET as well :-)). And, remember, MicroSoft make
the language and the IDE and their support through MSDN available for FREE.
I honestly don't believe they are as wicked and evil as they are painted,
but I don't think they are Saints, either... :-)


<<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 weekly 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.

I have encountered similar stuff when I worked for a Hospital Board many
years ago (prior to 1975). Systems were painstakingly specced and volumes of
documentation produced. There was so much that no-one could possibly read it
all. On a number of occasions we implemented processes and then found they
were incompatible with other processes and had to be re-written. The
interface incompatibilities were in the documentation (with design specs for
overcoming them) but no-one had the time or inclination to read the entire
spec before starting work...

The solution is to break work into manageable chunks and do a phased,
iterative, implementation. I like RAD, but that is a whole other ball game
:-)

As for learning Java, that really can't be a waste of time. Whether you use
it at your current employment or you use it elsewhere, it is a useful string
to your bow.

You may find that even after you retire you want to "keep your hand in".
There are applications that present themselves every day and "hobby
programming" is fun and even, sometimes, profitable. For this both Java and
C# are useful.

C# is fun, but you don't want to allocate all of your leisure time to
learning new computer programming languages... :-)

The problem with working for Government is that there is little empowerment.
It is therefore very hard to get things changed. It seems to me you are
doing the best you can in the environment you are in.

Don't worry about it.

Pete.


.

Relevant Pages

  • Re: Searching OO Associations with RDBMS Persistence Models
    ... I agree those pesky DB language do tend to thrash a lot. ... Both SQL and C++ can be extended with custom data types. ... The RDB has no idea that this is the ... The programming language is also always a detail. ...
    (comp.object)
  • Re: UDF returns table to feed a call back to itself ... how? (cross post)
    ... using SQL has his first ever programming language. ... Ever read Weinberg's PSYCHOLOGY OF COMUTER PROGRAMMING? ... I don't advocate scrubbing data with SQL. ...
    (microsoft.public.sqlserver.programming)
  • Re: DELETE rows from Table lists
    ... This is a sequential file model we used in tape systems in the 1950's -- ... hundred new SQL programmers in the next year. ... language a procedural language? ... How many years/months have your been programming in SQL? ...
    (microsoft.public.sqlserver.programming)
  • Re: Alternative to Dynamic SQL?
    ... know any of that because you're a entry level programmer using ORMs ... who hardly know sql. ... People want to be able to write their application in ONE programming ... language - at least the core of that application. ...
    (microsoft.public.sqlserver.programming)
  • Re: If you cant write Text2.Text = Text1.Text, then VB clone is no good
    ... Visual Basic was a development platform that utilized the BASIC language as ... DotNet, is the future, but it takes a while to get up to speed. ... Computer programming people might ridicule ...
    (comp.lang.basic.visual.misc)