L'auteur de l'article discute des problèmes des langages de programmation modernes et des moyens de corriger les lacunes.Au cours des 18 dernières années, les gens ont inventé de nombreuses langues, parmi lesquelles, probablement, les plus populaires sont le swift, le kotlin et le go. Dans le même temps, la caractéristique distinctive du langage de programmation du 21e siècle est l'absence de toute caractéristique distinctive. La chose la plus agréable en travaillant avec de telles langues est que vous pouvez passer un week-end à en apprendre une et enfin dire que vous avez réussi à apprendre une nouveauté populaire, mais en fait vous n'avez rien appris de nouveau. Ils ne sont vraiment rien de nouveau. Tous les langages modernes sont créés sur la base d'une formule correcte et éprouvée, dont le nom est très probablement Objective-C, Java ou C.
Le «manque de nouveauté» peut être considéré comme une caractéristique valable, mais cette situation soulève une question. Sommes-nous vraiment confrontés aux langages du nouveau XXIe siècle, ou tout cela n'est-il que le reflet des mauvaises habitudes de programmation du XXe siècle?
Si j'inventais le langage, je n'essaierais pas de corriger le passé, mais j'essaierais de créer quelque chose qui fonctionnerait bien dans les conditions modernes, mais qui serait également capable de se développer et de résister à l'épreuve du temps. Si cela nécessite des solutions constructives radicales, qu'il en soit ainsi.
A bas la syntaxe!
La syntaxe des langues modernes reflète une tentative de faire entrer la liberté de la craie et du tableau noir dans les chaînes de l'ASCII. Certains éléments d'un enregistrement, tels que les signes arithmétiques ou les parenthèses, sont perçus plus ou moins naturellement. Mais un certain nombre d'autres désignations ne se justifient qu'en économisant des efforts en appuyant sur les boutons de téléscripteur.
La saisie de texte à partir du clavier n'est plus difficile. Nous ne sommes pas tenus de nous mettre dans une position où il est nécessaire de deviner le sens de la syntaxe. Des morceaux comme
(($: @ (<# [), (= # [), $: @ (> # [)) ({~? @ #)) ^: (1 <#) - un format d'enregistrement très court et volumineux (soit dit en passant, c'est un vrai morceau de code en
langage réel ), mais cela n'améliore en rien la lisibilité. Et, plus important encore, il est difficile de le "google" ou de le trouver sur stackoverflow.
On peut en dire autant des noms mystérieux des fonctions, des conventions des codes de retour et des attributs au sens obscur. Ils ont bien servi dans le passé, économisant beaucoup d'espace sur les cartes perforées, mais aujourd'hui, il est temps pour un repos bien mérité.
Quelque chose comme
FILE * test_file = fopen("/tmp/test.txt", "w+");devrait être transformé en
create file /tmp/test.txt for input and output as test_fileNous n'avons pas besoin de tous ces crochets, guillemets, astérisques et points-virgules (à moins, bien sûr, qu'ils ne transmettent vraiment pas l'idée plus clairement). La coloration syntaxique est tout à fait capable de remplacer complètement la notation syntaxique.
Certaines choses abondantes sont disponibles au 21e siècle: par exemple, la vitesse d'analyse, la mémoire de l'ordinateur, la recherche en ligne. D'autres ressources sont encore en prix: temps de développement, mémoire du programmeur, efforts consacrés à l'apprentissage des fonctionnalités du langage. Les modifications des règles d'écriture du code devraient déplacer l'attention vers des ressources moins chères et économiser des ressources plus chères.
À bas les types intégrés!
Vous connaissez probablement les
paradoxes JavaScript . Par exemple, tels que:
> 10.8 / 100
0.10800000000000001Ce résultat n'est pas propre à JavaScript. Et ce n'est pas du tout un paradoxe, mais un exemple d'adhésion absolument correcte à la norme respectée IEEE 754. Une implémentation similaire des nombres à virgule flottante se trouve dans presque toutes les architectures. Et ce n'est pas si mal, étant donné que nous essayons de caser un nombre infini de nombres réels en 32, 64 ou 256 bits.
Ce que les mathématiciens considèrent impossible, les ingénieurs incarnent par le rejet du bon sens pour une mise en œuvre pratique. Les nombres à virgule flottante dans l'interprétation IEEE ne sont pas du tout des nombres. Les mathématiques nécessitent l'associativité de l'opération de leur addition. Les types float et double ne sauvegardent pas toujours cette propriété. Les mathématiques exigent que l'ensemble des nombres réels comprenne des entiers, mais cette exigence n'est pas remplie même pour float et uint32_t de la même taille. Les mathématiques exigent que les nombres réels aient un élément zéro. Eh bien, à cet égard, la norme IEEE dépasse toutes les attentes, car les nombres à virgule flottante ont deux éléments zéro au lieu d'un.
Non seulement les nombres à virgule flottante ont des caractéristiques similaires. Les entiers intégrés ne sont pas mieux implémentés. Savez-vous ce qui se passe si vous essayez d'ajouter deux de ces nombres 16 bits?
0xFFFF + 0x0001Personne ne donnera une réponse exacte. Un instinct nous dit que le débordement donnera 0x0000. Cependant, un tel résultat n'est documenté dans aucune norme internationale. Dans la gestion de cette opération, tout le monde est guidé par l'approche C et la famille de processeurs x86. Alternativement, 0xFFFF peut résulter, ou une interruption sera déclenchée, ou un bit spécial indiquant un débordement sera stocké dans un endroit spécial.
De tels moments ne sont généralement pris en compte nulle part, et les règles de traitement de ces opérations diffèrent d'une langue à l'autre. Si les bizarreries à virgule flottante sont au moins fixées par la norme, alors la dernière question posée est, en principe, imprévisible.
Au lieu de cela, pour les calculs numériques, je suggérerais d'introduire des types de données d'une valeur définissable avec un point fixe et avec un comportement standardisé en cas de perte de précision ou dépassant la limite supérieure ou inférieure. Quelque chose comme ça:
1.000 / 3.000 = 0.333
0001 + 9999 = overflowed 9999
0.001 / 2 = underflowed 0Il n'est pas nécessaire d'ajouter tous les zéros de fin: leur présence doit être impliquée par la définition du type de données. Mais il est important de pouvoir choisir vous-même les limites maximales et minimales et ne pas dépendre de l'architecture du processeur.
Ces calculs ne fonctionneront-ils pas plus lentement? Oui, ils le feront. Mais posez-vous la question: à quelle fréquence devez-vous programmer l'informatique hautes performances? Je crois que si vous n'êtes pas un expert dans ce domaine, alors c'est très rare. Et si vous êtes engagé dans de telles tâches, vous utilisez à cet effet des équipements et des compilateurs spécialisés. Pour autant que je sache, un programmeur typique du 21e siècle résout rarement des équations différentielles.
Quoi qu'il en soit, rien n'empêche l'utilisation de types intégrés rapides, complexes et imprévisibles du passé comme alternative plutôt que comme option par défaut.
A bas la pratique des métalangages!
Il existe de merveilleux langages qui ont été inventés non pas pour effectuer des tâches, mais pour créer des langages capables de les exécuter. Raquette, Rebol et Forth ne sont que quelques exemples. Je les aime tous, jouer avec eux est un pur plaisir. Mais, comme vous l'avez probablement deviné, le plaisir de travailler avec la langue n'est pas le critère principal qui rend la langue universelle et populaire.
La possibilité de créer de nouvelles langues dans une langue pour effectuer une tâche particulière est un outil très puissant qui porte ses fruits lors de travaux de recherche indépendants. Malheureusement, si le code doit être clair non seulement pour l'auteur, alors en plus du code principal, vous devrez enseigner à d'autres personnes et au nouveau langage interne. Et ici les problèmes commencent.
Les gens veulent terminer la tâche et ne pas apprendre une langue qui aidera à faire le travail exactement une fois, et après cela, ils ne seront pas utiles. Pour les étrangers, l'idée de maîtriser votre langue est un investissement peu susceptible de porter ses fruits. Mais apprendre quelque chose de standardisé est un investissement pour la vie. Par conséquent, ils réécriront plutôt votre code et ne l'apprendront qu'à ce moment-là. Ainsi, d'innombrables dialectes apparaissent pour une sphère appliquée. Les gens discutent de l'esthétique, de l'idéologie, de l'architecture et d'autres choses sans importance. Et des millions de lignes de code sont écrites pour sombrer dans l'oubli en quelques mois.
Les gars de Lisp sont passés par là dans les années 80. Ils ont réalisé que plus les éléments de langage appliqués sont standardisés, mieux c'est. Ainsi naquit Common Lisp.
Et il était énorme. La norme INCITS 226–1994 comprend 1 153 pages. Ce record 17 ans plus tard n'a été battu que par C ++ avec la norme ISO / IEC 14882: 2011 (1338 pages). Le C ++ doit faire glisser un héritage insupportable, même s'il n'a pas toujours été aussi important. Common Lisp a été créé pour la plupart à partir de zéro.
Le langage de programmation ne devrait pas être si énorme. Ce n'est pas nécessaire. Il a juste besoin d'une bonne bibliothèque standard, remplie de toutes sortes de choses utiles, pour que les gens n'aient pas à réinventer la roue.
Bien sûr, il n'est pas facile de maintenir un équilibre entre la taille et la pertinence de l'application. L'expérience du C ++ dans la pratique a montré à quel point il est difficile. Je pense que pour parvenir à l'équilibre nécessaire, le langage du XXIe siècle devrait être affiné conditionnellement dans un certain domaine appliqué. Étant donné que la plupart des problèmes se posent maintenant précisément dans le domaine des applications commerciales, le langage devrait probablement se concentrer sur les problèmes commerciaux, et non sur le développement de jeux ou la conception Web.
Alors ...
La langue du 21e siècle doit être orientée vers les entreprises, utiliser des expressions de langage claires et ne pas dépendre des types intégrés. C'est super qu'une telle langue existe déjà! Que pensez-vous, de quoi parle-t-on?
Oui, c'est COBOL.
C'est l'une des premières langues de haut niveau, aujourd'hui majoritairement oubliée. Je dois admettre que j'ai intentionnellement décrit les anciennes caractéristiques de COBOL comme ultra-modernes et incroyablement prometteuses. Et je l'ai fait pour montrer une chose. Le code n'est pas écrit par des fonctionnalités linguistiques. Tu le fais.
Il est naïf de penser que la langue est responsable de la qualité du code, et que l'ajout de certains gadgets (ou leur suppression) peut automatiquement tout améliorer. À une certaine époque, les programmeurs n'aimaient pas Fortran et COBOL, par conséquent, ils ont inventé le C ++ et Java, afin de finalement arriver à une situation où, 20 ou 30 ans plus tard, ils détestaient également tout le monde.
Selon mes sentiments, la racine du problème se situe quelque part dans le domaine de la sociologie et de la psychologie, mais pas dans la programmation. Aimons-nous vraiment moins les langues? Et sommes-nous satisfaits de l'environnement dans lequel nous travaillons? Windows est vulnérable, Visual Studio est trop lent, il est impossible de quitter Vim. En fait, ce sont ces choses qui provoquent le mécontentement, et non le processus créatif lui-même.
Mais il faut toujours trouver celui à blâmer. En tant qu'ingénieurs logiciels, en partie responsables de la qualité des programmes, nous ne nous blâmerons pas, non? Par conséquent, nous recherchons des défauts dans les outils. Inventons de nouveaux COBOLs jusqu'à ce qu'un jour le soleil commence à briller plus fort, les oiseaux ne chantent pas plus fort et Windows commence à se charger en 2 secondes.
Mais ce jour ne viendra probablement jamais.
Par conséquent, si je voulais inventer le langage de programmation du 21e siècle, j'essaierais plutôt de trouver une nouvelle approche de la responsabilité. Ou une nouvelle façon de mieux maîtriser les outils existants. J'essaierais d'être plus attentif aux détails essentiels et de me débarrasser sans pitié de toute complexité inutile. Au lieu des langues qui entrent et se démodent, il y a toujours des choses fondamentales qui méritent d'être constamment repensées.
