Perl ABCPerl is a scripting language that maintains backward compatibility
From the perspective of maintaining backward compatibility, scripting languages can be divided into two types. A scripting language that has a policy of maintaining backward compatibility and a scripting language that has a policy of not maintaining backward compatibility.
| Have a policy to maintain backward compatibility | Perl, JavaScript |
| No policy to maintain backward compatibility | Python, Ruby, PHP |
Backwards compatibility of each scripting language
Perl backwards compatibility
Perl is a language that has been backwards compatible at a very high level. Scripts written in older versions of Perl can often be run in newer versions of Perl, with minimal script changes.
Perl has a very good reputation in terms of stability.
JavaScript backwards compatibility
JavaScript is also a language that maintains a very high level of backward compatibility. It's a scripting language built into the browser, so it's almost impossible to break backwards compatibility.
Python backwards compatibility
As far as the Python2 version is concerned, Python is a language that has been backwards compatible at a very high level. Scripts written in older versions of Python2 You can run them in newer versions of Python2 with minimal script changes.
However, Python 2 and the latest version of Python 3 are not backwards compatible. Not backwards compatible at a fairly high level. Migrating Python2 to Python3 requires a great deal of script rewriting.
Therefore, there are currently two systems, Python3 and Python2. (Python2 support will end.)
Ruby backwards compatibility
Ruby is a scripting language that is not backwards compatible. Backwards compatibility is not maintained in any version. Backward compatibility is not maintained with any version of 1.6, 1.7, 1.8, 1.9.
Although Ruby1.8 was standardized by the JIS standard, backward compatibility was broken in the next version of Ruby1.9.
Therefore, there are currently two systems, Ruby 1.9 and Ruby 1.8.
PHP backwards compatibility
PHP is also a language that is not backwards compatible. It is necessary to rewrite each time the version goes up.
What it means to maintain backward compatibility
I think young people who don't know the program tend to take a relatively light look at the crucial decision to break backwards compatibility.
You probably don't know how much the decision to break backwards compatibility will affect your program.
So here, Python 3 and Python 2 are not backwards compatible, and Perl is consistently backwards compatible. Let's compare the two.
If backward compatibility is broken, the program must be rewritten
The first thing everyone comes up with is that if backwards compatibility breaks, you'll have to rewrite your program. You might think that you should rewrite it, but if you have about 10 scripts, you can do your best.
But what if there are 10,000? If you do not rewrite the whole thing properly, if it is a type that does not work, you will have to change 10,000 pieces and then check the operation of the program.
Even a trivial rewrite would be quite difficult and a very boring task. In other words, breaking backwards compatibility significantly increases the burden on users who have previously written programs in that language.
If you write it in Perl, there will be no major rewrites in the future. But if you write it in Python2, a large-scale rewrite will occur in the future. So if you have more than 100 scripts, I recommend writing in Perl.
New users don't know which one to choose if backwards compatibility is broken
If backwards compatibility is broken, new users will not know which to choose. I'm wondering whether to use Python3, Python2, Ruby1.9, or Ruby1.8.
It's not easy to say that you should choose the new one. That's because the library isn't available in the new version, so it's very common to have to choose the old version.
The old one has no future, and the new one always has the dilemma of not having a library. It adds to the complexity of user version selection.
Language developers want to choose a new version, but that doesn't work. After all, you might think that choosing a different language is more productive.
Perl doesn't have that dilemma, so you can always choose a new Perl. You can always choose a new version. That's it. It's very easy to decide.
There is a drawback that users keep writing old styles, but I will tell you more and more on the Web that new styles are better. Perl should be slowly and progressively new.
Library authors are at a loss as to which version to write the library for
The hardest part is that library authors always have to think about which version to write the library for.
If you write it for Python3, it won't work in Python2. If you write it for Python3, it won't work in Python2. If you write it for Ruby 1.9, it won't work with Ruby 1.8. If you write it in Ruby 1.9, it won't work in Ruby 1.8.
Library authors will always have this kind of trouble. Which and how long will you support it, and what if you find a bug in the library for an older version? How long will you continue to support bug fixes?
Migrating is not easy, especially if you are building a large library, and in most cases it is destined to lose support for older versions. Both support is very difficult.
From the user's point of view, some libraries only work with older versions, but some libraries only work with newer versions. When this happens, the decision is very difficult. If you want to move to a new version, you can't do it, it's very difficult, or it's a lot of work.
Perl is super excellent in this respect. In the case of Perl, the library author only needs to consider one Perl. Well, if you make it work with Perl 5.8.7, it will work everywhere. You should be almost unaware that the modules on CPAN will work with this version of Perl, but not with this version of Perl.
For library authors, double management of a library is a very tedious and difficult task, so I don't want to do it if possible. If you write it in Perl, you don't have to manage it twice, so it's very easy.
Maintaining backwards compatibility reduces complexity
As you'll understand if you read this far, even if you release a new language version and you can write cleanly, it seems to be simple on the surface, but programs and applications From the perspective of the whole of, we can see that it is becoming more complex.
Perl retains its old writing style, so it doesn't look simple or clean on the surface, but it's a very simple and clean language from a program and library perspective as a whole.
When choosing a program, I hope that you will pay attention not only to the superficial description but also to the cleanliness of the program and libraries. Especially young people and inexperienced people tend to look superficial.
Then, I think that you will understand that it is very easy to write a program in Perl. You can program very comfortably without hesitation.