Re: snakes and ladders

[emilbarton]

A troll is not something one can decide to become, it is a social function, and if you suffer from embodying this function, you should become aware of its natural necessity: without troll there would be no mob and thence no fun.

So rejoice: it's not your fault. Accept: Troll pride!

On the level of programming, I think that you could perhaps maintain a page somewhere on the web, where people could find an example of what your code does so anyone could understand your lament without having to scan the Perl monks site for older messages (with dead links). But they told you already...

Finally I can only insist on keeping indulgent for all the professional programmers who manifest their anger or their superiority at your imaginativeness: you might well be a misunderstood genius. Personnally I have found a new information paradigm that would change the face of the world... Unfortunately I'm not sure, it could simply be working, without being too stupid nor too useful, nor too clever either, and it's really badly written.

Indulgence is required also because of the benefits you can draw from the situation: don't forget that social welfare is often forbidden to your employed contradictors: think social! In many countries, trollness can ensure a monthly rent that would at least, render life feasible. You see: there's always light! Do as I say, and youl'll come to appreciate your condition: Troll solidarity!

[Logicus]

Imho, one shouldn't have to be a genius to receive common courtesy... anyhoo...

If you want I'll give you the complete sourcecode to my forum system, it's too slow for a big audience (unless you happen to have access to big iron...) but I'm hoping to fix that issue with this compiler.

I'm also hoping to keep 100% compatibility with the aXML system declaration and presentation markup docs, and as an ambition I'm hoping to compile them into a well optimised PSGI app.

I would be interested in seeing your heretical code, I'm not bothered at all by how good the implementation is, or how fast it is as long as it works correctly since faster & neater solutions can come later if the idea behind it is good and worth developing.

peace.

[Your Mother]

You could probably get a huge performance gain without changing any code—if it’s presently well behaved and scoped—just by going persistent with running it. This is mostly how everyone does it and why understanding prior art is so important and will save you much more time than it costs to learn. Template::Toolkit and Catalyst are both fairly slow for example. Catalyst is all but useless run as CGI and TT2 compiles and caches itself to improve performance and only resorts to recompiling from the original templates when they have changed. Even the check interval for changes is tunable.

Run any one of your CGIs like so and visit it at port 8080 on whatever host–

starman --listen :8080 -MPlack::App::WrapCGI \
  -e 'Plack::App::WrapCGI->new( script => "your.cgi" )'

• Plack
• Starman
• CGI::Compile
• Plack::App::WrapCGI
• Plack::Builder
• Plack::App::CGIBin

[Jenda]

IMNSHO, one should not claim to be a genius even if he happens to be (and sorry I am pretty sure you are not) and if he/she does, he/she should expect his/her geniality to be put to a test. You came here preaching your uber-genial miracle without even being able to explain what the heck it is. What did you expect?

[emilbarton]

Thank you for your answer. My code is not yet to be shown to anyone (will it ever be?) but I'll work on it, I'll try to improve functions commonly expected in the field (data management) and one day, as soon as I feel confident enough, I'll ask for evaluation.

I may seem a little sleepy, but I did not understand yet the ins and outs of your work. Is your system comparable to CMS, as Drupal or Moodle? What is your intention? Are there new kinds of web interactions that you wouldn't like to disclose yet (making thus dialog difficult)? Sorry if I'm asking you to repeat (in few words) things already said but it's not always clear information that one digs out from old threads.

[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.