Re^4: snakes and ladders

[Logicus]

Ok the best description I have come up with yet is that it's a general purpose extensible declarative markup syntax. It has been called yet another templating system, and you can do templating with it, and I guess that is probably going to be it's most typical use if anyone uses it at all. What I'm hoping to do is make it so that you can deploy very fast PSGI etc code by building aXML declaration files and compiling them with the compiler I'm trying to build.

Some practical reasons for it to exist are :

• Seperation of concerns
• Simplicity with power
• Ease of deployment
• Portability
• Rapid development
• Simple debugging
• Easy Maintenance
• Loose Coupling
• Threaded Multi Processing

Taking these one at a time:

Seperation of concerns

Code, markup and style should be seperate. CSS is a declarative language for specifying style attributes, but not how to actually render them for example. aXML is a declaritive language for specifying server actions, and does not itself say anything about how they are to be computed. The actual logic goes in separate plugin files.

Simplicity with power

The deceptively simple syntax of aXML allows for reasonably complex and expressive declarations to be built up from optimised primitives. When the compiler is built a system declared in aXML could I believe result in an optimised PSGI application being produced.

Ease of deployment

Generally an aXML programmer would simply create declarations using the existing plugins. It's possible to create complex systems with currently only minimal need to write any custom Perl code.

Portability

The syntax strongly promotes modular code and code reuse, such that once the code for a given directive command has been designed, if it's placed in the main plugin folder, it's available to all the documents using the system, instantly and completely dynamically. You could completely change the engine under the declarations for another one and the application would be unaffected as long as the replacement was 100% compatible with the standard. Thus systems built out of aXML declarations are completely decoupled from their compiler and operating system environment.

Rapid Development

Given the ability of the syntax to perform templating functions new systems can be setup in very short lengths of time. Once a declaration is built it can be reused in new projects.

Simple Debugging

Since the declarations are built out of reused plugin code blocks, if a declaration doesn't work it's very likely to be the declaration that is wrong and the simple syntax style makes it easy to spot errors.

Easy Maintenance

Having been through a nightmare of repeatedly having to refactor code which was not designed with clear seperation of concerns in mind, I know that maintainability is vitally important and must be considered from the beginning of the project. By separating the markup and declarations from the code which runs the site right from the get go, your making life easier later. It's also possible to use aXML declarations as an ORM such that your application would be unaffected should management decide to go with NoSQL after all. (You just update the plugin code, or drop a different plugin into it's place.)

Loose Coupling

The aXML declarations provide only an abstract description of the server actions, and do so in a modular way. The individual components are completely oblivious to each other and thus can be swapped and changed as required.

Threaded multi-processing

Now this is where it gets controversial, but I'm happy to go out on a limb and suggest aXML declaration based systems have advantages on a multi-processor threading system.

According to the Declarative Programming Wiki, QUOTE: Declarative programming has become of particular interest recently, as it may greatly simplify writing parallel programs.3 END-QUOTE.

The citation given for that : http://www.cse.unsw.edu.au/~pls/damp09/

I personally believe that the stucture of aXML will lend it self to a multi threaded approach, however I am not yet well enough versed in either perl or threading/forking application design to utilise that potential.

[emilbarton]

All right, I think I understand better now.

If you already have a valid declarative language of your own, why wouldn't you try to make a (Cpan) module to control the correctness of any such code?

Then people could test your compiler on an experimental site, discuss various versions and bring their help or even propose their own compilers.

Anyway you are right not to let you depressed by bitter criticism.

[Logicus]

My code is not yet CPAN ready, (nor production ready really) however I do have a forum system running on it which seems fast enough on a small $20 a month server. I would probably have real problems if a few hundred users tried to browse it at the same time on the current implementation lol.

As for code correctness, there is a very simple set of rules for tags and the rest is left upto the developer. There will be a very small number of built in tag names to access some standard primitives but after that the code would be application specific.

For instance 

<use><qd>action</></>   

would use 2 built in primitives (use&qd) to process the action named i
+n the query

where

<shop::cart::contents></>

would use &contents from a shop::cart package which deals with the DBI or your choice of ORM etc. The versions out there already don't support this but I have made a lot of progress since then in many directions and I'm hoping to start pulling it all together into a coherant form quite soon... it just depends how long this compiler takes to get going.

[emilbarton]

If you really apply Separation of concerns there should be at some point in the development, a moment in which you can extract some stable part of your code and begin to build the rest upon it. But my competence limit is reached. Best wishes anyway!