Python’s Flying Circus épisode 2: vous aimez les Perl, mais aimez vous les Ruby ?

Publié le par
2

Après notre comparatif rapide entre Python et Perl, il convenait tout de même de présenter un autre langage de programmation concurrent: Ruby. Comme Python et Perl, Ruby est un langage libre, de très haut niveau, multi-plateforme, générique, multi-paradigme, et doté d’un typage dynamique fort.

Dans l’esprit, Ruby est cependant plus proche de Perl. Son créateur Yukihiro Matsumoto (dit “Matz”) s’est en effet inspiré de certains principes de Perl pour concevoir son langage. En particulier, il s’est opposé au Zen de Python1 selon lequel  “il doit y avoir une – et de préférence seulement une – manière de faire ce que l’on veut”. Dans une interview donnée en 20032, Matsumoto déclarait ainsi :

Ruby a hérité de la philosophie de Perl le fait de laisser plus d’une manière de faire la même chose. Je tiens cette philosophie de Larry Wall, qui est véritablement mon héros. Je veux libérer les utilisateurs de Ruby. Je veux leur donner la liberté de choisir .

Dans l’usage, Ruby est comme Perl, moins diffusé que Python. Il est très utilisé dans la programmation web grâce au succès de Ruby on Rails. Mais il ne faut pas oublier pour autant que ses compétences vont bien au-delà, et qu’il peut donc aussi nous être très utile. Il est d’ailleurs assez riche par défaut – de nombreuses fonctions existant par défaut sur Ruby devant être importée depuis des modules spécifiques dans Python. Après le passage de la version 1.9 à une version stable 2.0, qui doit avoir lieu sous peu, nous nous attacherons donc à vous montrer quelques unes des applications que l’on peut dessiner pour nos domaines avec ce langage.

  1. Lisible par exemple ici. [↩]
  2. VENNERS Bill, “The Philosophy of Ruby – A Conversation with Yukihiro Matsumoto”, 29 septembre 2003 [En ligne]. URL: http://www.artima.com/intv/rubyP.html [↩]

Florian CAFIERO

Ancien élève de l'Ecole Normale Supérieure Paris-Saclay et diplômé de l'Ecole nationale des chartes, Florian Cafiero est ingénieur de recherche en mathématiques appliquées aux sciences humaines et sociales au CNRS. Il enseigne les méthodes quantitatives appliquées aux sciences humaines à l'Ecole nationale des chartes.

More Posts - Website

Follow Me:
TwitterLinkedIn

Python’s Flying Circus épisode 1: Python vs. Perl

Publié le par
1

Jusqu’ici, le langage que nous avons utilisé a toujours été Perl. Mais nous ne pouvions pas, surtout vu l’intitulé de notre blog, ignorer trop longtemps un des langages “rivaux” de celui-ci: Python. Notons que le rapprochement entre le nom de ce langage et une célèbre troupe de comédiens britanniques ne vient pas que de mon appétence visiblement pas assez modérée pour les jeux de mots ; c’est bien en honneur des Monty Python, dont il était un grand admirateur, que Guido van Rossum a nommé en 1989 son nouveau langage de programmation de la sorte.

Le premier billet à propos de Python reprendra un sujet déjà largement débattu : Perl ou Python ?

Les points communs

Avant d’examiner les raisons qui feraient choisir un ou autre langage, commençons d’abord par comprendre pourquoi on peut hésiter entre ces deux langages.

Perl et Python ont tous les deux des usages variés

Même s’ils ont chacun des domaines de prédilection, Python et Perl sont tous deux des langages génériques, utilisables dans des contextes fort nombreux, en particulier grâce à  l’utilisation de bibliothèques spécialisées.

Perl et Python sont tous les deux multi-plateformes

Vous êtes un geek assumé travaillant chez vous sur une distribution obscure de Linux, mais à votre université, on s’acharne à vouloir accroître les profits de Microsoft ? Vous avez toujours votre brave vieux PC sous Windows XP, mais votre laboratoire s’est équipé en iMac 27 pouces Quad-Core flambant neufs (je m’adresse là à d’éventuels visiteurs qui ne seraient pas dans la recherche publique française, bien entendu) ? N’ayez crainte! Aussi bien Perl que Python peuvent être utilisés quel que soit le système d’exploitation. C’est un magnifique avantage pour les situations plus ou moins crédibles que nous venons d’évoquer, et pour beaucoup d’autres d’ailleurs. Mais ce n’est donc pas un facteur de choix entre ces deux langages.

