chromatic

What's my hidden agenda in agreeing with this article over yours?

That's a strong statement. Are you quite sure those are the only two possibilities?

This is also the P6 problem.

Many years ago there was a perl compiler...

... but it never worked very well. Certainly it didn't save memory and it rarely saved much startup time.

Perl still didn't address any real problems...

I think there's something like the Expression Problem in programming language design. How do you allow people to solve new problems and explore new patterns and paradigms in a language without encouraging them to create a series of incompatible forks (Tcl, Lisp, Common Lisp, Forth, Smalltalk, heavily macroed or otherwise preprocessed C or C++), limiting the scope of your language to small or relatively isolated projects (Lua), bringing ideas into the core library where they slowly bitrot (Python, Perl), or facing a dramatic rewrite (Perl, PHP)?

For better or worse, Perl's answer in the past few years has been to prototype new ideas on the CPAN, let the community use them and reimplement them and compete, and eventually enable them with the minimal core support possible. The strategy is decent, but it's not fast and it relies on the ability to find people willing and able to do this work in the Perl core.

Exactly. (I believe I wrote that explicitly the previous time this was posted.)

Part of the problem is that programmers believe we're special snowflakes and can't possibly be seen as fungible Taylorist cogs. Another part is that we chase language and library fads more than we pursue deep domain knowledge.

Deep domain knowledge, of course, includes a good understanding of business in general.

http://modernperlbooks.com/books/modern_perl_2014/

It works best with at least six months practical experience in any programming language.

