[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin wrote:
>
>....
>
> Didier replies:
> In procedural languages you say *how* to do things. In functional languages
> you say *what* you want. For instance, languages like Visual Basic are
> procedural language because you specify to the system a sequence of actions
> to perform, something like "display", "calculate", "store", "recall". In the
> case of functional language, you do not have to say "display" you specify
> what you want as final result. For instance by specifying a template. There
> are also other more subtle elements to consider but these two elements catch
> the essential spirit of procedural vs. functional or the opposition of "how"
> vs. "what". In one case you tell the system what kind of action to perform,
> in the other case you specify what you want as final result.
I'm going to suggest different terms and definitions.
Terms: declarative versus procedural. Declarative is "what you want".
Procedural is "how to do it."
But I do not think that the two are absolutes but rather a spectrum.
XSLT is *more* declarative than Python but not AS declarative as CSS.
(for instance in XSLT you must explicitly say to do the
"apply-templates" whereas CSS just "knows")
> Off course, Visual basic is a strange beast since you visually specify the
> visual end result by placing components in a form. And this could be
> considered as specifying "what" we want in terms of visual layout [1].
Yes, visual basic has a declarative screen layout strategy, whereas Java
has a procedural one.
Here are some examples. Here is a procedural way to download a file:
ftp ftp.somesite.com
> username: XXXX
> password: YYYY
> GET somefile.xml
Here is a declarative way:
ftp://ftp.sometsite.com
Here is a procedural way to make a phone call:
"Operator? Could you please see if there is a Jones in Smallville? Could
you please connect me to that person?"
Here's a declarative way:
223-555-2822
Now consider a SOAP message. You connect to the endpoint. That's like
the operator or FTP server. You send it a message (or invoke a method),
that's like the request for a file or phone connection.
It might seem that we could build a declarative layer on top of SOAP as
we did on top of FTP and the phone number system, but it isn't that
simple. The side effects of FTP fetching and phone calls are well
understood. The side effects of calling some random SOAP method is not
explicit to clients of that call. So you need to think about how often a
method is going to get called in processing a request, or in what order
methods are going to get called. So you need to think about the HOW
things get done, not just the WHAT gets done.
It isn't that REST allows you to move entirely into a declarative
universe. Some methods WILL have side effects and you can't invoke them
willy nilly. But REST says that barring a bug, GET will not have side
effects. Therefore you can safely build declarative systems on top of
GET. Examples of that include every web page in the world, Google,
Yahoo, etc. Nobody ever hesitates to add a page to Yahoo because doing a
GET on it will have bad side effects. The side-effect free GET method is
the basis of hyperlinking which is a declarative way of relating
information resources.
For instance, here is a declarative way of relating a purchase order to
a customer resource:
<po>
<customer
href="http://www.ourcustomerdatabase.com/ourcustomers/customerid"/>
...
</po>
Then to get from a purchase order to a customer then I can use the
declarative XPath expression:
document(/po/customer/@href)
This will allow any PO to refer to any customerID anywhere on "the web"
(more likely the organizations intranet or maybe that of partners).
The typical SOAP strategy would be more like:
<po>
<customer>0903426897432</customer>
...
</po>
Now to actually GO from the purchase order to the customer ID, you have
to do something like this:
someotherservice.someMethod(customerId)
That can't be done in XSLT/XPointer/XInclude so I guess we'll have to
add SOAP RPC features to all of those languages!
Note that there are many who say that I unfairly talk about SOAP RPC as
if it were the whole thing. But the situation *gets worse* if you avoid
the RPC subset of SOAP because you don't *even* have a standardized
concept of method, so you are even farther from interoperability. You
don't even have the procedural "someotherservice.somemethod(...)"
syntax.
Paul Prescod
|
