You know, I neither wish to give-away XP’s nor to start any sort of impassioned argument here, but, let’s face it ... it is (or will be, if it ever actually sees the light of day) ... “just another” programming language. Woo hoo.

I’m a professional engineer and engineering project-manager. We all are. I want a better engineering tool .. always. But, I wanted it five years ago. I want a genuinely better improvement to Perl that is 100% backward compatible with all of the CPAN and internal code-base. I want “-er” and I want it with zero engineering risk. A tool that meets those qualifications is eagerly awaited. A tool that does not ... is not “Perl” and should not dovetail upon that name. A tool that does not ... might (or, might not) have any more engineering-reason to exist than does any other newfangled language that from time to time pops out of the halls of academia. Or, it might be “OMG!” ShowMe.™

It is a damned difficult problem, if I may say, to create a worthy-successor to an established programming tool that has hundreds of millions of lines of source-code in service worldwide. You do not have a clean slate to work from: you have a legacy, too. Issues like “ROI” and “risk” trump words like “elegance,” much to the consternation of the language team. That’s also why, e.g.ADD 1 TO COBOL GIVING COBOL. turned out to be nothing more than a curiosity, and why a preponderance of FORTRAN programs in-service continue to use pre-77 syntax. That’s also why some of the extensions to Perl that have seen the light of day, such as Moose, are “amazingly elegant hacks,” yet “hacks” nonetheless. They didn’t go all the way back to the binary implementation ... to the “perlguts” ... they are fat and heavy, but they do at least part of the job that needs doing, and most importantly, they retain the entire legacy.

A couple years ago now, I watched a project spectacularly-fail that tried to move from Perl to Ruby, arguably an “-er” language that of course already exists. This project smashed into a wall, not because of the language but because of the so-called “gems.” The project backers erroneously assumed that, if Ruby had a “gem” to do what Perl had a “package” to do, the functionality and robustness of the two would be if not the same then at least very similar. So, they assumed, the project would be a “natural win” because the Ruby language was, to them, “-er.” (These people are genuine experts in both systems.) They discovered the hard way that their software stood on the shoulders of giants, and that, in the end, it was the giants who mattered. And so it is here. Perl, itself, is a comparatively tiny language ... but true giants have been built with it and you can use any of those giants. Of course I am not disparaging Ruby, which I also use frequently, and I will note that those “gems” that I refer-to have vastly improved, as would quite be expected.

Build something ... release it ... it would please a great many people including me to “eat crow” and to thunderously applaud your new and worthy engineering tool. You have doubting Thomases ... what did you expect now. Don’t take it personally or anything. This is engineering. We all have bridges to build, and clients to build them for.