cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [UPDATE] Scheme/Cocoon progress - initial benchmarks show good speed!
Date Mon, 21 Jan 2002 08:02:54 GMT
On Sat, 19 Jan 2002 10:38:05 +0100, Stefano Mazzocchi <stefano@apache.org> wrote:

> Ovidiu Predescu wrote:
> 
> > Other than this everything else in the infrastructure is the same
> > between the two implementations. The difference is of course, the way
> > the pipelines are setup: in the compiled case each pipeline is setup
> > by compiled code, running as fast as possible, while in the Scheme
> > case, the pipeline setup is driven by the Scheme sitemap function,
> > which should be slower than the compiled version.
> 
> I'm curious about the trends. 
> 
> A while ago I thought that an interpreted sitemap could be as fast (or
> even faster) than a compiled one on hotspot JVM.
> 
> What JVM are you using? have you seen any difference in performance
> trends between the two (the compiled sitemap should be faster at first,
> then converging after a few thousands calls)

I'm running both IBM's 1.3.0 and Sun's 1.3.1. While running on the
same JVM, I don't see much of a difference in how the application
performs in time. At startup both implementations are slower, but they
improve quickly. I didn't spend much time investigating this aspect,
so I cannot comment much on it.

> > For the flow language, I was thinking to name it JWebFlow. I
> > originally thought of JavaFlow, or WebFlow, but they are both taken by
> > some other projects/commercial companies.
> >
> > Any better ideas on a good name for the flow language? I'd like to
> > hear your comments on this one.
> 
> Hmmm, I question if we need to name it.

I think we do need a name for it. I explain this below.

> I mean: cocoon has the sitemap language, but we don't call it XMap or
> XPL (extensible pipelining language) or equivalent. We simply say
> 'sitemap' and everybody understands.

Right. The fact that we don't name it explicitly, doesn't mean the
sitemap is not a language. The implicit name for it is "Cocoon
sitemap", probably that's why nobody came up with another one.

> Now, my personal suggestion is to avoid calling the language something
> but call the flow scripts simply 'flowmaps'.
> 
> As we then say 'sitemap markup' we will say 'flowmap language'.
> 
> My impression is that naming the language will give users the impression
> they have to learn another programming language (yet another!) in order
> to run Cocoon and get something out of it.
> 
> Hey, this is *exactly* what happens for the sitemap, but people are
> *much* less scared away from markup because I think the problem is with
> syntax, not with semantics.
> 
> that is the reason why a scheme version of the sitemap or flowmap will
> scare the crap out of almost every user we already have!

Yes, unfortunately I have to agree with you here. People don't get too
excited when they see a language with apparently little, to no syntax
:-/

> so, java doesn't scare people away because it uses the good-old C
> syntax. javascript same thing.
> 
> Now you come up with JWebFlow... ok, the user thinks: has a J on it, so
> it must be similar to java, and that's good, but then what?
> 
> On the other hand, the docs say: the sitemap defines the resources of
> your site and the flowmaps define the flow and interaction between them.
> 
> What could be easier and more elegant than that?
> 
> so the user looks at examples and find out that the sitemap is written
> using the XML syntax (and he'll find similar to the httpd.conf or
> server.xml files and be pleased) and the flowmaps are writting using a
> javascript-like syntax, cool, that's how he would have done it in his
> dreams.
> 
> But if you tell him: look, in order to write your flowmaps, you have to
> learn JWebFlow... oh, shit, no, no, I have a short deadline and I'm
> already mixing java and PHP in my site, no please, no more languages.
> 
> See what I mean?

Yep, I understand the rationale behind your point of view.

However the situation is very different between the sitemap language
and the flowmap language. The sitemap is a small "little language" for
describing processing. [Note that "little language" is an actual term
in computing, and refers to domain specific languages.] Traditionally
people don't give names to such languages, unless they evolve them
outside the context of the project they were initially used. This is
fine usually, as you, as the developer, are concerned more about the
language's functionality rather than evolving it outside your
project. The risk however, and you touched on it briefly, is that
people trying to use your project will perceive the language as
proprietary. [The "proprietary" term is related to whether the
language is unique to your project or not, not to whether the
source-code of the language's implementation is open-source or not.]

On the other hand, if you reuse some existing language in your
project, you eliminate part of the risk of being perceived as
proprietary. So from a pragmatic point of view it's good to reuse as
much as you can, and invent new little languages only when
necessary. Although there's now a large belief that every software
project defines many little languages in its implementation. Not all
of them have names, and perhaps the implementor is not even aware he's
implementing a little language.

[Related to little languages is the belief that a good programming
language should make the task of creating little languages very
simple. Incidentally, Scheme and Lisp-like languages, are very good at
this with their very powerful macro system, the ability to represent
programs as data, and interpret this data as a program, and access to
the runtime evaluator. Other languages however, like Perl and Python,
evolved more recently with lots of features in the ability to define
little languages. In such languages, you can easily define your own
little language with some careful thought and little work, which
describes the tasks you want in higher level concepts, as opposed to
the low level abstractions of the programming language, whatever that
is.]

Now let's go back to the sitemap and flowmap languages we currently
use or we'll use in Cocoon. I believe our users will benefit a lot
more if we identify them as separate language, rather than hide them
underneath Cocoon' shell.

It's better if other systems or software projects adopt these
languages, and refer to them through their proper names. This will
make these languages less proprietary, and easier for people to accept
them, if they encountered them in other projects. But for this to
happen, these languages have to have names of their own, and not be
referred to as "Cocoon's sitemap" or "Cocoon's flowmap" languages,
which makes them tied to Cocoon.

To give you an example from the Cocoon world, look for example at
XSP. The fact that it was recognized earlier in Cocoon's lifetime as a
separate language, made it adopted by AxKit. I would say this was a
very good thing, the first step towards conquering the world ;-). We
should try to do the same thing with other parts of Cocoon, not only
XSP. That's exactly the reason I'm trying to come up with a name for
the "flowmap language". I believe the concepts behind it are much too
powerful for it to be just a little language for Cocoon. For Cocoon to
be successful in the long run, it's important to have its ideas
adopted by other projects as well.


Best regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message