xml-dev - RE: Various presentations, schema concepts, etc.

[johns@syscore.com (John F. Schlesinger)]

Matt wrote:
"One thing about declarative programming and functional programming is that
debugging is _hard_. Jumps are implicit, not explicit, and so tracing a path
through the code is non-trivial and extremely input dependant. Although I
look forward to the first XSLT gui debugger :-)"

I don't agree that debugging functional programs is hard. Actually, because
there are no side effects at all and any expression can be replaced with its
value, it is very easy to debug them. Functional programs tend to be made up
of lots of little blocks, each of which has an obvious function (hence the
name) and can be proved correct. The problem of debugging is to show that
the assembled functions actually implement the specification. If the
specification is in Z, by the way, a program in Haskell or ML will quite
often be nearly the same as its Z specification. On the other hand, if you
don't have a specification, debugging can be a challenge...

Yours,
John F Schlesinger
SysCore Solutions
212 619 5200 x 219
917 886 5895 Mobile

-----Original Message-----
From: owner-xml-dev@xml.org [mailto:owner-xml-dev@xml.org]On Behalf Of
Matt Sergeant
Sent: Monday, July 03, 2000 7:34 AM
To: Rick JELLIFFE
Cc: , , ,XML-Dev Mailing list
Subject: Re: Various presentations, schema concepts, etc.


On Mon, 3 Jul 2000, Rick JELLIFFE wrote:

> Matt Sergeant wrote:
>
> > I'm not convinced its really the next wave though - like
> > functional programming its just too hard to grok for non comp sci people
> > (and there are a lot of them in this field who are going to need to be
> > able to work with us).
>
> I am not so sure that functional programming is so bad: SQL is basically
> a functional language is it not?

I would have to disagree with that. SQL is a declarative language, like
XSLT: You specify what the results you want are, and don't worry about the
underlying implementation.

> I suspect that the problem with functional programming is that it
> changes the boundaries between what is hard and what is straightforward
> too much.  XSLT's approach of allowing extensions (cheating) on a small
> and targetted application domain seems to be pretty acceptable--it
> forces you to use a different tool to solve the problems which (the
> kinds of FP used in) XSLT is not great at.

Think of XSLT extension functions as akin to SQL's stored procedures.

> Dr John Reekie, who co-wrote the RISP SGML processor with me in the late
> 80s, later went on to study functional programming (graphical tools for
> DSP compilation) before ending up at UCB for TCL work. I remember his
> suggestion, after working with functional programming techiques (and
> liking them very much) was that  perhaps they require a too high level
> of abstraction for typical programmer (typically trained programmers?),
> compared to procedural code (we are used to assignment): he thought that
> mediating the functions through a GUI might make FP more attractive.
> But, of course, functional programming may find in the large and regular
> data structures of XML documents data which is well-suited to be treated
> as the input and output of functions. A new application area may cause a
> resurgence in uses of functional programming (in the same way that XML
> may cause a coarse-grained resurgence of data-flow architectures).

I guess we'll see about that. The people who like FP enough to use it
every day seem to be found only in academia. Real world programmers have
to use hacks and shortcuts to get their work done in the time given to
them.

One thing about declarative programming and functional programming is that
debugging is _hard_. Jumps are implicit, not explicit, and so tracing a
path through the code is non-trivial and extremely input
dependant. Although I look forward to the first XSLT gui debugger :-)

--
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************