"Comparer les langages de programmation sur une base meilleure-pire est une occupation complètement idiote."

Avertissement : oui, lundi, nous avons publié un habrapost avec une telle comparaison des langues. Non, nous ne sommes pas fous. Tout se passe comme prévu.

Vitaly Bragilevsky combine la connaissance de l'informatique théorique et la pratique de programmation actuelle. Il enseigne des disciplines liées à l'informatique théorique, est membre du comité de normalisation Haskell et membre du comité de supervision pour le développement du compilateur GHC Haskell.

Cette habrastatya est une grande interview de Vitaly sur les sujets suivants:

• Enseigner et se familiariser avec JavaScript;
  
• Pourquoi choisir Haskell;
  
• La place des langages fonctionnels dans la vie d'un programmeur;
  
• À quoi sert JavaScript et comment évolue-t-il?
  
• Ce qui apparaîtra dans les langages de programmation au cours des 10 à 15 prochaines années;
  
• Quels langages de programmation sont crédibles et pourquoi;
  
• Quelle est la différence entre les conférences scientifiques et les conférences de développeurs. Pourquoi un enseignant irait-il même jusqu'à eux?
  
• Est-il important de lire au programmeur, les livres sont-ils obsolètes et lesquels doivent être lus?
  

Les entretiens sont menés par les membres du comité du programme de la conférence HolyJS 2019 de Moscou , Alexei Zolotikh et Artyom Kobzar. Si l'entretien ne vous suffit pas, alors très prochainement, lors du prochain HolyJS, Vitaliy vous dira et montrera avec des exemples comment connecter JavaScript à la théorie des algorithmes.

À propos de l'enseignement et de la connaissance de JavaScript

Artyom : Parmi nos auditeurs, en particulier au sein de la communauté JavaScript, vous n'êtes pas très connu, veuillez nous parler de vous, de ce que vous faites, de vos passe-temps - travailleurs, professionnels, peut-être inactifs.

Vitaliy : J'enseigne principalement, donne un cours à l'Université d'État de Saint-Pétersbourg et participe périodiquement à d'autres travaux. Depuis que je suis professeur, j'ai dû étudier beaucoup de sujets différents. Comme cela se produit généralement dans une université, il est nécessaire de lire un cours particulier, et pour cela, vous devez comprendre tout cela.

Il se trouve que j'ai enseigné beaucoup de choses. Par exemple, un de mes tout premiers cours spéciaux, qui m'avait été assigné dès la première année de travail, quand j'étais très jeune, s'appelait "Web XML-technologies". Ensuite, ce sont des sujets d'actualité, Ajax est juste apparu en JavaScript, et il n'y avait vraiment pas de littérature. J'ai expliqué comment utiliser tout cela.

Depuis, personne n'a vraiment compris comment l'utiliser, tout se limitait à des exemples comme celui-ci: il y a deux listes déroulantes, l'utilisateur sélectionne un élément dans l'une des listes, une demande est envoyée au serveur et vous recevez des données pour remplir la deuxième liste déroulante. C'était une nouveauté, il y avait peu de tels sites sur les sites. Ensuite, seule la recherche Google est apparue en mode bêta, lorsque, pendant que vous commencez à taper une sorte de requête, il vous dit de continuer. Les trucs d'Ajax étaient nouveaux et je les ai enseignés.

Ce que je n'ai pas enseigné seulement après cela: des choses à la fois mathématiques et programmées. Il était une fois je suis tombé sur Haskell, et depuis lors, c'est devenu le principal domaine d'attraction, ce que j'ai fait. En plus d'enseigner, d'étudier tout en informatique en général, pour enseigner, j'ai commencé à collaborer avec la maison d'édition "DMK-press", j'ai traduit plusieurs livres pour eux (avec d'autres personnes, j'ai édité quelque chose moi-même). C'était tout autour de Haskell aussi. Peut-être que ces deux types d'activités - l'enseignement et ce qui est associé à la traduction de livres en russe - c'est la principale chose que j'ai faite.

Artyom : Autrement dit, nous avons directement appelé un vétéran JavaScript. J'ai trouvé Ajax et probablement PHP.

Vitaliy : Oui, j'ai même programmé en PHP dans les toutes premières années, écrivais plusieurs sites.