Professional Perl programmers understood this coding error as a coding error at least in 2000, in my personal experience. If you squint, you can see it as a poorly designed interface in the CGI module (though I'm not sure how you would fix it), but your examples are passing untrusted, unvetted user input to sensitive code.

Professional programmers have understood that as bad practice for multiple decades.

Did all of those programmers and maintainers never read the tutorial for the language?

I'm certain if you went back in time and asked "What happens if a query string contains multiple parameters of the same name?" many people would look very confused, as if they'd never considered such a thing were possible. In other words, the answer to your question is "No, most web programmers neither read nor understood the documentation, because the state of web programming in those days was terrible."

Some of the profits of the Slashdot sale went to Blockstackers as an investment to develop E2. Unfortunately, the dot-com crash (and, to be fair, not enough effort spent marketing the software) meant there was little market for the underlying CMS.

"Larry Wall and other active Perl porters and Perl helpers met on Tuesday afternoon at Perl Conference 4.0 and mapped out a what is planned to become a complete rewrite of Perl that will become Perl 6 in 18 to 24 months." -- Linux Today, byline July 19, 2000 http://www.linuxtoday.com/developer/2000071901704OSSW

Cross-checked against an eyewitness report by Chris Nandor, published at http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/... on July 19, 2000.

Almost all of its developers quit around the same time:

http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...

While that behavior feeds back into improved quality for responsive maintainers, it takes additional time during installation. When combined with point #1, it can make dependency chains seem more fragile.

Perhaps in specification, the feature comparison matrix suggests that NFG is Not Yet Implemented in any implementation in practice:

http://perl6.org/compilers/features

I wonder if that "significant and rapidly growing chunk of the planet's programmer population" will find that an untested and partially implemented feature suffices for their needs in the real world.

The important point of JWZ's article isn't "teenagers". It's "rewriting everything from scratch... happens, over and over again". For example, Rakudo's current "Great List Refactor": http://pmthium.com/2014/10/apw2014/

JWZ explained it more than a decade ago: http://www.jwz.org/doc/cadt.html

That is the problem.

The future of Perl is very, very difficult to predict. 14 years ago, the next major version was announced. It was explained and designed and promoted in public by gathering the community's list of 361 technical flaws.

P6 is now older than Perl was when P6 was announced and no one can tell when or if P6 will replace Perl. That includes developers as well as users and technical decision makers. If you start a new project in Perl today, how long will it be supported? Will you be able to hire or train enough developers? Will you be able to retain them? Will P6 ever replace Perl?

Python has its difficulties with the gradual adoption of Python 3, but at least there's a consistent and coherent story about community expectations. Perl doesn't have that, and that, to me, as a technical decision maker, is a huge risk.

That's unfair. The current motto of the p6 faithful has become "It's a sister language not intended to replace Perl" over the years, but a lot of things have changed over the years. If and when a usable p6 is released, who knows what the motto will be then?

You brushed over the Python 2 to 3 migration, but at least that one had a coherent strategy. It's not an easy strategy, but there's an end of support date for Python 2. There's a widespread effort to port libraries and frameworks and projects to Python 3.

That hasn't happened yet for Perl. It's not clear if that's ever going to happen for Perl. No one is exactly sure how much of the CPAN p6 will support, if any.

Will people start writing more new code in p6 instead of Perl? Will people port code from one to the other? Will p6 be able to use existing libraries? Will those libraries be usable in the same process?

When will p6 be stable? When will it have documentation? When will it have support, from a community point of view or a vendor or bundling in a supported distribution? When will it have tool support? What is its deprecation policy? What is its support period? Who will use it? What will they use it for? How much training do they need? How much do they charge? How easy is it to hire them?

There are so many unknowns. It's unfair to sweep them under the rug and say "Everyone should know that Perl is Perl and 6 is something else and the latter doesn't matter."

Smalltalk was expensive (VisualAge, VisualWorks, for example) and wanted to own the world (image-based). With the web suddenly solving all deployment problems everywhere (at least, that was the rhetoric), paying thousands of dollars per developer for tools seemed silly.

Again, please leave me out of your uninformed and biased speculations. You weren't there. You weren't involved. I was--not only as a developer on both projects but as the P6 project secretary. In that capacity, I took and published hundreds of pages of notes, and I'm more than capable of speaking for myself.

Let's assume the Rakudo developers acted in good faith per your reasonable default. The effect is still that Parrot is all but abandoned, multiple productive developers with decades of practical experience attempting to implement P6 no longer contribute to either Parrot or Rakudo, and Rakudo isn't obviously more usable than it was three years ago. The effective delivery date of P6 is still "some time in the future". The fourth anniversary of Rakudo Star is approaching and it hasn't met its goals.

Even if Rakudo were released in a stable, 6.0 form today, I still wouldn't use it for anything I care about because I don't trust its developers to deliver usable software reliably.

When Rakudo announced it wanted to rewrite NQP to run on multiple backends, the stated justification for not relying on Parrot in the long term was twofold. First, because Parrot developers didn't treat Rakudo as the most important hosted language. Second, because Parrot didn't provide the features Rakudo wanted--in particular, its object model was unusable by Rakudo.

Those reasons are tied together; the second was used as proof of the former. You can also throw in the deprecation policy as a supporting reason, but that makes things more complicated because Rakudo developers wanted it in place for some things ("you can't change things in Parrot and break our code") and wanted it gone for other things ("why can't you just fix this thing?").

I have a problem with both reasons #1 and #2, because I have multiple examples of Parrot developers offering to do make changes to help Rakudo. In my case, I was told not to do them. In the case of sixmodel, the stated impetus behind #2, Andrew and others (who had been accused of not wanting to help Rakudo) were continually volunteering to write the very code that Rakudo developers said they wanted and were continually told "No, not yet." (See Raiph's links, for a few of many examples. See the #parrot and #parrotsketch logs for many more.)

Meanwhile, Rakudo developers were continually complaining how Parrot developers were not interested in helping Rakudo and how Parrot was technically a bad fit, citing sixmodel as an example.

I interpret that response as something other than good faith. I believe that's why Parrot developers left; there's no point to sticking around in that situation.

You mean the first commit committed to a repository which survived long enough to be made public, eventually. Even so, if you look at the timestamps on those first commits, you realize that either the design of the VM leaped from someone's head fully-formed like a virtual Athena, or (as was widely known at the time) that someone had been designing and playing with ideas for much longer.

Maybe look at the chronology again?

The one where Rakudo developers told Parrot hackers not to implement sixmodel to replace Parrot's default object system (the one which one of those Rakudo developers had, in fact, actually implemented) during the period where it was obvious that those Rakudo developers were in fact designing their own VM?

Who am I to believe, you or my own lying eyes?