Perl 6 et Python 3 ne sont pas rétro-compatibles

Quand vous apprenez l’un ou l’autre de ces langages, vous apprenez un langage qui n’est pas compatible (ou du moins, pas fait pour être compatible) avec ses versions antérieures. Ce point peut-être gênant si vous cherchez à intégrer votre travail à un projet réalisé avec une version antérieure de ces langages. Des solutions ont été proposées de chaque côté. Du côté de Perl, un mode de compatibilité a cependant mis en place pour aider la portabilité entre Perl 5 et Perl 6. Du côté de Python, par contre, on a choisi de continuer à améliorer Python 2 au fur et à mesure des actualisations faites pour Python 3 – le but étant que les utilisateurs de Python ne soient pas obligés d’apprendre la nouvelle version pour bénéficier de ses améliorations. Mais si vous êtes un nouvel utilisateur de Python et que vous voulez produire un travail compatible avec Python 2, il vous faudra apprendre et Python 2 et Python 3.

Perl et Python utilisent un typage dynamique

La chose peut paraître anecdotique – mais elle me permet de revenir sur un des points du “hello world!”.  Comme Jean-Baptiste le faisait remarquer, C++ demande à l’utilisateur de déclarer le type de la variable qu’il crée: s’agit-il d’un nombre entier, d’un nombre réel (“à virgule flottante”, si on aime cet anglicisme), d’une chaîne de caractères etc.  ? On parle pour les langages agissant de la sorte de “typage statique”. A l’opposé, pas plus Perl que Python ne vous demanderont cette information.  Ils utilisent un “typage dynamique”. Jean-Baptiste ayant déjà illustré ce point sous Perl, je me charge uniquement d’expliciter ce phénomène sous Python. Plutôt que de demander la nature d’une variable (son “type”), Python va regarder ses attributs pour déduire de lui-même le type. On parle de “duck typing”: si je vois un oiseau qui nage dans une mare, doté  d’un joli col vert et de palmes jaunes, qui se manifeste par des “coin-coin” aussi élégants que sonores, j’appelle cet oiseau “canard”1. Python fait de même: si je lui crée trois variables de types différents, il observe leurs caractéristiques et infère leur type.

Ainsi, Python reconnaît-il sans aide que la constante de Planck est un nombre réel (float), que 42 est un entier (int – pour “integer”) et que “coin coin” est une chaîne de caractères (str, pour “string”).

Les différences

Python: un langage plus rapide ?

Pour la plupart des tâches testées, l’exécution d’un code Python se fait plus rapidement que celle d’un code Perl2. Avouons-le, ce dernier point n’est pas crucial dans la plupart des applications en littérature et en sciences humaines – mais selon vos utilisations, il peut tout de même avoir de l’importance.

Python: un langage plus simple ?

De l’avis de beaucoup, et en particulier depuis la version 3 de Python, ce langage est globalement plus simple à apprendre. Un de ses avantages est ainsi d’avoir été conçu pour que chaque tâche ne puisse être exécutée que si l’on écrit un ensemble précis et unique de lignes de codes. En résulte un code  lisible et facile à maîtriser. A l’opposé, en Perl, il peut exister beaucoup de solutions différentes pour réaliser la même opération, ce qui rend difficile, même pour un utilisateur avancé, de lire le code d’un autre programmeur. C’est ce point qui a probablement le plus aidé à la diffusion de Python, plus répandu que Perl aujourd’hui.

Perl vs. Python: littéraire contre scientifique ?

A ce stade, avouons-le, on ne voit pas bien pourquoi certains pourraient préférer Perl à Python. Pourtant, Perl a lui aussi des avantages clefs, en particulier pour les domaines qui nous intéressent. Perl a ainsi été conçu pour extraire au mieux des informations d’un texte, et de générer des rapports à partir de ses analyses. C’est donc naturellement que Perl est devenu le langage de prédilection des linguistes – et qu’il peut être celui des philologues, voire des historiens, sociologues ou juristes voulant analyser des corpus textuels importants. Python est quant à lui plus à l’aise avec les tâches plus calculatoires, ou mathématiques en général, en particulier avec l’aides de modules comme  NumPy, SciPy, ou Matplotlib. Il est grâce à cela populaire dans des domaines comme la bio-informatique, la finance, et généralement pour l’analyse de données scientifiques. Bien sûr, Python ou Perl peuvent être utilisés sur les terrains de prédilection de l’autre  avec une certaine efficacité – mais nous y reviendrons dans de prochains billets.