À propos des raisons de choisir Haskell

Artyom : Vous êtes le plus célèbre de la communauté Haskell. Pourquoi vous êtes-vous arrêté à Haskell et cet écosystème?

Vitaliy : Comme je n'ai jamais envisagé une carrière de programmeur pour moi-même, j'étais libre dans ce que j'aime. Je n'avais pas besoin de m'intéresser à ce qu'ils payaient plus. Quand j'ai découvert Haskell, j'ai vraiment aimé. Ce n'est pas très bon d'en parler, et je me suis même permis de dire quelque chose comme «Haskell est une langue pour les gens intelligents dans la communauté anglophone, et la communauté est plus intelligente en moyenne.» Les Américains m'ont battu pour cela, et ils ont raison. Mais c'est exactement ce qui m'intéressait.

C'est-à-dire qu'à un moment, alors que j'étais encore aux études à l'université, j'étais engagé dans des mathématiques plutôt rigoureuses, donc passer à un sujet de programmation relativement dur était très naturel pour moi. En général, il est clair que, parmi les langages de programmation utilisés dans la production, Haskell est l’un des plus gourmands en sciences ou en ressources. Toute cette abstraction qui s'y trouve est la plus proche des mathématiques. Par conséquent, pour moi, c'était un choix naturel.

A propos des langages fonctionnels et de leur place dans le monde des programmeurs

Alexei : Que pensez-vous des langages dynamiques et fonctionnels? Et les choses comme Lisp?

Vitaliy : J'aime me positionner non pas tant en tant que Haskellist, mais en tant qu'amoureux des langages de programmation en général. Premièrement, il est clair que toutes les langues ont le droit d'exister. Je crois que comparer les langages de programmation sur une base «mieux-pire» est une occupation complètement idiote. Malheureusement, cela se fait souvent dans les réseaux sociaux et pas seulement, mais cela n'a aucun sens.

J'aime apprendre les fonctionnalités des langages de programmation et classer en quelque sorte les langages de programmation selon ces fonctionnalités. Mais considérer que c'est une bonne fonctionnalité, et c'est mauvais, c'est stupide. Par conséquent, il est clair que les langues à typage dynamique ont certainement le droit d'exister. Par exemple, maintenant dans mon cours pour étudiants de première année, j'ai pris le langage de programmation Julia comme base. C'est un langage dynamique, il y a un système de type. C'était intéressant pour moi de lui apprendre, en même temps de voir ce domaine d'applicabilité.

En général, le premier langage fonctionnel que j'ai rencontré était Lisp. Il y a de nombreuses années, quand j'ai lu le livre «La structure et l'interprétation des programmes informatiques» , tout cela impressionne. Par conséquent, je m'intéresse beaucoup à tout cela. Par exemple, j'aime aussi beaucoup JavaScript, car je connais bien son histoire.

Je sais que quand il est apparu pour la première fois, cela aurait dû être quelque chose comme Lisp, car au début, la syntaxe d'origine ressemblait à Scheme. Et puis, plutôt, pour des raisons de marketing, il a été remplacé par un C-like, mais, bien sûr, les langages Lisp sont à l'intérieur, et cela m'impressionne.

En général, j'ai le sentiment que de nombreux amateurs de JavaScript ne le savent pas, et ils vont bien, mais je sais, donc je suis encore mieux. Donc, toutes les langues sont bonnes, et c'est intéressant pour moi de les étudier, c'est intéressant d'étudier le domaine de l'applicabilité, c'est intéressant de voir ce qui est rendu plus facile et plus pratique. Et en général, une telle comparaison des langues pour des tâches individuelles est également un domaine intéressant distinct, que j'aime traiter.

Ce qui est bon en javascript

Artyom : Pendant que vous prépariez le rapport, vous étiez en contact avec la nouvelle version de JavaScript, avec ce qui y était intégré. Que pouvez-vous distinguer de bonne, mauvaise, peut-être une solution intéressante du point de vue de la théorie des langages de programmation?

Vitaliy : Évaluer du point de vue de la variété des langages de programmation, bien sûr, la chose la plus intéressante en JavaScript est son modèle objet. C'est ce que c'était depuis le tout début. Le modèle prototype a une histoire très riche, il est super intéressant car pratiquement aucun autre langage moderne ne l'a maintenant.

