chromatic

I have trouble understanding this paragraph. It seems to argue that acquisitions encourage company formation and execution. So far so good--but what's the definition of innovation in this discussion anyhow?

Perhaps the most confusing idea to me is suggesting that investing in startups does encourage innovation, but not as much as randomly giving out grants would. Is it possible to compare the efficacy of the VC, M&A, IPO ecosystem to those targeted grants or even a guaranteed wage? To me, that is worth exploring.

Instead I fear we get SV press releases heralding innovation in something--anything--other than yet another example of cashing out for the established network of moneyed interests.

I question this claim. Perhaps it's true of some syntactic features (`say` comes to mind as do some proposals for function signatures), but the semantics rarely translate over well (consider smartmatch). If you squint and tilt your head you can claim that Moose is an example of a feature designed in one language and implemented in another, but Moose is more an exercise in language/feature syncretism than it is porting something complete in implementation or design to Perl 5.

The inner parentheses force evaluation of the two inner comma operators in the scalar context provided by the function prototype. `1` and `3` get evaluated in void context and discarded, leaving `2` and `4` as the two arguments to the function. (I had to look up `+` in prototypes, however.)

Without a working understanding of lists and context, this example is undoubtedly baffling, but that's why the documentation exists.

By default, the arguments to a procedure are in the array context, which means that the comma operator expects both of its operands to be arrays. It promotes them to single-element arrays if they are scalars. In Perl, comma (,) can mean cons, append, flatten all at once.

I wrote an explanation of context in Perl which is hopefully clearer:

http://modernperlbooks.com/books/modern_perl/chapter_01.html...

The primary goal of the `...` feature was to make example code compile safely. (I implemented the feature in Perl 5.)

You're ignoring context, which is a fundamental design decision in Perl. That's like criticizing C for having pointers while ignoring the design decision to expose memory as a flat space.

Yes--people who have practical experience writing and maintaining code that has to be maintained tend to write maintainable code.

Scientists (and, in my experience, especially bioinformaticians) tend to make horrible, awful messes no matter how maintainable you think a language is. (You can hand them Inform 7 and it'll still end up looking like Fortran ate the csh manual and vomited all over an APL keyboard.)

The goal was to run existing Perl code in the same process, so that you could gradually adopt new features or use existing libraries with new code. If that had worked out, there'd have been less of the Python 2/3 gap.

Then again, the idea that Perl and P6 are different languages is something that's come up after the fact, after it became obvious that P6 wouldn't be ready for general use any time soon.

The idea that it would be a series of incremental improvements to Perl 5 ended around 2001, and certainly by 2002 at the latest:

http://www.perl.com/pub/2000/11/perl6rfc.html

The grand unification of runtimes (Ponie) had failed long before the announcement of its demise in 2006:

http://www.nntp.perl.org/group/perl.ponie.dev/2006/08/msg487...

I suspect but can't entirely prove that the appearance, rapid ascent, and even more rapid burnout of Pugs made a lot of people realize that this would be a long slog. Even so, if you look back at mailing list messages or conference talks or blog posts in 2006, 2007, 2008, whenever, you'll see that the party line has always been "It's only a year or two away."

Way back in the early days, the goal was to release a usable 6.0 in a couple of years. The "there's no hurry" line is a post hoc justification from around 2006 or so.

That's moving the goalposts a bit! What's currently called "Rakudo" is at least the sixth or seventh attempt at an implementation, not counting Pugs, viv, v6, or Niecza.

Oh, don't worry. There's plenty of activity in Perl and the CPAN that's not waiting on Rakudo.

Does your programming language distinguish between period, semicolon, and colon? Are = and == separate operators? Is whitespace sometimes insignificant and other times significant?

The voting system of PerlMonks rewards this.

Trying to force that culture of expression and code gymnastics to write a maintainable codebase just isn't worth it in my opinion.

Don't adopt a voting system like that of PerlMonks in your business, I guess. Or else hire responsible adults. That seems straightforward enough.

The problem with the English language is that it allows writers like James Joyce to get their work done just as it does E. B. White.

I can't wrap my mind around this complaint. "Why should you count on Perl treating booleans the way Perl treats booleans? Other languages don't treat booleans the way Perl treats booleans, so obviously you shouldn't rely on Perl treating booleans the way Perl treats booleans."

It's almost as if there were some democratic notion of boolean semantics where every language you know gets one vote.

Yes!

we don't see or hear about any new start-ups using Perl

The world is a lot bigger than just startups, but see:

http://www.builtinperl.com/

http://www.cpantesters.org/

I've been fortunate to work in circumstances where it's allowed and expected to spend time experimenting with new ideas or technologies to see if they'd fit with the project--so it's not a distinction between people who put in their eight hours and go home and people who work twelve or fourteen hours a day, seven days a week.

Yes, and that's my gravest concern about most Perl tutorials. Perl's theoretical basics are sufficiently different from other Algol family languages that they should be taught explicitly. Expecting people to intuit them over time leads people to conclude that Perl is "a poorly integrated collection of features."

The language does have its warts, but it's much easier to work with when you understand its underpinnings and work with them rather than against them.

(I apologize for the late reply.)