Why I don't want to program in Perl anymore

Much has been said about the shortcomings of pearl as a language and platform, for example, about the fact that there is no language specification, about the strange syntax to which you need to get used for a long time, etc.

It is enough that the authors of the language, conceiving new versions, in fact created a new language a little similar to the original one ( Perl 6 ), thereby acknowledging that the current pearl was not very successful, which is understandable in principle, because The language was created as a replacement for the shell, and then acquired features.

I would like to say about my personal observations, which led me to work on a pearl, I will go only as a last resort, despite the fact that this is my main language.
')

1. Backward compatibility - the pearl is trying to maintain it, on the one hand it is good, on the other hand, in order to write on a modern pearl, it is necessary to explicitly include pragmas of using new features, i.e. By writing the default code in the 21st century, you can get code in which the compiler does not even catch typos and variable names and does not support any new constructions. I think those who want backward compatibility should include such pragmas, and by default the language should be relevant.
   
   
2. Parallel programming - with threads in Perl was initially bad, somehow they were not always recommended to use, you can fork processes, but up to a certain threshold, and then people start thinking how to optimize it and of course the pearl is no exception - the history of this question is about this, first there was POE , then Coro replaced it, and then AnyEvent won and won. And for a long time I did not understand the essence of the problem, but when I learned how these issues are solved in Erlang or Haskell I realized that asynchronous programming on callbacks is a low level, in fact, a step backwards. Pearl once shot exactly as a high-level language, and then it turned out the opposite.
   
   
3. Global variables - literate programmers of course use use strict and my, but many language constructs, such as regular expressions or eval, use global variables to return a result, which is always a deformity to remember, for example, $ 1 may be the result of the previous match, so check not the presence of the value, but the result of the match. In python, including for regex, they managed without global variables and everything turned out fine.
   
   
4. eval is an example of strangeness in syntax, in fact, eval is in a pearl, if you pass a string to it, it behaves as expected from a function with that name, but if you pass it a block of code, then it essentially implements the try statement, although it is poor ( so cpan has a lot of try fixes).
   
   
5. Passing parameters to a function - again, some low-level mechanism is proposed, parameters come in the form of an array and need to be explicitly turned into something readable, some variants cannot be implemented in principle, for example, two hashes cannot be passed by value, only by reference. There are of course crutches like this , but crutches are crutches, just look at how parameter passing is implemented in Python to understand what a well thought-out high-level parameter transfer syntax should look like.
   
   
6. in — — , element in array, , smart matching, , , .
   
   
7. — Datetime, , ( ) , . Class::Date, - , , - , , . .
   
   
8. , , , .
   
   
9. , — « ».

- , , , , , , , , -.

, , , , Inline::Python .