Au final, le choix entre Python et Perl est délicat, et dépend de vos centres d’intérêts précis. En dehors de l’analyse textuelle, il  paraît clair qu’un expert en humanités devrait préférer débuter Python, qui reste plus facile d’accès que Perl. Pour l’analyse textuelle, Perl est probablement le bon choix – mais nous mettrons régulièrement ce choix à l’épreuve, en comparant l’efficacité de Perl et Python sur différentes tâches d’analyse de corpus au cours des prochains billets.

  1. C’est bien là l’origine de ce terme, rarement traduit en français – “duck typing” préservant une impression de sérieux, contrairement à “typage canard”. On trouve trace de cette expression et de ce raisonnement pour la première fois en 2000 dans la bouche d’Alex Martelli sur ce newsgroup. [↩]
  2. Les sources de ces tests sont trop nombreuses à citer. Juste en clin d’oeil à notre premier billet, on pourra par exemple consulter cette évaluation sur le blog d’Ivan Zahariev [↩]

Florian CAFIERO

Ancien élève de l'Ecole Normale Supérieure Paris-Saclay et diplômé de l'Ecole nationale des chartes, Florian Cafiero est ingénieur de recherche en mathématiques appliquées aux sciences humaines et sociales au CNRS. Il enseigne les méthodes quantitatives appliquées aux sciences humaines à l'Ecole nationale des chartes.

More Posts - Website

Follow Me:
TwitterLinkedIn

Du texte à l’écran : L’édition de textes à l’heure de l’électronique

Publié le par
3

J’ai assisté, le jeudi 4 novembre, à un Atelier organisé par l’École nationale des chartes et l’Università degli studi di Siena ad Arezzo, intitulé Du texte à l’écran : L’édition de textes à l’heure de l’électronique, dont le programme est disponible ici, et j’aimerais vous faire profiter des quelques notes que j’ai prises à cette occasion.

La matinée était consacrée, avec un parti-pris pratique appréciable, à la présentation d’expériences d’éditions, dont la diversité était un point fort. Ainsi, après un mot de bienvenue du directeur de l’ENC, Jacques Berlioz, la journée s’est ouverte sur une présentation, par Florence Clavaud, du travail qu’elle a effectué en collaboration avec le Groupe de recherche sur les pouvoirs et les sociétés de l’Occident médiéval et moderne (le GREPSOMM) pour convertir de façon semi-automatisée les 387 minutes correspondant à l’année 1437 dans la pratique de Pierre Christofle, notaire à Orléans, depuis le format Open document, utilisé  pour leur travail préparatoire par les chercheurs canadiens, au format XML TEI, adapté à une publication en ligne, qui ne saurait tarder, sur la plateforme d’édition électronique de l’ENC, ELEC. Camille Desenclos a ensuite poursuivi sur la TEI, avec la présentation du travail d’édition entrepris pour son mémoire de Master II et portant sur la correspondance active de l’ambassade du Duc d’Angoulême (1620-1621), corpus constitué de 87 lettres. Elle a montré en  quoi elle avait été amenée à opérer des choix d’encodage en raison d’une forme d’inadéquation de la TEI à l’édition de correspondances. Elle a également souligné qu’au sein du projet TEI, un groupe spécialement dédié aux correspondances travaillait à la définition de bonnes pratiques et à la création de nouveaux éléments et classes adaptés.

On s’est ensuite éloigné temporairement de la TEI, avec une présentation par Elisa Brunoni et Irene Giacomelli de l’édition digitale du Corpus Rhythmorum Musicum (IVe-IXe siècle), dirigée par Francesco Stella, édition très riche, notamment du côté de l’interactivité et des statistiques textuelles, concernant entre autres choses l’ordre syntaxique (vers par vers !) ou les cas employés. S’il est permis de faire une légère critique sur cette présentation, par ailleurs passionnante et concernant une édition très aboutie, on pourra déplorer le manque relatif de détails techniques sur la réalisation concrète de la base de données qui est derrière l’édition.