Dans des langages comme C #, en utilisant des méthodes d'extension, ils résolvent le problème de l'ajout de méthodes aux objets existants. C'est ce que JavaScript était depuis le début, et là, il semble beaucoup plus naturel. Autrement dit, nous avons un prototype auquel nous ajoutons des méthodes, puis créons de nouveaux objets en fonction de celui-ci. Dans des langages comme C #, c'est plus artificiel, à mon avis.

J'étais intéressé de voir comment les modules sont ajoutés à JS. En JavaScript, depuis très longtemps, il y a eu des problèmes associés aux modules, pendant des décennies, vous pouvez dire, et je me demande comment ils ont commencé à faire tout cela. Parce que les modules sont un sujet théorique profond, il existe de nombreuses approches différentes pour leur mise en œuvre. Certes, je ne peux pas dire que j’ai étudié à fond cela, mais c’est ce qui me semble un cas intéressant dans le domaine du développement des langages de programmation. Autrement dit, comment ajouter des fonctionnalités au langage existant qui n'existaient pas auparavant.

C'est toujours intéressant car il y a quelques années à Haskell, on a tenté d'ajouter, disons, des modules plus corrects. Maintenant, nous pouvons dire que cette tentative a échoué, personne n'a commencé à l'utiliser. Il s'agit du soi-disant projet de sac à dos, c'est-à-dire qu'il semble être mis en œuvre, mais l'utilisation est si insignifiante qu'il est devenu clair qu'ils ont fait un bon nouveau système modulaire, mais cela n'a pas très bien fonctionné.

J'ai le sentiment, en discutant avec différents gars qui sont engagés dans JavaScript, que les modules de JS se sont avérés meilleurs. C'est vrai, je le sais très superficiellement. Je pense que l'opinion sur JavaScript est très influencée par le fait que vous pouvez y écrire du très mauvais code. Et si vous pouvez écrire du très mauvais code, quelqu'un doit l'écrire en grande quantité. Cela affecte négativement l'évaluation de la langue. Du point de vue de la théorie des langages de programmation, ce n'est bien sûr pas très bon.

Alexey : Avez-vous réussi à voir les dernières versions de JavaScript? Qu'est-ce qui a surpris outre le système de modules?

Vitaliy : Je ne peux pas dire que j'ai réussi. J'ai feuilleté quelque chose, mais pas très profondément. Je ne peux pas lister.

Ce qui apparaîtra dans les langages de programmation dans un avenir proche

Artyom : La théorie des langages de programmation est un environnement plutôt académique et, en principe, intéressant. Quelles sont les nouvelles fonctionnalités dans les langues qui vont apparaître dans 10 à 15 ans? Quelles recherches sont actuellement en cours dans ce domaine?

Vitaliy : Je dirais que le sujet le plus chaud en ce moment est la frappe progressive. C'est quand en même temps dans le programme il y a à la fois des parties typifiées et non des parties typées. C'est pour Python, pour JavaScript, c'est fait pour les langages de jouets. Autrement dit, nous pouvons, d'une part, combiner des parties typées et non typées, et d'autre part, nous avons un moyen simple d'étendre la frappe.

Autrement dit, nous faisons un prototype d'implémentation de quelque chose, comme cela a toujours été fait dans des langages dynamiques sans aucun type, puis nous commençons à accrocher des types sur des composants individuels, de plus en plus. Idéalement, nous obtenons un programme tapé avec tous les avantages. Il y a moins d'erreurs au moment de l'exécution, etc.

C'est peut-être l'un des développements les plus importants. Certains éléments sont déjà sous forme de bibliothèques, mais jusqu'à présent, il s'agit toujours d'un domaine de recherche. Si nous regardons les principales conférences sur les langages de programmation, il y aura certainement plusieurs sections consacrées à la dactylographie progressive, à la dactylographie. C'est quelque chose qui sera presque certainement inclus dans la plupart des langages dynamiques, car c'est très pratique. Il s'avère que la combinaison de deux mondes.

