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 Tue, 22 Jan 2002 19:28:32 GMT
On Mon, 21 Jan 2002 13:11:35 +0100, Stefano Mazzocchi <stefano@apache.org> wrote:

> > [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.]
> 
> hey, careful here: while I agree that this might be good (what is the
> XML model is not a way to build your own markup vocabularies and
> semantics?) I also perceive the danger or Flexibility Syndrome that such
> 'do it yourself' languages give you.
> 
> If you make the contracts to floppy, they bend when you put too much
> pressure on them.
> 
> One for all: C++ operator overloading!

A little language is usually specialized for a very particular
purpose, and a programmer designs it so that he/she can deal with
higher level of abstractions than objects, methods, functions etc. in
the host language in which he implements the little language. Examples
of little languages range from simple configuration files, to the
languages used by awk and sed to do text processing. Since the
programmer designs the language for a very particular scope, he is
free to add new language constructs as he pleases, the flexibility is
total. You're also free to adapt the little language you've created as
the needs change.

Little languages are used since the beginning of programming to
describe specialized tasks. What I was referring to above was the
ability to describe and implement little languages in a simple way in
a host language like Scheme.

Check out this paper to read more on little languages implemented in
languages like Scheme:

http://www.ai.mit.edu/~shivers/ll.ps

> > 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.
> 
> Here is where I don't find myself resonating with your view.
> 
> If I were to choose between abstracting the languages so that they were
> more portable and make them more usable even if this means making them
> cocoon-aware, I would choose the second one.
> 
> I see your point, but I think it's theory: in practice, unless
> standardized by the W3C or the JCP, it's very hard that some technology
> invented in Apache will get the 'language' status and become a contract
> between different implementations (look at XSP, for example)

You may be right, but still I wouldn't discount the power of the
Foundation in pushing through some of these things.

However I'm not thinking that far, at JCP or W3C standardization, I
think it's overkill at this stage, and even later. I'd seek more
exposure in the developer community to the concepts promoted by Cocoon
first, and let things flow by themselves. If the ideas are right and
solutions easy to build, the standardization doesn't matter. As a side
note, Java is not standardized, yet is widely used.

> > 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.
> 
> Ok, I agree with your view of software dynamics, but I don't think it
> would be any *better* if other projects start building 'cocoon clones'
> with other languages, because that would place even more rigidity on the
> contracts and we are not *that* stable and we are not a recommandation
> entity like W3C or JCP (and don't want to become one!)

I think this is OK if other projects start cloning Cocoon, what's
wrong with that? It only reinforces the ideas promoted by Cocoon.

And again I don't seek to have yet another language become a standard
or something even remotely similar. I just think we need to expose the
ideas to the wider community, and I believe the best way to do this is
to have the concepts properly named so people can refer to them.

> > We should try to do the same thing with other parts of Cocoon, not
> > only XSP.
> 
> Knowing how XSP technology has been 'stagnating' for the last 18 months
> (yes, I'm partially responsible for this, I admit!), I don't think we
> are big enough to do what you propose.
> 
> This is why I would *not* be happy if other projects start to clone our
> contracts and want to control their further development: I don't think
> we are solid enough to do this and might tear the user community apart
> and provide forks. (the fact that AxKit uses XSP is simply to avoid
> reinventing the wheel: you can't make them interoperate so they are not
> the same stuff!)

I don't think if we have other projects implementing concepts similar
with ours, they'll want to control our own development. Usually when
another implementation comes on the scene with similar concepts, it
just forks at some point, and new ideas start flowing back and forth
between the projects.

> I have the *strong* impression that if other projects start to 'clone'
> us for their use in other languages, the net result will be more
> visibility, but too much for what we can currently handle!

Maybe, but I don't think it'll be that bad.

> Cocoon is a big-time R&D project: we are inventing, not implementing.
> This requires time, patience and lack of pressure. If you turn your R&D
> effort into a solid contract (by giving a name to it!), people will
> start asking for 'stability of that contract' and the evolution will be
> slowed down, or you'll be foced to fork.
> 
> In not saying that this will never happen, but there is proper timing
> for everything and I think *this* is not a good time for making the
> sitemap and the flowmap a contract shared by different implementations,
> because that will very likely tear them apart, along with the user
> communities.

You say it as if there's already another implementation doing similar
things ;-) Not so, at least to my knowledge.

> > 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.
> 
> Key works: 'long run'.
> 
> I'm not saying that this will not happen, but I'm saying that we should
> make it as hard as possible for people to clone Cocoon and rip out
> contracts until we have the ability to 'fight' to keep those contracts
> solid and we have a position where we have clear indication on how to
> evolve and influence them.
> 
> For now, my opinion is: let's focus on development. Marketing has to
> follow that.

Yep, this is what we do already. But we need to keep an eye opened to
what's happening outside, and sell our work as well.

Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.rgv.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