Pont entre les travaux des érudits français et italiens, la communication de Laura Gili s’est penchée sur les possibilités procurées par l’outil électronique pour les éditions multilingues. Elle a également introduit la question du lien entre édition papier et électronique, problématique qui a été ensuite reprise par Anne Rochebouet, qui a présenté l’intérêt indéniable de LaTeX pour les éditions critiques sous forme papier, tant en ce qui concerne la présentation d’un apparat critique sur plusieurs étages de notes, la mise en vis-à-vis de textes sur plusieurs colonnes ou sur deux pages, ou la typographie impeccable que permet ce logiciel de traitement de texte, certes un peu atypique à l’heure de l’hégémonie du WYSIWYG, mais dont l’efficacité n’est plus à démontrer.

L’après-midi s’est ensuite ouverte par une présentation, par Frédéric Glorieux et Vincent Jolivet, de Diple, modules et méthodes pour l’édition en ligne de documents TEI. Diple fournit plusieurs outils pour qui voudrait se lancer dans l’édition en TEI : un module de conversion de fichiers Open document en fichiers XML TEI ; le schéma TEI utilisé par ELEC ; un module, XREM, de génération automatique de la documentation d’un fichier XML ; une libraire PHP permettant de générer le site de consultation…  Devant tant d’outils permettant virtuellement de faire une édition électronique de façon automatisée, une question récurrente et fondamentale a refait surface : Peut-on faire une édition en XML sans connaître les balises ? Si l’on ne peut proposer de réponse univoque à cette question, on notera toutefois que, si des développements permettent d’automatiser la partie la plus technique du travail d’édition en ligne, la responsabilité des choix scientifiques, y compris en ce qui concerne le balisage, et leur justification repose nécessairement sur l’éditeur.

La dernière partie de cette journée a enfin été consacrée à l’exploitation des éditions électroniques, avec en premier lieu une intervention de Dominique Stutzmann sur l’exploitation de l’information paléographique du matériau écrit. La démonstration s’est appuyée sur l’exemple des différentes formes du s et des variations dans le système abréviatif. Une analyse en composantes principales exceptionnellement claire a montré sur le plan factoriel envisagé une division de la population en deux groupes selon un critère chronologique (avant ou après 1169). L’intervenant a également renvoyé à un article de Nicolas Mazziotta dans Corpus relatif à ces questions d’encodage des abréviations du français médiéval1 et souligné à la fois la multiplicité des initiatives actuelles et l’importance de l’élaboration d’une norme d’encodage, nécessaire à la pérennité et l’interopérabilité.

Ce fut alors au tour de Frédéric Glorieux et Renaud Alexandre de présenter le projet OMNIA, Outils et méthodes numériques pour l’interrogation et l’analyse de textes médiolatins2, en mettant l’accent sur le besoin de numérisation et de mise en ligne des ressources lexicographiques existantes et l’utilisation des documents numérisés « pour mettre en place des procédures de recherche formalisées et largement assistées ». Pour satisfaire à ce dernier objectif, il est indispensable de recourir à des outils de lemmatisation, de génération de tables de cooccurrence et d’interrogation chronologique. Nous ne pouvons en effet que souligner l’importance de ces besoins, pas uniquement spécifiques au latin médiéval, mais valant également pour les langues romanes médiévales3.

Last but not least, la journée s’est conclue par une intervention de Francesco Stella sur des Expérimentations de statistique linguistique sur un genre littéraire : l’épître latine. S’il est impossible de résumer en détail ici cette communication particulièrement riche, on s’attardera sur un point très intéressant soulevé dans le débat : faut-il lemmatiser ? En effet, dans une certaine mesure, lemmatiser c’est détruire de l’information linguistique, comme il a été souligné avec un renvoi aux théories de Michel Banniard, bâties en bonne part sur l’observation des formes. On ne peut néanmoins s’empêcher de constater, en consultant de nombreuses études de statistiques textuelles, et particulièrement en regardant « en bas » des tableaux d’occurrences, que l’importance  de certains lemmes dont beaucoup de formes différentes sont employées (et je pense particulièrement aux verbes) est masquée par l’absence de lemmatisation. En attendant de consacrer un billet entier à cette question, je me contenterai de noter ici, avec D. Stutzmann, qu’il serait intéressant d’étudier ce qui se passe au moment de la lemmatisation, c’est-à-dire l’utilisation des cas et des genres propre à chaque lemme, et de conclure avec l’ensemble des participants qu’une étude sérieuse se doit d’envisager à la fois l’utilisation des formes brutes et des lemmes.