Depuis dix ans, la recherche se poursuit sur les types dépendants, lorsque le type dépend des valeurs. Le plus gros problème est qu'il efface la ligne entre l'étape de compilation et l'étape d'exécution, car au stade de la compilation, les valeurs spécifiques ne sont pas encore connues, mais les types doivent être vérifiés. Autrement dit, des valeurs spécifiques apparaissent dans l'exécution, mais les types doivent déjà être corrects.

Et là, vous devez déjà écrire une fonction dans laquelle le type du résultat change en fonction de la valeur transmise. Ce flou de la frontière entre le temps d'exécution et le temps de compilation est une chose très intéressante, il est également activement étudié en théorie depuis 10-15 ans maintenant et tombera presque certainement dans de nombreuses langues, principalement celles typées statiquement, car le système de type expressif dû à ce développement est considérablement augmenté.

Certes, il y a un inconvénient. Il s'avère que l'écriture de programmes peut être trop compliquée. Il semble que les types contrôlent tout, mais l'écriture est très difficile, alors parfois vous pensez qu'au diable ces types dépendants, prenez n'importe quel type et programmez-le.

Artyom : Ils le font ici.

Vitaliy : Cela peut aussi se faire avec un grand désir, parfois il n'y a nulle part où aller. Lorsque vous arrivez du serveur, vous ne comprenez pas quoi et jusqu'à ce que vous lanciez le programme, vous ne savez pas, vous devez encore utiliser de telles choses, même à Haskell, il n'y a nulle part où aller.

Comment Vitaly développe Haskell

Artyom : C'est drôle. Retour à Haskell. Vous êtes membre du comité Haskell 2020. À Podlodka, vous avez dit que vous ne faisiez rien, mais dans une interview, vous avez mentionné que vous travailliez toujours sur des familles simples et à fonctions limitées. Quelles autres choses spécifiques implémentez-vous, supervisez-vous ou participez-vous à la mise en œuvre, peut-être, de la nouvelle norme Haskell?

Vitaliy : Ce sont deux comités différents. J'ai deux comités. L'un est Haskell 2020, où rien ne se passe vraiment, c'est un comité mort. Son but est d'écrire une norme de langue, et elle ne sera certainement pas écrite. Cela semble mieux - «Comité pour l'élaboration d'une norme linguistique», mais ne fonctionne pas.

Le deuxième comité est appelé «GHC Compiler Supervisory Committee» - le Glasgow Haskell Compiler. J'y suis depuis un peu plus d'un an, sa tâche est beaucoup moins ambitieuse. Ce comité examine les fonctionnalités, les suggestions de modification du compilateur et la version du langage implémenté dans ce compilateur. Il existe un Haskell standard, mais il existe un Haskell implémenté par un compilateur spécifique. Voici un exemple d'une telle extension de langage: «familles de types simples». Il s'agit d'une tentative de faciliter la programmation au niveau du type en ajoutant des contrôles supplémentaires.

Certes, je dois dire qu'il y a un environnement assez libre, c'est-à-dire que je n'ai probablement pas suivi d'accessoires tout l'été et que je devais passer beaucoup de temps à ce comité, j'ai l'intention d'y revenir.

Ma tâche est la suivante - elle l'a fait: il y a une proposition décrite, je dois regarder, peut-être conseiller à l'auteur de finaliser quelque chose et finalement aller au comité avec une proposition soit de recommander l'inclusion dans le compilateur, soit de refuser. Après avoir soumis cette proposition, le comité discute et prend une décision - tout y est décidé collectivement.

L'une des phrases que je dois est liée au trait de soulignement dans les annotations standard. Lorsque vous ne pouvez pas spécifier complètement le type, c'est-à-dire qu'il y a des trous là-bas, et il est proposé de réformer ce système afin de tout analyser de manière uniforme. Les trous peuvent être dans des annotations standard, dans l'implémentation de fonctions. Une certaine approche unifiée est proposée.

Ce comité envisage des changements étroits dans le compilateur.

Artyom : Nous avons également un comité de normalisation - TC39. Au début, un certain arrive et il cherche un champion. Un champion est une personne d'un comité qui est prête à superviser ce site. Ensuite, pour autant que je sache, nous avons une graduation par étape. Il y a 4 étapes sur lesquelles la fonction se déplace. Zéro, c'est quand il n'y a qu'une proposition, un, c'est quand un champion est trouvé et une API de haut niveau est décrite, et ainsi de suite. Le quatrième est déjà entré dans la langue. La personne qui a fait la préposition et le conservateur participent aux réunions de ce comité et font la promotion de cette proposition. Comment ça se passe avec toi? S'agit-il simplement d'un comité qui décide ensuite à l'interne?

