> (1) ... If I read Python fans on Quora today, it feels like the enthusiast PHP community in the early 2000's.
This isn't a useful comparison. If Python fans in the early 2000s were like PHP enthusiasts at the same time, and Python fans are still enthusiastic while PHP fans are not, then that gives a rather different interpretation.
That is, one reading of the comment is that Python will follow the PHP trajectory, just 15 years later. Another is that Python fans have maintained their enthusiasm far longer than PHP ones have, and that more long-lived enthusiasm may be indicative of a better language.
Since there are two mostly opposite ways of reading the text, it doesn't make a useful comparison.
As a reminder, in the 19990s and 2000s, Java was the mainstream education language.
> (3) ... "its whitespace-based syntax is really annoying (see Garry Taylor's answer ..."
Taylor's answer asserts without proof that "I think for real code, Python’s whitespace idea really, really doesn’t work. / It’s a pain to refactor, lambdas can only be one line (!), and just doesn’t present benefits."
As a proof-by-example, there are 500K Python code bases, like NumPy+SciPy.
PyCharm include automatic Python refactoring operations.
In practice, I have not found the lack of multi-line lambdas to be a problem. When my lambdas get to be that large, I tend to replace the code with something more declarative than functional, because I find it easier to understand. But at this point it's a personal view.
What little there is on the way of experimental evidence, like Lutz Prechelt's now-dated "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl" suggest that it isn't a serious and obvious problem.
> ... More WTFs of Python language design see in Richard Kenneth Eng's answer
Eng does not like indentation, but explicitly says it's a matter of individual preference.
I agree that it's "easy to advertently [sic] misalign" Python code. It's also possible to inadvertently mess up {}s, as this example from the C FAQ shows: http://c-faq.com/strangeprob/emptyloop.html .
> ... Python is lagging behind new and better languages such as Go, Elixir, Julia, Clojure or Dart in many features.
"New" is true. "Better" is an opinion. It would be better to describe why they are better.
Are there no features in Python which Julia, etc. are missing? That is, is it wrong to say "Go, Elixir, Julia, Clojure, and Dart are lagging behind Python in many features"?
For a trivial example, I don't think Go supports an eval().
You might respond that 'eval' shouldn't be used, which is fine. That means that "having features" doesn't mean "better".
> (4) In web development Python offers nothing outstanding
That paragraph seems to be pure opinion.
> (5) In the data science / ML etc. field ... as I know it has severe problems with commercialization, that is: it is easy to craft a model with it, but when it comes to an actual commercial product, problems begin...
I don't know what that means. What are the problems?
FWIW, Python is also widely used in the sciences outside of 'data science / ML etc.'
This isn't a useful comparison. If Python fans in the early 2000s were like PHP enthusiasts at the same time, and Python fans are still enthusiastic while PHP fans are not, then that gives a rather different interpretation.
That is, one reading of the comment is that Python will follow the PHP trajectory, just 15 years later. Another is that Python fans have maintained their enthusiasm far longer than PHP ones have, and that more long-lived enthusiasm may be indicative of a better language.
Since there are two mostly opposite ways of reading the text, it doesn't make a useful comparison.
> (2) ... "script kiddie" ... "mainstream educational language"
As a reminder, in the 19990s and 2000s, Java was the mainstream education language.
> (3) ... "its whitespace-based syntax is really annoying (see Garry Taylor's answer ..."
Taylor's answer asserts without proof that "I think for real code, Python’s whitespace idea really, really doesn’t work. / It’s a pain to refactor, lambdas can only be one line (!), and just doesn’t present benefits."
As a proof-by-example, there are 500K Python code bases, like NumPy+SciPy.
PyCharm include automatic Python refactoring operations.
In practice, I have not found the lack of multi-line lambdas to be a problem. When my lambdas get to be that large, I tend to replace the code with something more declarative than functional, because I find it easier to understand. But at this point it's a personal view.
What little there is on the way of experimental evidence, like Lutz Prechelt's now-dated "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl" suggest that it isn't a serious and obvious problem.
> ... More WTFs of Python language design see in Richard Kenneth Eng's answer
Eng does not like indentation, but explicitly says it's a matter of individual preference.
I agree that it's "easy to advertently [sic] misalign" Python code. It's also possible to inadvertently mess up {}s, as this example from the C FAQ shows: http://c-faq.com/strangeprob/emptyloop.html .
> ... Python is lagging behind new and better languages such as Go, Elixir, Julia, Clojure or Dart in many features.
"New" is true. "Better" is an opinion. It would be better to describe why they are better.
Are there no features in Python which Julia, etc. are missing? That is, is it wrong to say "Go, Elixir, Julia, Clojure, and Dart are lagging behind Python in many features"?
For a trivial example, I don't think Go supports an eval().
You might respond that 'eval' shouldn't be used, which is fine. That means that "having features" doesn't mean "better".
> (4) In web development Python offers nothing outstanding
That paragraph seems to be pure opinion.
> (5) In the data science / ML etc. field ... as I know it has severe problems with commercialization, that is: it is easy to craft a model with it, but when it comes to an actual commercial product, problems begin...
I don't know what that means. What are the problems?
FWIW, Python is also widely used in the sciences outside of 'data science / ML etc.'