Re: Which 'Perl6'? (And where?)

[davido]

BrowserUk

There's a distinction to be made between "discouraged" and "deprecated" with respect to the status of threading. I followed the discussions on the p5p mailing list out of curiosity. It appears that a few people grew tired of answering questions about threads (I think in IRC), and felt that threads' correct use was sufficiently complicated that it would be in everyone's best interest if newcomers were discouraged from using them. But it's my understanding that there's no intention of removing them entirely.

Here are a couple of related messages from P5P. The entire thread may be worth reading (at least I found it interesting).

• http://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html
• http://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213457.html

I disagree with the strategy of "This is hard to use correctly so let's tell people not to use it." I think it's an over-reaction. If something is too difficult for some people to use correctly, that doesn't mean that it's of no value to those who have taken the time to learn how to use it properly. Most of the rest of Perl's documentation does a reasonable job of mentioning, "...this feature is deeply magic. Here be dragons." ...That sort of thing. There's nothing wrong with just documenting the complexities and suggesting that for many situations forking is easier to manage, rather than to strongly discourage the use.

A "Best Practice" might be to favor one approach over another in a general sense. But we all know that threads have specific uses that are not easily replaced with other technologies. For that reason, I think that "discouraged" is probably too strong.

But I do think to be fair one should recognize that they are not deprecated, and nobody is talking about removing threads from Perl.

[raiph]

I'd say this issue ("it's hard to use threads correctly") has at least four separate aspects worth considering in the context of Perl 5 and its documentation:
1. Is concurrency appropriate? There are two basic motivations that can lead to use of concurrency constructs in programming: 1) because the domain naturally involves asynchronicity and 2) to speed things up. In the latter case, if the problem being tackled is really IO bound, turning to concurrency probably won't help.

   It might be worth providing some simple rubrics in some Perl documentation to help folk figure out when concurrency likely will or won't be helpful.

2. The Problem with Threads. For all but trivial problems, correctly using conventional low level concurrency constructs such as threads and locks is surprisingly difficult. This is true for all langs, even, say, erlang or clojure. It has nothing whatsoever to do with Perl.

   It might be appropriate to warn most programmers away from use of low level constructs. Perhaps "Here Be Dragons And They WILL Burn You" goes too far and a link to "The Problem with Threads" or somesuch will suffice.

3. Futures et al are the future. There are much simpler, safer, higher level ways to do concurrency. I haven't tried Paul Evans' Futures, but they look the part.

   It think it is appropriate to encourage most programmers to use these higher level constructs.

4. Perl 5 "threads" are very heavy. This sometimes introduces additional complexity.

   I'd say this is worth mentioning, but it's perhaps the least important of the four points (though perhaps the most annoying to those expected to answer questions about them).

Finally, I'll note that the section Make the hard things possible in the P6 synopsis on Concurrency says:

Perl 6 should not hide the existence of OS-level threads, or fail to provide access to lower level concurrency control constructs. However, they should be clearly documented as not the way to solve the majority of problems.