I got as far as:

And this is a process which will continue into the future with the upcoming Quantum Computer systems, a version of which sporting 128 Qubits is already available on the market.

and then realised that you are fool enough to believe hype like this garbage. Despite that no one has seen it do anything and that no reputable quantum physicist believes that their description makes any sense at all.

Indeed, it is believed that the whole thing is a scam based on a few theoretical ideas and terms stolen from someone elses published work that has been misinterpreted, misconstrued and misquoted:

Umesh Vazirani, a professor at UC Berkeley and one of the founders of quantum complexity theory, made the following criticism:

"Their claimed speedup over classical algorithms appears to be based on a misunderstanding of a paper my colleagues van Dam, Mosca and I wrote on "The power of adiabatic quantum computing." That speed up unfortunately does not hold in the setting at hand, and therefore D-Wave's "quantum computer" even if it turns out to be a true quantum computer, and even if it can be scaled to thousands of qubits, would likely not be more powerful than a cell phone."

Their modus operadi seem to be to take some obscure but cool piece of theory, hype the shit out of it on the web, blag their way into getting a few (or a lot of) millions in venture capital before quietly folding the company after a few years, having paid themselves huge salaries and acquired lots of material goods.

Now, let me see:

1. Take a few quotes from someone else's cool sounding but ultimately useless paper.
2. Hype the idea as revolutionary genius, but make sure it is complex enough that you can claim that most people, (especially Vulture Capatalists) won't understand the details.
3. Appear to have something of a prototype that will be Real Good, Real Soon Now.
4. Try to generate some news worthy 'buzz'.

Yep. You seem to be following their recipe exactly -- I hope you you didn't pay too much for their "How To Make $Billion" e-book.

are fool enough to believe hype

We need the Quantum Computer systems, to control the new Q Bomb ;-)

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Regexes aren't evil in this case because they're slow. They're evil because it's incredibly difficult to correctly parse XML using regexes. In a language with stricter regexes, it'd be impossible, but in Perl's extended regexes, it's merely very, very difficult.

I don't take people seriously who talk about what they're going to do. I take them seriously when they talk about what they've already accomplished. So far, your entire output has been polluting Meditations with successive walls of text, plus a zip file with Perl code demonstrating terrible coding practices.

After cutting out the ranting about 486s, Moore's Law, and the herd mentality, I see a potentially useful templating system. But not a particularly remarkable one. It looks like Lisp done in XML, something that would be recognizable to someone who read the first chapter of Structure and Interpretation of Computer Programs. It hardly justifies all this talk of heretics and blasphemy.

tl;dr: please stop spamming Meditations. If your ideas have merit, then go code them up in a package that doesn't parse CGI parameters by hand and demonstrates knowledge of placeholders and context free grammars.

They're evil because it's incredibly difficult to correctly parse XML using regexes.

Not at all. Writing an XML parser using regular expressions is definitely no harder than writing one that doesn't. It's writing an XML parser (compared to using an existing one) that's hard.

I think that it would be better to say that, “whether or not you can parse XML using regexes ... from an engineering perspective that is not the point.”   When you are developing a piece of computer software that needs to process an XML file, the single most important consideration that you have is to minimize your exposure to project failure.   If you have at your beck and call a package of software that accomplishes a particular task (as evidenced by its ability to pass 15,385 (or somesuch) internal self-tests, and if you can get all that just by uttering the magic words, use XML::Twig, then, “point, set and match!”

This is the very same reason why there is a viable and important business in making pre-hung doors and even, in some cases, pre-finished walls and houses.   At the end of the day, you just want to deliver results.   You want to collect your final check, go to the pub, and not worry about being interrupted as you get a wee bit pleasant, because you know that every promise you made to your customers was kept ... and that you made a modest profit doing it.

So I request, I implore you, let go of the past, and have a real look at what I have done

That would be much easier if provided a link to the code in question, instead of assuming that everybody knows all of your previous nodes by heart, and remembers where to find it.

It also helps if you paste one or two usage examples here, kinda like the "synopsis" sections of most Perl modules.

be efficient, be frugal with memory usage, etc etc. But those rules just don't apply anymore, at least not to such a degree that they used to.

The above may not apply to simple programs and small sets of data, but somewhere out there someone IS pushing the envelope and guess what, it turns out all of those things still do matter! And they always will, because no computer can ever perfectly recreate the universe and run it in real-time. You should try dabbling in 3D computer graphics sometime to get a feel for how much further we have to go.

I accumulated over the last few years, but there is rhyme and reason to it all. I have the best of intentions here! Let me explain

There is never cause for being rude , esp to those civil souls who were genuinely interested in hearing what you have to say (most of them)

But those rules just don't apply anymore

Sure they do, see Increasing the efficiency of a viral clonal expansion model

And therein comes the reason why my ideas have received a less than lukewarm response.

Like many have told you many times, this is not the reason.

but that does not matter, because it is incredibly easy and quick to program in it,

For you and only you , no one else, and only because you know it so well, not because of the syntax.

Like I explained in Re^2: RFC : Abstraction Markup , TT2 does it with almost identical syntax/rules -- its prior-art

Hmmm...   I never quite expected to be referred-to as anybody’ “forebearer,” at the tender age of never-you-mind ... and I find it mightily amusing to see “1991” referred to as though it were “long ago.”   :-D

“Siddown, young punk, sober up and let me tell you a story!”   ;-) :-D

