|Perl: the Markov chain saw|
Pulling Punchesby simonodell (Acolyte)
|on Jul 12, 2011 at 00:54 UTC||Need Help??|
I've heard that around here people do not pull their punches, and indeed it appears that they also hand them out at the drop of a hat for whatever reason suits them. I've also heard this little rumour that humility is highly valued here, however according to experimental evidence, monks appear to speak highly of humility and yet show little evidence of knowing what the word actually means.
So I'm not going to pull any punches either, and believe it or not, merely pressing on with explaining my ideas here publically and for free, and requesting help with a problem I have found too difficult to solve single handed is a huge demonstration of humility.
Right now for the punches.
PHP IS KICKING PERL'S ASS.
Sorry! not sorry! If you, like me, live in the REAL world, you will be aware that it is getting harder to find perl jobs and that in job listings the number of PHP related jobs outnumbers perl jobs by maybe 5 to 1.
BUT PHP SUCKS.
We are into PERL, we all know why... no need to explain it, I'm sure we have all at some point been called to debug someones PHP based project, and seen a spaghetti mess reminiscent of something out of the film "brazil" come spewing out of our monitor screens. You know what I'm talking about, code and markup and even database calls all mashed into one big messy monolithic block of code with dozens of echo statements and the like. YUCK.
PERL NEEDS TO ADAPT AND EVOLVE OR ITS GOING TO DIE.
But despite it's many and numerous flaws, PHP is still taking over, and you have to ask yourself why that is. It's no good moaning about it and wishing the world would suddenly and magically discover what is so amazing about PERL, they won't, it is too complicated for most, requires too much discipline and effort to craft an elegant solution.
PERL IS FAST GOING THE WAY OF COBOL.
I did cobol at college, right after I had already got into and fallen in love with ANSI C (+asm for super whizzy fast turbo speed inner loops)... I'm sure you can imagine the horror I felt having to go BACKWARDS in terms of code abstraction level to a primitive, verbose, clunky and BORING old language. Infact COBOL was the root cause of me leaving college. I won't use primitive obsolete languages, period, won't do it.. no... fullstop. I'd rather be unemployed thank you goodbye.
I'M NOT HERE TO LEARN YOUR WAYS
I am not the sort of person who needs a teacher or a mentor, I am quite capable of solving any problem I come across or reverse engineering code in any language I choose. Ok well some problems are too difficult, however even those will be solved if I only had time to do it with. When I say too difficult I don't mean impossible, I mean it might take me to 2016 to solve, but I will solve it because I'm awesome and sexy.
MY PARADIGM IS BETTER THAN PHP
I chose PERL for the reasons you all choose PERL, because it rocks. But... and it is a big BUT, in the real world which many of you monks take great care to not interact with where possible, PHP is winning because it is so quick and easy to get results which please manager types who haven't got a clue about namespaces, $_, and all the other goodies which PHP completely lacks. But I'm a man with a plan, and you are the monks who are going to listen up, because I have solved the problem and my perl based paradigm is easier and quicker to get results with than PHP, and it comes with all the PERL yummyness you love so much.
I refuse to work with the tonker toy language that is PHP, however I do see it's appeal to some, especially people who just want results fast. And fast is good, I hate wasting keystrokes, for a start I've got a pile of worn out keyboards and for seconds I would really rather avoid getting R.S.I. .. infact that is probably why I am not a java programmer. (don't get me started on that subject)
Ok so now I've given you a bit of an entertaining rant and established my awesome geek coder sexyness and utter lack of false humility, perhaps I should direct you to my other nodes wherein I have tried to explain things instead of just chatting away about things you all already know about.
ON THE OTHER HAND I CAN'T BE BOTHERED.
So I will leave you with this brief explanation and let you all get on with clicking the -- button or whatever it is you like to do with your spare monk time.
It's a bit like embperl only sexier.
It's a bit like HTML::Mason only less secretive and no funny handshakes.
Systems are built out of files which contain a mix of xmlesque tags and HTML.
Known tags are defined by plugins which are written in perl and have the full use of everything perl.
The $result of computing a child tag, becomes the $data of a parent tag.
The simple rules :
Rule 1 : Tags are computed from the innermost to the outermost, unless the tag delimiter type specifies otherwise.
Rule 2 : ( ) tags have the highest priority and compute prior to child tags of type < > and [ ].
Rule 3 : < > tags have the next highest priority and compute prior to tags of type [ ].
Rule 4 : [ ] tags have the lowest compute priority.
Using this very simple set of rules, and by defining the meaning of tags using plugins, it is possible to provide a system which is easier and quicker to write apps in than PHP whilst still having all the power and stability of perl available and retaining compatibility with CPAN modules etc.
YOU CAN DO WHATEVER YOU WANT WITH IT
Unlike things like coldfusion etc, I am not trying to suggest that the names of the tags themselves are important, I don't want to limit things so that you have to type in <CFthis> <CFthat> etc, but instead allow you the freedom to decide what to call your own tags and what those tags should do.
for instance I have a tag called <loggedin> which only shows the data it contains if my framework agrees the current user is logged in. I could just as easily of called the plugin <anyonethere> or <wehaveuser> or anything really, it doesn't matter.. TIMTOWTDI
Well I'm going to stop ranting now and get on with being uber geeky sexy, because believe it or not, my time is actually valuable, and I believe that if you lot are half as good at programming as your collective attitude suggests, I have already just thrown a gauntlett down to you which you will not be able to resist picking up, and I have given you plenty of information that took me years of experiments to obtain and to refine the ruleset and test it's validity. (it always works)
IT WILL BE INTERESTING TO SEE IF ANY OF YOU ARE CODER ENOUGH TO WRITE AN IMPLEMENTATION OF THOSE RULES WHICH IS MORE EFFICIENT THAN MINE.