in reply to
Re^6: Does Perl Have a Business Plan?
in thread Does Perl Have a Business Plan?
You completely/elegantly ignored the ROI topic I pointed to.
Your link lead me to a blank 'Sign Up to see the Wonderful Goodies' page. I haven't stuck my hand in a lucky dip box since I was a kid.
Unfortunately my estimate of the situation (and of your estimate of the situation) differs significantly.
Yes. Does that make you automatically right?
If Perl6 is so obviously dead in the water, why are you bothering to attack it?
I would like to quote ...
Ah! Appeals to -- for all intents and purposes, random -- higher authority, the last chance saloon of unreasoned zealotry.
Do you quote him because he is right, or is he right because you quote him?
that situation would radically change, 180°, if there was a Perl5 to Perl6 converter.
And now finally to the agenda. But, are you promoting a converter you have written; or recruiting for the magic bullet you perceive?
If you ever unlock that door to your vision, we might find out.
In all likelihood this is just another 'I've a great idea and I've written a thesis and knocked up a web page to present it; now all I need are some donkeys to do the work' to raise my
phantastical vision to reality; but I'll keep an open mind for now.
If it could automatically convert 80% of the pure-perl CPAN modules to Perl6 ... BINGO!
Sorry, but I think you are wrong. Indeed, I think that perhaps the second worst thing that could happen to Perl6 is the creation of such a tool. Why?
Because some large percentage of the Pure-perl modules are dross unworthy of persisting.
Large numbers of the modules on CPAN are newbies first goes at writing modules; 90% boiler plate; 10% wasted effort.
Ranging from: trivial OOified replications of; or ill-conceived "corrections" to; misunderstood built-in functionality.
To: badly designed, or badly written, or clumsy interfaced, or theoretically pure but with horrible performance, or just plain broken. And sometimes all of those.
Written as stand alone projects without the benefit of real world application, in order to gain experience, or simply to have a presence on CPAN to which they can point prospective employers/customers. Token gestures of 'contribution'.
Because it would lead to the persistence of the whole never-mind-the-quality-feel-the-width ethos that pervades unknowing's view of CPAN today.
There are probably less than 100 (certainly less than 500) vital, critical, modules on CPAN -- ie. those that fulfill 90% of the use statements seen in the wild. And most of them will have an XS component that would prevent automated conversion.
And of those that are pure-Perl, the best, most used, most indispensable ones will make extensive use of all of the quirks and guru-tricks that at the same time, make Perl5 so powerful and productive; but also, so difficult for initiates and part-timers.
For you magic converter to be able to port these, Perl6 would need to replicate all of the "bad behaviours" -- bugs-made-features; quirks and dark corners -- that are the reasons for both its existence and the desire to have it. And if Perl6 did that, it would be little better than Perl5 and lead to all the same problems.
It would concentrate the efforts of the must-have-a-presence-on-CP6AN developers in exactly all the wrong places.
A line for line conversion of Perl5 to Perl6 won't benefit from what makes Perl6 so desirable. Instead of looking at the requirements and then using the power and elegance of Perl6 to satisfy them in the best way it can; effort would be concentrated in finding boiler-plate replacements for Perl5 idioms and then applying them as widely as possible.
It would encourage and facilitate the persistence of the scatter-gun approach to library design that is characteristic of the 90's approach to language library design in general and of CPAN in particular.
The whole free-for-all for top-level name-spaces; and stick-it-in-wherever, uncoordinated approach to getting-it-out-there. A first-come longest-lived and highest profile namespace landgrab, with a total lack of control over either logical structure or quality.
Step back and take a look at the way library design has evolved in other languages. Java and C++ are good starting points. Look at the STL of the C++98 and the STD::* classes of C++11. The wide, deep, meandering of the former and the concentrated, coordinated, minimalism of the latter.
To succeed, Perl6 needs CP6AN to be designed, coordinated and controlled.
Automatically generated/converted code is crap.
If you start with bad code prior to conversion, you'll end up with worse code after it.
The Perl6 core libraries need to be designed to the strengths of Perl6; and written using the best of Perl6 idioms. Anything less will serve as a bad reference for new authors and reflect badly on Perl6 as a whole.
Logic dictates that if the first examples of Perl6 -- its libraries -- that people encounter are bad examples; then that is what they will write. And that would be the final nail in the coffin that has been sat, ready & waiting in the corner for a very long time.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.