Vitaliy : Toute notre activité est ouverte, elle se déroule sur GitHub et partiellement sur des listes de diffusion ouvertes. L'auteur de la proposition arrive - alors que nous examinons la proposition, la mise en œuvre ne nous intéresse pas beaucoup. Cela peut être, cela peut ne pas être, nous ne l'analysons en aucune façon, rien n'en dépend. Tout d'abord, il y a une discussion par la grande communauté, tout le monde peut commenter cette proposition.

Puis, lorsqu'il s'est installé, l'auteur le soumet au comité, c'est-à-dire demande au comité de l'examiner. Le secrétaire du comité nomme un berger qui le supervisera. Il regarde, analyse, propose peut-être des améliorations ou, au contraire, essaie de justifier pourquoi cela n'a pas le droit d'exister, après quoi il émet une proposition de rejet ou, peut-être, de demande de révision ou d'acceptation. Le comité discute, prend une décision.

Et lorsque le comité décide que nous sommes d'accord avec ce pré-site, et qu'il passe au statut d'accepté, en principe, n'importe qui peut reprendre sa mise en œuvre. Jusqu'à présent, il peut n'y avoir aucune implémentation, nous prenons simplement une décision - oui, ce serait bien d'avoir une telle fonctionnalité dans le langage ou le compilateur, et nous avons une telle liste de sous-nœuds acceptés, mais non implémentés.

De plus, ce n'est plus la tâche du comité, alors n'importe qui fait une demande de pull au code source du compilateur, il y a des ingénieurs, l'équipe croise partiellement le comité, ceux qui décideront déjà si cette demande de pull est acceptée ou non.

Étant donné que le comité accepte d'accepter, c'est-à-dire, en principe, il est nécessaire d'accepter la demande de fusion, mais il y a des questions d'ingénierie, elle n'est pas codée ici, certains problèmes de performances sont résolus par l'équipe qui développe directement le compilateur. Ce n'est plus notre métier.

Alexei : Il s'avère que maintenant Haskell a des normes assez anciennes. Je vois qu'il y a Haskell 2010.

Vitaly : Oui, 2010, très vieux. Il y a eu plusieurs tentatives pour en écrire un nouveau. Il y avait une idée de publier des normes chaque année, mais, malheureusement, tout a échoué. En 2016, un comité 2020 s'est réuni, mais il n'a également rien fait. Il y a plusieurs raisons à des degrés de difficulté différents, pourquoi ce travail n'est pas en cours. Oui, la dernière norme de 2010, il n'y en a pas de nouvelle et il n'est pas visible qu'elle soit apparue.

À propos des cours et des nouveaux projets

Artyom : Revenons à votre activité principale, à l'enseignement. Je vous ai personnellement rencontré au cours de la théorie des catégories, ce que j'aime beaucoup. Vous dites que vous ne l'aimez pas. Quels autres cours avez-vous dont vous pourriez être fiers et ceux que vous pensez qu'il serait agréable de rencontrer? Par exemple, le cours peut avoir été avec des jambages, mais en principe, le programme narratif lui-même est très bon.

Vitaly : Premièrement, j'ai publié sur YouTube tous les cours que j'ai. Là, j'ai un cours sur Idris - c'est un tel langage de programmation avec des types dépendants, et même deux versions, je l'ai lu deux fois. J'ai également quelques cours sur le compilateur de langage Haskell là-bas. L'un est consacré aux questions de théorie des modèles. Je ne me souviens pas exactement du nom, mais il s'agit de la façon dont la théorie des types fonctionne directement dans le compilateur Haskell.

L'idée est simple: tout le code Haskell est compilé dans un λ-calcul assez simple, le soi-disant système F avec de petites extensions. C'est en fait dans le code du compilateur, et le cours se concentre sur la façon dont ces éléments de la théorie des types sont utilisés directement dans le compilateur.

