Maintenant, je voudrais faire une comparaison ou donner un avis. Juste satisfaction de soi et opinions personnelles.
Je pense qu'il est important de connaître le contexte et le but de chaque langue en termes d'utilisation de cette langue.
Avant Perl, il n'y avait que des langages de compilation comme C dans le monde, et seuls les shells, seds et awk pouvaient traiter sans compiler. Quand je voulais traiter automatiquement un petit texte, mais que ce n'était pas quelque chose que je créerais sérieusement en langage C, tout le monde traitait les commandes UNIX côte à côte comme des scripts shell. Des commandes pratiques telles que sort et test étaient fournies sous UNIX, et même un traitement un peu compliqué pouvait être géré en utilisant pleinement sed et awk.
Cependant, il existe deux types de shells, le type Bourne Shell et le type C Shell, et même si la même commande UNIX a des options différentes selon le système d'exploitation, la portabilité est faible. Il avait l'inconvénient d'être lourd.
Pendant ce temps, Perl est né pour résoudre le mécontentement des scripts shell. Il comprenait les fonctions de shell, sed et awk, et implémentait de puissantes expressions régulières en plus des fonctions requises pour le traitement de texte. En traitement de texte, il est beaucoup plus puissant et plus rapide que la combinaison de commandes par le shell. De plus, en raison de la portabilité élevée que le même Perl fonctionne de la même manière, tout le monde a commencé à utiliser Perl.
Ensuite, Internet s'est propagé au grand public et est devenu une ère où de nombreuses personnes créent des sites Web. De plus en plus de gens veulent mettre non seulement du HTML statique mais aussi des pages dynamiques (CGI) telles que des compteurs et des babillards électroniques. À cette époque, Perl était une bonne option pour implémenter CGI. Puisqu'il s'agit d'un langage de script, il peut être utilisé simplement en le plaçant, un traitement de texte puissant tel que les expressions régulières est possible (traitement de texte si le crachement HTML est épuisé avec CGI), et il est installé en standard sous UNIX / Linux, il est donc facile à prendre en charge et à fournir Pour cette raison, il fut un temps où CGI s'appelait Perl.
De cette façon, Perl est devenu très populaire et a construit une époque, mais il y avait trois problèmes majeurs.
Si vous le faites d'une manière, tout le monde écrira le même algorithme, ce qui rendra le code plus propre et plus facile à lire. Et la maintenabilité est également améliorée. Python a été créé sur la base de l'idée d'inversion. Les retraits sont parfois utilisés dans un style qui n'est pas souvent trouvé dans d'autres langues, comme le blocage, et la lisibilité est exceptionnelle. Il est devenu le langage suprême pour une programmation bien conduite.
PHP a été créé avec l'idée que si vous intégrez le code dans le HTML au lieu de créer le HTML avec le code, vous n'aurez pas besoin d'une instruction d'impression redondante. De plus, en compilant et en installant ensemble le module Apache appelé mod_php, nous avons pu éliminer le lent démarrage du processus propre à CGI. C'est devenu le langage idéal pour créer de petites pages Web dynamiques.
Ruby a été conçu et créé comme un pur langage orienté objet depuis le début. Sans parler de Perl, Python était également orienté objet, donc j'étais insatisfait des spécifications du langage que je considérais comme orientées objet (PHP est également orienté objet). Puisque Ruby est un langage orienté objet à part entière qui utilise tout comme un objet depuis le début, il est devenu un langage qui peut être écrit très simplement lors de la programmation orientée objet.
Perl a une longue histoire et a une longue journée, et au départ c'est plus que d'autres en termes de nombre de bibliothèques, de nombre de codes de référence, de nombre de sites et de livres d'information japonais, de savoir si des normes OS sont disponibles, etc. C'était supérieur. Cependant, dans les temps modernes, toutes les bibliothèques nécessaires pour d'autres langues sont disponibles, il existe de nombreux codes de référence, de nombreux sites et livres d'information japonais, et des packages sont préparés pour chacun sous Linux. Bien sûr, le dernier Mac OS X a les quatre langues installées depuis le début. En d'autres termes, on peut dire que la différence environnementale a complètement disparu.
Il est préférable de faire un choix qui convient à chaque objectif car c'est une telle époque. Si vous voulez conserver l'ancien code, vous pouvez le laisser en Perl, si vous voulez mettre l'accent sur la maintenabilité, vous pouvez utiliser Python, PHP est le meilleur pour une petite page dynamique Web, et si vous voulez écrire docilement avec l'orientation objet, Ruby Tu peux l'utiliser.
Et c'est ennuyeux quand c'est fini, alors je vais tourner mon point de vue vers l'avenir.
On peut dire que le Perl 5 actuel est déjà mort. Cela ne veut pas dire qu'il ne se développera plus, mais qu'il est stable. Tant qu'il s'agit de Perl5, le code que je viens d'écrire fonctionnera à l'avenir, et le code que j'ai écrit il y a 10 ans fonctionnera bien.
Cependant, Perl 6 sortira dans le futur. On dit que Perl 6 est un langage complètement différent, tronquant la compatibilité descendante. Perl 6 peut être accepté comme un autre langage, mais il est peu probable qu'il soit considéré comme la prochaine version de Perl 5. Cependant, il est certain que Perl 5 prendra sa place dans le langage successeur qui en aura profité. Continuera-t-il son déclin progressif ou renaîtra-t-il sous le nom de Perl 6, et peut-il s'appeler Perl? L'avenir invisible continue.
Le Python actuel maintient Python 2 et Python 3. Python2 et Python3 ont une certaine incompatibilité, et la réécriture est presque essentielle. De nombreux outils de migration sont disponibles, mais ils ne semblent pas aller de l'avant. C'est parce que de nombreux systèmes d'exploitation utilisent toujours Python 2. Il existe de nombreux outils auxiliaires qui forment la base d'un système d'exploitation en Python. Et c'est fait en Python2. Pour passer à Python3, il est nécessaire de réécrire, et il est nécessaire de vérifier depuis le début ce qui fonctionne actuellement de manière stable. Il est préférable de le maintenir en cours d'exécution sur Python2, qui est actuellement en cours d'exécution. Après tout, le Python installé en standard dans le système d'exploitation restera Python2, et les outils créés en conséquence seront Python2. Oui, il n'y aura jamais de passage à Python3.
Cela peut être ironique car Python a réussi dans Python2. Il est normal que Python3 soit beaucoup plus propre sur le plan linguistique, mais le jour viendra-t-il où Python3 deviendra courant?
La troncature de la compatibilité PHP peut être célèbre. La troncature de compatibilité linguistique se produit généralement dans les versions principales. Perl change beaucoup à 5-> 6, et Python en tronque à 2-> 3. Ruby coupe également une certaine compatibilité avec 1.8-> 1.9 (1.9 était à l'origine positionné comme une version de développement de 2.0). Cependant, PHP est tronqué dans la version mineure. Au début, il sera traité comme obsolète, mais dans la prochaine version, une erreur se produira. En d'autres termes, il y a beaucoup de codes qui ne fonctionnent pas simplement en changeant deux versions mineures. Et PHP ne prend en charge que jusqu'à deux versions mineures. Si les développeurs ne maintiennent pas indéfiniment l'ancien code, ils ne fonctionneront qu'avec les versions vulnérables.
Et il n'est pas clair que PHP7 soit à côté de PHP5. De cette manière, les directives de développement PHP ont été critiquées de diverses manières. Le PHP que vous avez écrit cessera probablement de fonctionner après quelques années. Le dilemme continue, qui n'a d'autre choix que d'être maintenu pour toujours.
Ruby avait également une certaine troncature de compatibilité avec 1.8-> 1.9, mais comme je ne l'ai pas tellement utilisé au départ, le dernier système d'exploitation a commencé à adopter la version 1.9 ou ultérieure (la 1.8 n'est plus prise en charge). (Bien qu'il y en ait). Depuis la version 1.9 et les versions ultérieures, la compatibilité est presque maintenue, il n'y a donc pas lieu de s'inquiéter de la compatibilité comme les autres langues.
Mais combien de personnes utilisent Ruby après tout? Il est devenu célèbre pour Ruby on Rails, mais les avantages d'avoir Rails sont perdus à mesure que de plus en plus de frameworks similaires émergent. Une simple application Web ne peut pas correspondre à PHP, et la lisibilité et la maintenabilité ne peuvent pas correspondre à Python. Les inconvénients d'être lent, d'avoir un petit environnement et d'avoir un petit nombre de bibliothèques ont disparu, mais cela ne signifie pas que d'autres langages présentent des avantages. Après tout, j'ai le sentiment que les passionnés d'objet l'utiliseront pendant longtemps.
Enfin, maintenant que JavaScript est utilisé au-delà d'un simple langage Web. Il existe également un node.js côté serveur, qui pourrait briser Perl et ses bastions dérivés Python, PHP et Ruby à l'avenir. Cependant, la spécification de langage de JavaScript elle-même est trop mauvaise pour être utilisée telle quelle. Comment le langage qui se compile en JavaScript appelé Alt JS et le prochain ECMAScript 6 vont-ils évoluer, et dépasseront-ils l'ancien Perl? L'avenir reste incertain.
Recommended Posts