The computer is always improving in speed and capacity, following Moore’s Law for as long as the wizards at Intel continue to work their magic with sand, such that we constantly find that we can implement more and more outrageous algorithms and actually get away with it.   This is a very good thing, because what today is “outrageous” tomorrow will be considered commonplace.   This trend will never end, and herein lies my cautionary tale:   hardware capabilities are rising fast, but “the bar” is always rising even faster.

Therefore, we will always be obliged to pursue the simultaneous goals of hardware efficiency and software development efficiency.   We must develop and maintain software practices which are highly disciplined.   We must build software of bulletproof “reliability, availability, and serviceability.”   None of these goals have changed in the last fifty years, nor will any possible advances in hardware unseat them from their hallowed place.

I quite-frankly appreciate the fact that I started in this business at a time when computers were small, because it taught me to be efficient.   I am very proud that we had a student-registration system that could provide less-than one-second response time to 32 terminals at the same time (this being the maximum number of terminals that the computer could support), and that it could give a very well-designed user experience to every one of them, and that could run with absolute reliability throughout day upon day of the registration rush, thus giving the school something that made headlines.   That is “damn good software engineering,” if I may say so myself, and if you were to translate those parameters to the present day it would still be ... “damn good software engineering.”

Quite contrary to the expressed popular opinion (these kids today...), the experience of having to make a dollar out of sixty-five cents has not kept me unaware of what has happened since, nor made me unwilling to “push the envelope” just as hard as I can manage to push it today.   Nevertheless, even as computers have become vastly more powerful than I ever expected they could be by this point in time, I still recognize the value of the maxims in The Elements Of Programming Style, including this one:

Don’t “diddle” code to make it faster:   find a better algorithm.

A maxim like that is universal, and it must always be remembered because the computer (and therefore, we...) can never, ever rest on its laurels.   The bar will always rise faster than we can keep up.   We will always be racing just behind the cue-ball.   Twenty, thirty, fifty years from now ... the practice of engineering will forever be the same.

One last thought:   twenty years from now, guess what.   The bar will have risen so much that you will look back upon today and shake your head with disbelief at how you managed to “make a dollar out of seventy-five cents.”   Moore’s Law shows no signs of stopping, and neither do customer expectations.   Hang on tight, kid ... this roller-coaster never stops.

Don't beat yourself up too badly.

You appear to have simply made the mistake of writing code without knowing the first thing about what you are trying to do. For example, SQL Injection attacks are not to be avoided in the way that you tried (I will assume you tried).

Avoiding SQL Injection attacks with Perl's DBI is quite simple. Each DBD:: driver is free to implement things differently, but this is generally how you do it:

# Connect to the database:
my $dbh = DBI->connect($dsn, $username, $password);

# Prepare a statement using '?' placeholder:
my $sth = $dbh->prepare(<<"SQL");
  select *
  from table
  where something    = ?
  and something_else = ?
SQL

# Now supply the arguments - they will be properly escaped:
$sth->execute( $some_value, $another_value );

# We have avoided SQL Injection and can process our results:
while( my $record = $sth->fetchrow_hashref ) {
  # Process $record:
}
$sth->finish();
$dbh->disconnect();
[download]

The funny thing is - this axiom is fairly basic. One can hardly avoid finding an example of this pattern - if you simply read others' clean code.

The fact that you seem totally convinced that your new toolkit is somehow superior (or even on the same level as) other toolkits aiming to solve a similar problem is comical. It is comical because you clearly don't Get It on such a fundamental level (yet) that anything you write at this point should be regarded as dangerous and potentially problematic.

To illustrate this point, imagine leaving your car at the mechanic to have the brakes fixed. Hours later you come back and overhear the technician asking his co-worker, "Is it righty-tighty-lefty-loosey? I can never remember these things!"

Clearly you would be worried about having *him* work on your car!

I recommend you spend a year (yes, 12 months) reading the source code of at least one module per day checked-in to http://search.cpan.org/recent to remedy this problem. I think perhaps you are just "green" and haven't been exposed to actual Perl code, written by professionals, enough. Granted, there is some real crap that gets posted on there, but it's mostly good. CPAN's setup has a de facto requirement that "You must be this awesome to upload a Perl module" which precludes a lot of folks who simply have no clue about anything. Not all of them, but many. So reading a daily dose of http://search.cpan.org/recent will help you become a better programmer, just as reading classic literature will help you become a better writer than reading facebook comments would.

With patience and experience, you can make a great contribution. You already have the altruism and will - just improve on what you've already got which most people never muster.