Et il y a un cours dans lequel je parle généralement de l'histoire de l'inférence de type et de la façon dont l'inférence de type a été organisée au tout début, lorsqu'elle a été inventée dans les années 60, avant que l'inférence de type ne soit arrangée dans la langue Haskell, quelles sont les difficultés comment tout cela fonctionne.

Il y a un petit cours que j'ai enseigné à l'école d'été de mathématiques. Là, de temps en temps, comme on me l'a dit, ils suivent des cours d'informatique pour que les enfants se reposent. , , , , : . — — . , , , .

, , . - , , , , , , - . , - , . , , - - . .

. -, , , , , . , . , - , -, - , , . - , , - , . . , , .

, , , . , , , , , , .

: - ? , , . , , , , - .

: Computer Science Club. , , , . , .

10 . « GHC Haskell: ». GHC, , 40 , 10 . : .

, Haskell, , . , , . .

, 1-2 . . , , . , : , — , - , . , .

, , , . , , . , .

, , , , , . , .

: , JetBrains - , . ? , - ?

: JetBrains , Haskell , JetBrains Haskell- , .

: Haskell JetBrains?

: Haskell c JetBrains, . , .

: Haskell JetBrains?

: - Haskell JetBrains? , .

: , . ()

: . , Java, Haskell.

: , JetBrains?

: JetBrains Education. JetBrains Research — , Education — .

JavaScript-

: , , , JavaScript? , , , Elm, Haskell.

: -, . GHCJS , , , . Elm , Haskell, . , , - .

, , , . JavaScript .

, Idris — Idris PHP, JavaScript, . . , , JavaScript Haskell .

, - , — , — , .

— , , , , . , . , HolyJS , , , , , . — , .

, λ- , — λ-, , , . , λ-, , .

1936 , — . , .

: , ? Swift, , enum , Union, ?

: , , . : , , . , , Python , , .

, , Python, . , , , .

, , , , , . C#. C# : -, Microsoft Java, , , , Delphi, #, C# , Haskell, .

, . , JetBrains, Kotlin, . Kotlin, C#, Swift Apple, . , .

++ - , , , - , , , . , , , JavaScript , . , , .

, , .

: -, , , Mozilla Rust.

: , Mozilla — , , - open source-, . . , Rust , . , Rust , - , .

, Twitter — - Microsoft, , , C++ Microsoft Rust. , . , Rust. , , , , . , .

Rust , - , .

: ! , , , , , — , . , , , - , ?

: , , . , . -, , . . , , — . — , , . .

— , , -, , . , .

, , , . , , . . , , , , . - . . .

: ? , , , , , ?

: , . , , , , . , - , , , , . , . , — . , , .

, — .

: HolyJS ? , - ? , .

: , , , , , . , , . , .

, , AppsConf. . . , .

, , , . : « , ?». - , , : , , Twitter , Google . , .

. , , , , , , , .

, , , . — , .

Artyom : Une dernière question, peut-être chaotique. Avez-vous écrit un livre sur Haskell intitulé Haskell in Depth ?

Vitaliy : Malheureusement, le livre n'a pas été écrit dans le processus. C'est ce qu'on appelle un «programme d'accès anticipé». Et elle, malheureusement, a été ralentie, et je reprends lentement le travail. Environ la moitié est écrite là-bas, et la seconde moitié est retardée, pour laquelle j'ai très honte de ceux qui ont acquis cet accès anticipé.

Artyom : Voici un fait intéressant: il y a une opinion dans la communauté que les livres sur la programmation, surtout s'ils ne concernent pas les connaissances fondamentales, ne sont pas très bons, car les informations deviennent rapidement obsolètes. Comment, en tant qu'auteur du livre, avez-vous une telle expérience? Et avez-vous envisagé un problème tel que les informations que vous fournissez dans un livre peuvent rapidement devenir obsolètes?

Vitaliy : Bien sûr, je ne comprends pas comment les livres sont écrits en JavaScript - à mon avis, c'est une tâche impossible du tout. Avec Haskell, en ce sens un peu plus facile. Mais voici ce que je peux dire.