Au moment de conclure ce billet, je m’aperçois que cette journée d’études a déjà fait l’objet d’un fort intéressant compte rendu, que je vous invite à consulter également, sur le blog de Dominique Stutzmann.

  1. Nicolas Mazziotta, « Traiter les abréviations du français médiéval. Théorie de l’écriture et pratiques d’encodage », Corpus [En ligne], n°7 | novembre 2008, mis en ligne le 13 novembre 2009, Consulté le 18 décembre 2010. URL : http://corpus.revues.org/index1517.html [↩]
  2. On trouvera une présentation générale de ce projet, datant de 2009, dans Bruno Bon, « OMNIA: outils et méthodes numériques pour l’interrogation et l’analyse des textes médiolatins (2) », Bulletin du centre d’études médiévales d’Auxerre | BUCEMA [En ligne], 14 | 2010, mis en ligne le 14 octobre 2010, Consulté le 18 décembre 2010. URL : http://cem.revues.org/index11566.html [↩]
  3. La question des outils existants  de lemmatisation pour l’ancien français ou l’ancien occitan fera d’ailleurs ici même l’objet d’un billet détaillé. [↩]

Jean-Baptiste Camps

Diplômé de l'École nationale des chartes et docteur en études médiévales de l'Université Paris-Sorbonne (la Chanson d'Otinel…, dir. Dominique Boutet ), Jean-Baptiste Camps est responsable pédagogique du master «Humanités numériques» à l'École nationale des chartes (PSL). [CV et liste des publications, voir : http://paris-sorbonne.academia.edu/JeanBaptisteCamps]

More Posts - Website

Follow Me:
LinkedIn

Identification automatique des noms propres

Publié le par
2

Voici un des premiers résultats de mes expérimentations avec Perl, à savoir un script qui permet, avec une marge d’erreur relativement faible (env. 1% dans mon corpus test1) d’identifier automatiquement les noms propres.

L’idée originelle est d’utiliser l’encodage « naturel» des textes, c’est-à-dire l’ensemble des  symboles et diacritiques traditionnels (ponctuations, accents, majuscules, etc.). En l’occurrence, pour les noms propres, cet encodage consiste en l’utilisation d’une majuscule au début du mot. Le problème principal réside alors dans la présence de majuscules également en tête de phrase (heureusement que nous ne prenons pas comme exemple un texte allemand contemporain !). Dans un premier temps, après avoir nettoyé tout ce qui ne nous est pas nécessaire, le script constitue donc deux listes. La première contient tout les mots commençant par une majuscule et ne se trouvant pas en début de phrase et qui sont donc nécessairement des noms propres ; la seconde, tous les mots se trouvant en début de phrase, qui peuvent être des noms propres, mais pas forcément.

#on récupère tout les mots qui commencent par une majuscule, sans être précédé par un point ou un guillemet.
@NomP = $texte =~ /[^.!?«»]\s+(\b[A-Z]\w+)/g;
@NomP = grep {/\w+/} @maj;
#Puis on récupère tout ce qui correspond à un point ou un guillemet, un espace, et une majuscule.
@debutPhrase = $texte =~ /[.!?«»]\s+([A-Z]\w+)/g;
@debutPhrase = grep {/[^\s.!?«»]/} @debutPhrase;

Maintenant que nous avons ces deux listes, nous avons d’ores et déjà récupéré une bonne partie des noms propres, mais il est encore possible d’améliorer le script et de faire diminuer le nombre de mots incertains (ceux de la liste @debutPhrase). Pour ce faire, on procède à une comparaison des deux listes (en incluant la variation du système bicasuel de l’occitan médiéval). Si le mot « indécis » correspond à un de ceux de la liste de noms propres, il est transféré dans cette liste2 :

Comparaison entre les deux listes (en incluant les variations graphiques)

De 57 mots dans la liste @debutPhrase, on passe à 40, dont seulement 6 vrais noms propres, chiffre qui est à opposer aux  460 noms propres trouvés, soit 98,71% de réussite, ce qui n’est pas si mal que ça (je suis bien sûr preneur de toute suggestion d’amélioration).

  1. Ce corpus test se compose d’une quarantaine de vidas, courts textes biographiques occitans du XIIIe siècle, racontant la vie d’un troubadour. [↩]
  2. Autrement dit, si notre mot qui porte une majuscule et se trouve en début de phrase apparaît ailleurs dans le texte, portant une majuscule, mais sans être en début de phrase, il s’agira d’un nom propre. Dans le cas contraire, la situation reste indécise : il peut soit s’agir d’un nom commun, soit bel et bien d’un nom propre n’apparaissant qu’une seule et unique fois dans le corpus [↩]

Jean-Baptiste Camps

Diplômé de l'École nationale des chartes et docteur en études médiévales de l'Université Paris-Sorbonne (la Chanson d'Otinel…, dir. Dominique Boutet ), Jean-Baptiste Camps est responsable pédagogique du master «Humanités numériques» à l'École nationale des chartes (PSL). [CV et liste des publications, voir : http://paris-sorbonne.academia.edu/JeanBaptisteCamps]

More Posts - Website

Follow Me:
LinkedIn

Réaliser un tableau d’occurrences lexicales avec Perl

Publié le par
Répondre

Voici un exemple des traitements que l’on peut réaliser (relativement) aisément avec Perl. Il s’agit ici d’un petit script permettant, à partir d’un fichier en entrée contenant plusieurs textes séparés par le symbole §, de créer un tableau au format csv contenant, pour chaque texte, le nombre d’occurrences de chaque forme.

Pour commencer, il nous faut nettoyer en supprimant les majuscules et la ponctuation du texte, contenu dans la variable $texte, puis créer une liste d’occurrences des formes du texte complet, sous la forme d’une table de hachage, en utilisant une sous-routine compteur dont il sera question plus loin :

$texte =~ s/\_|\t|\.|\:|\,|\;|\«|\»|\)|\(|\'|\~|’|…|\?|\n/ /g;
%occurrencesTexteComplet = &compteur($texte);

Une fois cette tâche effectuée, nous allons maintenant séparer le texte complet, en une série de sous-textes en utilisant le symbole § :
@sous_textes = split(/§/, $texte);

Nous pouvons à présent comparer les listes d’occurrences de chaque sous-texte avec celui du texte complet :

Comparaison des deux tableaux d'occurrences

Et voilà, il ne nous reste plus qu’à générer le fichier de sortie, au format csv, que l’on pourra par la suite ouvrir avec Calc (ou Excel), importer dans R, etc.

Mise en forme du csv

La sous-routine compteur

Il s’agit d’une sous-routine que Perl rend assez simple, car c’est le type de traitement pour lequel il a été conçu. Elle compte un à un les mots d’un texte, et, à chaque fois qu’un mot réapparaît, elle ajoute 1 au compteur :

La sous-routine compteur

Jean-Baptiste Camps

Diplômé de l'École nationale des chartes et docteur en études médiévales de l'Université Paris-Sorbonne (la Chanson d'Otinel…, dir. Dominique Boutet ), Jean-Baptiste Camps est responsable pédagogique du master «Humanités numériques» à l'École nationale des chartes (PSL). [CV et liste des publications, voir : http://paris-sorbonne.academia.edu/JeanBaptisteCamps]

More Posts - Website

Follow Me:
LinkedIn

Première quête: à la recherche d’Excalibur

Publié le par
Répondre

“What is your quest ?” Bien entendu, “to seek the Holy Grail”  (ou “Holy Gr@il” dans notre cas…). Mais pour s’aventurer dans une quête aussi périlleuse, on ne saurait s’aventurer sans armes. Et parmi les armes, il faut choisir: impossible d’apporter tous les types d’armes sur son dos, c’est bien trop lourd.

C’est à faire ce choix difficile parmi le vaste arsenal des armes informatiques disponibles que nous allons nous attacher dans les premiers moments de ce blog. Aujourd’hui, il est quasiment impossible de maîtriser le fonctionnement de tous ces outils disponibles, même pour un professionnel de l’informatique. Et dans la foule des langages de programmation et des logiciels disponibles, il est souvent difficile de se repérer : de quoi aurais-je besoin ? qu’est-ce qui sera le plus maniable ? le plus puissant ? le plus simple d’usage ? Au gré de nos propres expérimentations, nous vous livrerons donc des éléments vous permettant de discerner les outils informatiques qui seraient utiles à vos recherches.

Retour sur notre “hello world”: langage de haut niveau et langage de bas niveau

Dans notre premier billet, Jean-Baptiste nous montrait la différence de codage d’une instruction très simple – saluer nos visiteurs autant fois qu’ils le désirent – entre C++ et Perl. Plus généralement, cette différence est celle que l’on trouve entre des langages de plus ou moins “haut niveau”.

Qu’on ne se méprenne pas sur cette appellation: il ne s’agit pas de distinguer une élite de langages de programmation d’une sorte de plèbe informatique. Un langage dit de bas niveau est un langage qui se rapproche de celui qu’utilise la machine, le processeur. Le plus  bas niveau serait ainsi de coder directement ses instructions en binaire – ce qu’on n’a plus à faire depuis des décennies, pour notre plus grand bonheur. D’un peu plus haut niveau, on trouvera la programmation en hexadécimal, le langage assembleur, puis le C etc. Et assez haut, on trouvera par exemple Perl, ou son rival Python.

Les langages de bas niveau sont cruciaux dans nombre de domaines de l’informatique. Ils permettent d’exploiter toutes les capacités de la machine employée, en étant au plus proche se son fonctionnement. Ils sont également d’une très grande rapidité d’exécution. Cependant, dans le cas des recherches en humanités qui nous occupent ici, ces langages sont assez significativement dominés par des langages de haut niveau.

Comme le premier post le montrait, il faut beaucoup moins de lignes de codes pour écrire un programme avec un langage de plus haut niveau (C++ n’étant pas à proprement parler un langage de bas niveau, mais étant toutefois de moins haut niveau d’abstraction que Perl par exemple). Et qui dit moins de lignes de codes dit moins de temps passé à coder, moins de fautes de frappe ou d’étourderie commises en écrivant le programme – et donc moins de temps passé à s’énerver en cherchant les bogues… En bref, un langage comme Perl (mais il n’y a pas que lui) est plus maniable, plus rapide à coder, et d’une certaine manière plus “magique”: avec très peu de lignes, il fait faire une masse prodigieuse d’opérations à notre machine. Voilà peut-être notre Excalibur…

Pour ces raisons, nous ne présenterons que des langages de programmation de  (très) haut niveau au cours des prochains posts.

Florian CAFIERO

Ancien élève de l'Ecole Normale Supérieure Paris-Saclay et diplômé de l'Ecole nationale des chartes, Florian Cafiero est ingénieur de recherche en mathématiques appliquées aux sciences humaines et sociales au CNRS. Il enseigne les méthodes quantitatives appliquées aux sciences humaines à l'Ecole nationale des chartes.

More Posts - Website

Follow Me:
TwitterLinkedIn

Un premier pas avec Perl

Publié le par
1

Dans la perspective de choisir un langage de programmation pour réaliser des programmes de traitement textuel, je me suis décidé, pour commencer, à comparer deux langages, un de relativement bas niveau (en l’occurence C++, mais j’aurais également pu choisir Java) et un de plus haut niveau (en l’occurence Perl, mais j’aurais pu aussi choisir Python).

 

Le test consiste à réaliser, sans connaissance a priori de ces deux langages, en un quart d’heure ou une demie heure, un programme très simple, version un tout petit peu plus évoluée d’un hello world ! qui demande à l’utilisateur combien de fois il veut qu’on lui dise « Bonjour ! » et effectuant cette opération1 :

À gauche, le code C++, à droite le code Perl

Première constatation, Perl paraît à la fois plus concis et un petit peu moins précis (moins propre ?) puisqu’on ne déclare pas la nature de la variable. En dehors de cela, rien de trépidant. Ce qui est plus intéressant, en revanche, c’est que l’on dispose d’au moins une autre solution très simple en Perl (qui, admettons-le, a été créé pour faire des traitements textuels, ce qui n’est pas le cas de C++) :

Alternative en Perl

Et voilà ! En un mirobolant total de 3 lignes de code, c’est fait. Voilà qui aurait tendance à prêcher pour Perl, même si ça n’a pas la rigueur et la beauté abstraite du C++.

  1. Je précise que je ne suis pas informaticien de formation, et ai donc sur le sujet le regard, peut-être un peu naïf, du néophyte. Que les programmeurs veuillent bien m’en excuser ! [↩]

Jean-Baptiste Camps

Diplômé de l'École nationale des chartes et docteur en études médiévales de l'Université Paris-Sorbonne (la Chanson d'Otinel…, dir. Dominique Boutet ), Jean-Baptiste Camps est responsable pédagogique du master «Humanités numériques» à l'École nationale des chartes (PSL). [CV et liste des publications, voir : http://paris-sorbonne.academia.edu/JeanBaptisteCamps]

More Posts - Website

Follow Me:
LinkedIn