Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^7: Plack Middleware aXML

by Logicus
on Oct 20, 2011 at 20:43 UTC ( #932750=note: print w/replies, xml ) Need Help??

in reply to Re^6: Plack Middleware aXML
in thread Plack Middleware aXML

You looking at it with a bias that you seem unaware of, whilst I agree the above example is a very nice neat bit of masters Perl, it is beyond the understanding level of the target user base.

My plan is and always was to make good structure easy and implicit, such that cheap spaghetti brained code monkeys who find things like PHP to be a challenge to the upper level of their intellectual capacity, can produce well structured and reusable apps quicker and easier than they can using things like PHP.

If they then graduate onto the level of writing plugins good for them, if they then continue to grow as a programmer and learn enough to write masters Perl, good for them and good for Perl. Most of them will never attain that level, the vast majority will do exactly what they are doing now, cutting and pasting code with very little understanding of what they are actually doing or why the spaghetti messes they make are bad.

You can golf your code down as much as you like and marvel at how few keystrokes your using, but as soon as you use 'magic' symbolism in there, you've just lost most of the audience.

There is a reason why Master Perl programmers earn upwards of 60,000 a year; they are in short supply because most programmers are not smart enough to reach that level.

There is a very good reason why Larry is so keen on allowing for Baby perl to exist without being punished, it's because he knows that not only is today's baby perler potentially tommorrows master, but also that the distribution curve of IQ points in the population means that baby perlers will always outnumber masters by many to one, and failing to support them in favour of top end people capable of writing things like your example, is a surefire way to end up with a language only intellectuals like us can appreciate.

There will always be a 1 : 1 mapping of aXML code to perl code, because aXML is written in Perl. And the perl code will always be both more efficient and flexible, provided that the programmer has sufficient understanding of the language to use and debug it. For the same reasons that their will always be a 1 : 1 mapping of Perl code to C code, and a programmer capable of writing the Code in C will also gain in terms of efficiency and flexibility. Its as true to say that only aXML can parse aXML as it is to say that only Perl can parse Perl, and for the same reasons!

Another thing is that the example I gave was just to illustrate how the structure works, the system is not intended to be a replacement for the syntax of perl, but to be complimentary too it.

It would be interesting to see just how many lines of Perl you need to trigger the same functionality as this example:

<batchvalidate> <test rule="username_not_taken" username="<qd>username</qd>" > [mem ref="username_error"]1[/mem] </test> <success> [use]adduser[/use] <success> <failure> [use]signup[/use] </failure> </batchvalidate>

Where there can be multiple tests, and the example connects to the database, checks if the username exists in the users table, and then decides what to do based on the results.

I would suggest the equivalent Perl code, if given in it's entirety like your example would be something like this;

use Plack::Request; use DBI; use Conf; use Modern::Perl; my $env = shift; my $qd = $req->parameters->mixed; my $dbh = DBI->connect( $Conf::conf->{'dsn'}, $Conf::conf->{'dsn_username'}, $Conf::conf->{'dsn_password'} ) || die "Could not connect to database: $DBI::errstr"; my $sth = $dbh->prepare(qq@ SELECT count(1) FROM users WHERE username="$qd->{'username'}" @); $sth->execute; .... ....

Blah I can't even be bothered finishing this example, if you don't get the point I'm making then maybe you never will.

Replies are listed 'Best First'.
Re^8: Plack Middleware aXML
by chromatic (Archbishop) on Oct 20, 2011 at 21:24 UTC
    It would be interesting to see just how many lines of Perl you need to trigger the same functionality as this example.

    That's not a fair comparison, for several reasons:

    • SLOC isn't an interesting metric until you get to orders of magnitude difference
    • Comparing a framework to something at a different abstraction level is misleading
    • There's running Perl code behind the aXML example that looks much like the eventual Perl code someone would have to write anyway
    • SLOC isn't the only meaningful concern. Consider syntax checking or highlighting, or debugging, or testing. The Perl infrastructure and toolchain has quite a few advantages over aXML due to its maturity

    I'm not saying aXML lacks its advantages, but concision alone isn't such a meaningful metric.

    Also your example Perl 5 code has a security hole. (We've talked about this before.)

    Improve your skills with Modern Perl: the free book.

      not a fair comparison..

      It's difficult to find a fair comparison when we are talking about such different paradigms. I'm not trying to replace Perl's syntax, so much as wrap it in a container which makes it easier and quicker to assemble batches of complex imperative statements using a simple declarative syntax.


      Sometimes there is little difference, and sometimes you do get several orders of magnitude advantage. For instance on the old system there was a plugin called aJAXchat (I haven't got round to porting it to the new one yet), which allows for any page of any project to instantly include an ajax powered chatroom by simply adding this :


      The more abstract you get with the tags and their meanings the greater the advantage you gain. Some of the plugins are hundreds of lines of code, and can be accessed, and layered with the other plugins to create even greater complexity. I.E ;


      Now suddenly the chat room only appears if the debug flag is set... why you would want to do that is beyond me, but the principle is sound.

      Your right when you say that someone would have to write the Perl code anyway to give the tags their meanings, but once written that tag then becomes a reusable package which as I mentioned can be used in concert with all the other packages. Write once, use many.

      (loggedin) <aJAXchat>rooms/<qd>roomname</qd></aJAXchat> (/loggedin)

      >>syntax checking or highlighting, debugging, testing.

      When your confident, as I am, that the lower level of the system is bug free (especially the older version), then you find that the only place bugs exist is at the document level, and nearly always its because you've left out the / from the end tag or something silly like that. The very nature of the syntax and the way it reuses batches of pre-written and well tested code lends itself to coding with very few bugs. With that in mind, consider then that a lot of the testing and debugging tools needed for the full blown complexity of Perl are just not needed to check if an aXML document has the correct syntax.

      As for saying Perl has advantage over aXML due to maturity, that's still thinking of aXML as being some sort of rival or equal to perl, it isn't, it's just an abstraction layer which implements a higher order and makes for quick and easy construction of statements which require a lot less brain power to build and debug than the Perl code which powers it.

      security hole... yeh I remembered that when I was typing it but I was just like bleh, its only a silly little incomplete example anyway.

        Also it will be nice at some point when I have the time, to get down to writing an editor for it or extending something like Padre.

        I have some ideas in mind for instance


        The syntax highlighter (and checker) would not need to know anything about what the tags actually do, all it needs to understand is the bracket schema.

        Also, I had in mind the ability to run a tag in isolation so you can see what it returns, and possibly if the editor is smart enough it could add a + sign next to things like the <inc> tag so you can see the result of including the given path. I.E;


        Then when you click on the + sign the sub "inc" gets run, loads the file with the given path, and displays its results inline;

        here is the file you requested

        You could then edit the loaded file in place, and when you click the - the editor saves both files. and returns the display to how it looked at the start. This gives the advantage that you can be sure your path statement is correct, you can create and edit a new file by typing in the path and clicking the plus sign, and you don't need to worry about saving the files or having multiple windows or tabs open with different files to switch between them.

        The sub file can also contain another nested heirarchy of tags, including more statements to include, like russian dolls.

        When your building a new system you open the editor and start by typing :


        Then you give the editor a request so that the value of action is known, click the + and start writing that action, when your done with that action you give the editor another request and start writing the next action and so on.

        I will eventually get round to writing this, but I only have one pair of hands and right now I have significantly more important tasks to complete so I can get out of having to visit the jobcenter twice monthly to beg for my survival pittance.

Re^8: Plack Middleware aXML
by Jenda (Abbot) on Oct 20, 2011 at 23:41 UTC

    There's no way to reimplement your example as there's no way to understand what the heck is the magic incantation supposed to do. On the other hand if instead of aXML "plugins" you simply implemented the same number of functions I'm pretty sure you could call them by code that'd be about as long, if not shorter, as your aXML example.

    See ... you do not have to write all your code using the modules you got with Perl or downloaded from CPAN. You can write your own, more specialized and higher level modules and then ... instead of using Plack::Request and DBI directly, you just call the functions or methods from those modules.

    If instead of fiddling with the aXML engine and writing aXML plugins, you wrote prettymuch the same thing you've put into the plugins as a plain old module, you could write Perl code at exactly the same level of abstraction.

    And then the way to add the AJAX chat you boast about in your later post would be


    If you want a fair comparison at least for the simplistic "dump if debugging" example include in your SLOC the definitions of the debug and dump aXML plugins and then compare that with my code. Or compare your (debug)<dump>$env->{'psgix.session'}</dump>(/debug) with it's pure Perl counterpart debug { Dump($env->{'psgix.session'}) };.

    Enoch was right!
    Enjoy the last years of Rome.

      Look Jenda-dude, your not telling me anything I don't already know here, and comparing aXML with Perl itself is not a fair or valid comparison. I know I started it, but only as a means to try and introduce a new thing which works in a completely different way, by relating it to concepts of which your already aware.

      A fairer comparison perhaps would be comparing aXML with something like TT2, however once again this is comparing apples and oranges, since TT2 has a limited domain-specific language for controlling document layouts, where aXML has a simple an open ended syntax which by virtue of that fact tha t definition files are coded in perl, is turing complete and far more expressive.

      I understand that it's difficult to see what I'm saying clearly using only what I have typed up for reference because I'm struggling to find ways to effectively communicate the concept. That's not entirely my fault either because aXML is not like anything else that I have ever come across and the comparisons usually fail to clearly express the situation properly.

      aXML has no conditionals, variables, loops or operators, all it concerns itself with is abstract symbols and their correct processing order. From the very simple ruleset you can derive huge complexity in very neat, understandable and reusable code.

      Now sure, you could obfuscate the hell out of it...

      (j34) <hhrhe>gghheh</hhrhe> <fdkes>adalekaeka</fdkes> <asdj3> [sdf] <sdkjer>aksdjke</sdkjer> [/sdf] </asdj3> (/j34)

      The above represents a VALID aXML expression, which aXML can process, given a plugin set which corresponds to the symbols. What does it do? there is no way to know however you can infer that :

      • j34 is the first plugin to be run
      • j34 takes 3 arguments
      • sdf is passed through, and is computed last. Indeed it's probably replicated by a loop inside the code of j34

      To know what the above does you have to know what the plugins do, which is why I recommend using descriptive tag names rather than obfuscated ones, but that's really upto you, there is no limitation on what you call your symbols or what they do. The symbols can even modify each other and the document as a whole at runtime, a feature I have exploited in previous projects.

      To give another example, consider this:

      (case c="(qd)foo(/qd)") <bar> [inc]bar[/inc] </bar> <baz> [inc]baz[/inc] </baz> (/case)

      The above has exactly the same result as :

      <inc>(qd)foo(/qd)</inc> or (inc)(qd)foo(/qd)(/inc) or [inc][qd]... or [inc](qd)... or <inc>(qd)...

      However you might want to use the case statement instead if you want to catch an error such as qd->foo containing a value which links to a file which doesn't exist..

      (case c="(qd)foo(/qd)") <bar> [inc]bar[/inc] </bar> <baz> [inc]baz[/inc] </baz> <else> [inc]wtf[/inc] </else> (/case)

      This would be the same as saying :

      given ($foo) { when (/bar/) { return get_file('bar'); } when (/baz/) { return get_file('baz'); } default { return get_file('wtf'); } }

      Again there is always a mapping, but sometimes it's hard to see what that mapping would be for instance;

      <case c="(qd)foo(/qd)"> (inc)cases(/inc) </case>

      Where the file "cases" contains the code which was previously in the case tag, but now is added in dynamically prior to the case tag executing. The result is the same, however I cannot imagine how you could do that normally (that's not to say you can't, just that it probably requires a higher level of perl mastery than I currently have, and definitely a higher level of mastery than is needed to achieve the same result quickly and easily in aXML.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://932750]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (2)
As of 2017-03-01 21:53 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (429 votes). Check out past polls.