Lorsque nous étudions les mathématiques à l'école, ces mathématiques sont également généralement très dépassées. Ce sont des choses qui sont apparues il y a quelques milliers d'années, un théorème de Pythagore. C'est peut-être encore en cours d'implémentation, mais dire que quelqu'un mesure les hauteurs des pyramides en utilisant le théorème de Pythagore est quelque chose comme ça, ils utilisent généralement des roulettes laser ou quelque chose comme ça.

C'est à peu près la même chose ici. Si une personne est un grand professionnel dans quelque chose et utilise une technologie depuis longtemps, bien sûr, elle n'a pas besoin d'un livre. Eh bien, le livre n'est pas pour lui et est écrit, il est nécessaire pour entrer dans une sorte de technologie, pour commencer à comprendre cela. Et quand vous êtes déjà entré, vous avez d'autres sources de développement.

Il me semble donc que les livres n'iront nulle part. Lorsque vous commencez à apprendre quelque chose, vous pouvez bien sûr apprendre les langages de programmation par articles, mais dans la plupart des cas, le résultat ne fonctionnera pas bien. Le plus souvent, il s'agit du transfert de leurs idées sur un autre langage de programmation vers un nouveau. Vous ne reconnaissez pas les constructions idiomatiques de ce langage et ne savez pas comment l'utiliser correctement.

Donc, au début, il vaut mieux prendre le livre, le trier, obtenir la base. Qu'il ne décrive pas les dernières versions des bibliothèques, que quelque chose soit ajouté à la langue, tout est possible pour rattraper son retard. Pour obtenir la base, à mon avis, vous avez encore besoin d'un livre. C'est pour tous les langages de programmation, même pour JavaScript. Quoi qu'il en soit, nous avons besoin d'une certaine stabilité, un tel point de référence, auquel vous pouvez vous référer.

Soit dit en passant, c'est l'un des objectifs lors de l'écriture d'une norme de langue Haskell afin de créer un point stable dans l'histoire de la langue par lequel vous pouvez écrire un livre. De plus, d'une manière ou d'une autre, la langue peut se développer, mais il existe une norme, et tout élève peut s'y concentrer.

Il est intéressant de voir comment les livres jouent le rôle de standard pour de nombreux langages de programmation. Par exemple, Straustrup a écrit un livre sur C ++, et c'est un point auquel vous pouvez toujours vous référer. Le C ++ est allé de l'avant, mais lors de l'apprentissage du langage, il est tout à fait possible de se concentrer sur cette version, qui est décrite par Straustrup.

Artyom : Vous avez soulevé un sujet intéressant sur les ressources dont les gens ont besoin, qui n'apprennent pas la langue, mais veulent aller plus loin et aller de l'avant. Vous pouvez conseiller certaines ressources que vous utilisez pour étudier et des ressources qu'il serait bon d'étudier pour qu'un ingénieur se plonge dans une théorie. l'informatique, dans la théorie des types, ou, comme vous l'avez dit, éliminer une certaine ignorance d'un ingénieur?

Vitaliy : C’est difficile pour moi de donner un exemple, je ne peux pas du tout dire que j’ai des sources d’information régulières. Twitter est peut-être la source la plus importante pour moi. Il s'avère que tout me vient via Twitter. Des liens intéressants m'apparaissent, je les garde pour moi et les lis régulièrement. J'ai le sentiment qu'au moins à Haskell il n'y a pas une telle source, mais il y a beaucoup de gens respectés qui écrivent des choses sensées.

J'ai en quelque sorte essayé d'utiliser régulièrement Reddit à cette fin, mais d'une manière ou d'une autre, cela n'a pas fonctionné pour moi, je n'ai tout simplement pas assez de temps pour le suivre. Mais sur Twitter, de toute façon, tout ce qui apparaît tôt ou tard me vient. Regardé rapidement, intéressant - enregistré, puis lu.

Et donc, en général, pour recommander quelque chose dans le domaine de l'informatique ou de l'informatique, pour être honnête, je ne suis pas prêt, je ne connais pas un tel site ou ressource. Pour ceux impliqués dans les langages de programmation, une source importante est le site http://lambda-the-ultimate.org . Toutes les choses les plus intéressantes y apparaissent et une discussion est en cours. C'est une lecture incontournable pour ceux qui s'intéressent à la théorie des langages de programmation.

Que lire au programmeur

