Here, fixed that for you.

Why wouldn't you want to use keyboard shortcuts? I'm genuinely interested as I'm on the other end of the scale and am doing pretty much everything via keyboard.

That service already exists. Ever heard of TPB?

When Netflix came their influence faded a bit because people were able to get their content easily, legally, and *now* instead of waiting for a torrent to download. But the greed of media companies may well reverse the trend.

At the very moment these media brands all set up their own streaming services they will see a curious thing: instead of setting up N monthly $10 subscriptions, people will rediscover the wonders of torrents...

I don't know what they are thinking.

These are all good ideas, and yes - quite obvious. You can bet Facebook will go the other route.

This, so much this! It would be great if, for example, The Chronicles of The Black Company by Glen Cook were made into a series. Or The Demon Cycle by Peter Brett.

While I somewhat agree that Perl does not try to be easy, I think it does not make it a good language, even for "professionals". What Perl does is hide your errors and turn them into traps. I just cannot comprehend why someone would want that? And to prove I don't come to a discussion with empty hands:

- no control over function parameter types
- automatic flattening of arrays
- no distinction between numbers and strings
- no distinction between hashes and arrays
- turning undefs into defined values when used as references (who in hell thought *this* would be a good idea?)
- modules are not first class values,
- no error when you mess up and use '==' instead of 'eq'
- no straightforward way of setting up a function with default parameters
- no officially sanctioned threading model (and no, 'use threads;' just doesn't cut it)
- no scoped lifetimes (in the spirit of Python's 'with' or RAII in C++)

I spent the last three years writing and maintaining Perl codebase of a few 10KLOCs. It was a nightmare. I solved most of my gripes with Perl, and was almost satisfied with the solutions I found. But the bad taste remains. In my opinion Perl has too many deficiencies to be considered a good language in 2017. There are better choices now (again, in my opinion).

THIS! People, this person knows what they are talking about!

If you use Perl as a BASH replacement for simple scripts then it is decent. There's no denying that. Kinda like an bash-o-awk-o-sed on steroids, with fancy syntax.

But writing more involved programs in it? Hell no... And I say that after working on a Perl program for the last three years (it paid the bills, barely but it did, so... you know). Never again. The amount of manual checks I have had to insert into the code to make it behave and to catch errors is staggering.

You can write good code in Perl, yes, but it takes a ton of effort and you have to be alert and on lookout for traps at all times - otherwise you're doomed. In my opinion, you're better off using a language that at least tries to keep mistakes manageable, with sane error handling, compile-time checks - basically, all the help you can get. Because writing software is not an easy task, and you will make mistakes.

This is a bug and will soon be fixed.

It's also available in, for example, Poland (as you can guess from the "pl-en" part of the URL).

Well, you can start today. Star Trek Discovery already is on Netflix: https://www.netflix.com/pl-en/...

In Soviet Russia official narrative swallows you!

Python is strongy typed. JavaScript is weakly typed. They are both dynamically typed. Consider the below code... ...in Python

>>> 42 + 'Answer'
Traceback (most recent call last):
    File "", line 1, in
TypeError: unsupported operand type(s) for +: 'int' and 'str'
...and in JS

js> 42 + 'Answer'
"42Answer"

One simple rule for determining if a language is weakly or strongly typed is: "Does the language lets me combine incompatible concepts (like add apples to oranges)?"
The rule itself is a bit weak, though - what are incompatible concepts, for example.

I know that.

I know this too. And it makes sense to me. I am a big fan of static analysis tools of various kinds.

My point (poorly expressed, it seems) was that type hints are not required to be enforced (neither at runtime, nor at compile time) and therefore probably won't be (due to laziness, or other reasons). The fact that you can use some external tool is almost moot.
With C++ you have to work to avoid the type checking, with Python you have to work to enable it.

Type hints are cool and all, but there is no intention to actually enforce them and that makes them more akin to documentation than anything else.

For example, the code below is perfectly valid:

def frombulate(x : int) -> int:
    return { 'answer': 42, }

frombulate([ 'A', 'list', 'of', 'strings' ])

The frombulate() function supposedly expects an integer, and claims to return another integer, but is happy to get a list of strings, and return a dictionary.