Alexei : Vous dites que les livres n'expirent pas. Y a-t-il une liste de choses incontournables à lire, ou juste vos livres préférés à recommander? Je parle de la théorie de la programmation, de la culture générale de l'ingénierie.

Vitaliy : On me demande périodiquement de faire une liste, je n’entreprends pas un tel travail, c’est une tâche très difficile.

Selon la théorie des langages de programmation, pour commencer à y entrer, il y a le livre de Pierce "Types in Programming Languages". C'est généralement une amorce pour commencer les types. Son premier tiers serait probablement utile à tous les programmeurs.

Mon collègue et moi traduisions un livre intitulé Introduction à la théorie des langages de programmation . Il est très petit, et il explique la sémantique formelle, l'inférence de type, les choses théoriques de la compilation. Une telle introduction utile aux langages de programmation.

Il y a un livre de Charles Petzold «Annotated Turing» . C'est un genre étonnant: l'auteur a pris un article de Turing de 1936, où Turing a décrit ce qui est devenu plus tard connu sous le nom de machine de Turing, et a écrit un livre épais qui explique cet article. Et l'article lui-même est aux pages 15. De plus, il y a une histoire de la vie de Turing lui-même, le contexte de cette tâche, comment tout s'est passé. Section par section, il donne un fragment de l'article et une explication de ce qu'il voulait dire.

Si nous lisons l'article maintenant, ce sera très difficile pour nous. Mais ce livre de Petzold est incroyable, il recrée tout le contexte et décrit l'article lui-même. Je le recommande à tout le monde, c'est une lecture très intéressante, élargit l'esprit. Il y a aussi le λ-calcul, car tout est proche, et des questions philosophiques se posent concernant les calculs.

Bien sûr, d'un point de vue technologique, je suis un grand fan du livre de McConnell «Perfect Code» . Il me semble que c'est aussi une lecture importante. Vous ne pouvez pas tout lire de suite, mais ouvrez-le simplement sur des pages aléatoires, lisez quelques pages et fermez-le. Il s'agit de la façon d'écrire du code.

Certes, j'ai récemment parlé avec plusieurs travailleurs mobiles, ils disent qu'un livre stupide dans lequel il n'y a rien d'utile. Mais il s'agit de savoir comment écrire un tel code afin qu'il vive longtemps, afin qu'il puisse être pris en charge, modifié. Peut-être qu'ils n'ont vraiment pas de tels besoins.

Oui, et il n'y a pas Swift, pas Kotlin, une sorte de Java là-bas, différents exemples dans différents langages dont les programmeurs modernes ne parlent plus vraiment de rien. Le livre a commencé deux millièmes. Mais je pense que pour tout programmeur, cette lecture est très utile. McConnell est toujours bon en ce qu'il confirme tout avec la recherche, dit: «Donc, nous avons fait telle ou telle étude, pourtant telle ou telle, et voici les résultats. Voyons ensemble comment écrire du code pour le rendre bon. »

Voici peut-être assez d'une telle lecture.

Artyom : Pour une solution plus spécialisée, je demanderai: vous avez recommandé la «mise en œuvre du compilateur moderne», qui est disponible en trois versions - Java , C et ML .

Vitaliy : Oui, c'est un livre sur les compilateurs. Je ne sais pas si tout le monde a besoin de le lire, c'est plus probable pour ceux qui sont intéressés par les compilateurs. Mais, oui, je l'aime bien - il est petit, et en travaillant avec lui, vous pouvez vraiment écrire votre propre compilateur. Je ne suis pas sûr que tous les programmeurs aient besoin d'écrire leur propre compilateur, mais si vous êtes soudainement curieux, les livres d'Appel sont vraiment intéressants, mais déjà quelque chose de restreint.

Maintenant, je ne me souviens plus de tout. Périodiquement, quelque chose surgit à la surface, car à un moment donné, je lis beaucoup. Par exemple, «La structure et l'interprétation des programmes informatiques» est également un classique qui est utile pour lire et faire des exercices. Même si je ne suis pas tout à fait d'accord, mais la lecture elle-même est très utile.

Vitaly Bragilevsky se rendra à la conférence HolyJS 2019 à Moscou les 8 et 9 novembre 2019 avec un rapport «JavaScript au service de l'informatique théorique». Les billets peuvent être achetés sur le site officiel .