Les langages disponibles pour une tâche

Les langages de programmation

Python, Java, Go, C, C++, C#, Haskell, OCaml, R, Ruby, PHP, Rust, Kotlin, Prolog, Node avec JavaScript, Node avec TypeScript, et Bash. Chacun dispose d’un éditeur, d’un bouton « Exécuter » et d’une zone de sortie, et chacun est réellement compilé ou interprété : si une tâche Java ne compile pas, vous voyez le message du compilateur.

Chacun peut s’accompagner de tests cachés, que présente un onglet « Tests », et d’un fichier de données à lire par le programme. Le cadre de test est celui du langage : pytest pour Python, JUnit 5 pour Java, go test pour Go et l’outil de test de Node pour les deux langages Node. En Bash, un test est un script qui réussit lorsqu’il se termine sans erreur. En C et C++, un test est une fonction dont le nom commence par test_ ; il réussit quand elle se termine et échoue quand elle plante ou qu’un assert échoue. En C#, c’est une méthode publique statique dont le nom commence par Test, qui réussit tant qu’elle ne lève pas d’exception. En Haskell, un test est une définition de premier niveau dont le nom commence par test_ et dont le type est IO () ou Bool : il réussit quand l’action se termine ou que la valeur est True. En OCaml, c’est une fonction de unit dont le nom commence par test_, qui réussit quand elle se termine ; en R, une fonction sans argument dont le nom commence par test_, qui réussit quand elle se termine, stopifnot() servant à la faire échouer. En Ruby, un test est une méthode de premier niveau dont le nom commence par test_, en PHP une fonction dont le nom commence par test_, et en Kotlin une fonction de premier niveau de même nom, toutes sans paramètre et réussissant quand elles se terminent. En Rust, c’est toute fonction marquée #[test], exécutée par le cadre de test de Rust, et en Prolog un prédicat test_ sans argument, qui réussit quand son but réussit. Chacun échoue en levant une erreur ou une exception.

Une application web en Python, Node, Go, Java et des sites statiques en HTML, CSS et JavaScript peut aussi être déployée depuis un dépôt GitHub public, à une URL qui lui est propre ; ce sujet fait l’objet d’une page dédiée dans ce manuel.

Ce qui diffère d’un langage de programmation à l’autre

Les paquets viennent du fichier de paquets du projet, en haut de l’arborescence et marqué « Paquets » : requirements.txt ou pyproject.toml pour Python, pom.xml pour Java, go.mod pour Go et package.json pour Node et TypeScript sur Node, avec des versions indiquées exactement. Ils sont récupérés dans un conteneur distinct puis fournis à l’exécution en lecture seule, et l’exécution elle-même n’a pas de réseau. Une nouvelle tâche s’ouvre avec un petit exemple à remplacer. Les élèves voient toujours le fichier et ne peuvent le modifier que si la tâche le permet. Bash, SQL, C, C++, C#, Haskell, OCaml, R, Ruby, PHP, Rust, Kotlin et Prolog n’ont pas de fichier de paquets, faute de réseau où un gestionnaire de paquets irait chercher.

Pour utiliser un fichier de paquets que vous avez déjà, importez-le en haut de l’arborescence, ou créez-y un fichier de ce nom : il devient la liste de paquets de la tâche plutôt qu’un fichier ordinaire. Une tâche n’en a qu’une ; pour passer une tâche Python de requirements.txt à pyproject.toml, renommez le fichier. Un pom.xml Java est lu pour ses propriétés, sa gestion des dépendances, son parent, ses BOM importés et ses portées, un paquet de portée test ne servant qu’aux tests, et seul Maven Central est accessible. Une tâche Java créée avant pom.xml garde son ancien dependencies.xml, qui fonctionne toujours ; collez-y un pom ou renommez-le en pom.xml pour en changer. Les fichiers de paquets ont leur propre page dans ce manuel, avec ce que chacun peut nommer et la façon dont les paquets sont installés.

Les éditeurs n’ont pas tous les mêmes atouts, et mieux vaut le savoir avant de choisir. Python offre la détection d’erreurs soulignées en rouge, la complétion, l’aide au survol et les signatures de fonctions, le tout calculé en lisant le code, jamais en l’exécutant. JavaScript et TypeScript sur Node soulignent les erreurs de syntaxe au fil de la frappe, alors qu’une erreur de type TypeScript n’apparaît qu’au clic sur « Exécuter », car c’est le compilateur qui en décide. Java, Go, C, C++, C#, OCaml, R, Ruby, PHP, Rust, Kotlin et Bash n’ont que la coloration syntaxique, sans rien de plus intelligent, et Haskell et Prolog s’affichent en texte brut, l’éditeur n’ayant pas de mode pour eux.

Quelques précisions que les enseignants demandent. En Java, la classe publique est toujours Main, et le code de départ la montre. Tout fichier Go est en package main. Bash est du vrai bash, donc les tableaux et [[ ]] fonctionnent. L’entrée standard est une zone sous le code, et comme read -p n’affiche rien sans terminal, le code de départ Bash affiche lui-même son invite en premier. Le C et le C++ sont compilés en C17 et C++20 avec les avertissements activés ; un avertissement s’affiche sans jamais empêcher l’exécution. Un programme C# s’écrit avec une méthode Main ou avec des instructions de niveau supérieur. Les tests sont ajoutés à la fin du programme, et le programme est chargé pour les exécuter : les codes de départ lisent donc leur entrée avec une solution de repli en fin de fichier. OCaml n’a pas de garde main : un let () = de premier niveau s’exécute aussi pendant les tests. Un programme R protège son main par if (sys.nframe() == 0) main(), comme le code de départ, ce qui est faux quand les tests chargent le fichier ; en R, readline() ne lit pas l’entrée standard dans un script, il faut utiliser readLines(file("stdin")). Un fichier de tests Haskell peut porter ses propres imports. Ruby et PHP protègent leur main par if __FILE__ == $0 et une comparaison de realpath, comme leurs codes de départ, et Prolog par :- initialization(main, main), si bien qu’aucun ne s’exécute pendant les tests. Un test Rust bloqué dans une boucle n’est arrêté que par la limite de temps de toute l’exécution. C#, Haskell, OCaml, R, Ruby, PHP, Rust, Kotlin et Prolog tournent sur une machine dédiée et non sur toutes : si elle est indisponible, l’exécution l’indique au lieu de démarrer, et réessayer un peu plus tard fonctionne.

Un programme qui écrit des fichiers, un rapport ou un graphique, les voit proposés sous la sortie dès la fin de l’exécution, cinq fichiers au plus en tout. Les fichiers texte peuvent peser jusqu’à 64 Ko, et une image PNG, JPEG ou WebP jusqu’à 1 Mo est aussi affichée sous la sortie, si bien qu’un graphique tracé avec matplotlib apparaît simplement. Ce que le programme a écrit est jugé sur son contenu et non sur son nom, un SVG n’est jamais affiché comme une image, et tout ce qui est écarté est signalé avec la raison. Les liens restent valables une demi-heure et lancent toujours un téléchargement, sans jamais s’ouvrir dans l’onglet.

Les tâches de plusieurs fichiers

Une page web se compose de HTML, de CSS et de JavaScript répartis dans trois volets, avec un aperçu en direct. Une tâche SQL réunit une requête et la base de données sur laquelle elle s’exécute, dans deux onglets. Pour un vrai shell, proposez un lab de conteneurs ou un lab VM.

Chacune fait l’objet d’une page dédiée dans ce manuel, car ce que l’enseignant prépare et ce que fait l’élève diffèrent d’un cas à l’autre.

Les tâches sans code

Il s’agit du devoir écrit, du quiz et de deux types de schémas. Ils se distribuent tous comme un programme, mais se corrigent différemment.

Questions fréquentes

Puis-je mélanger les langages dans un même module ?

Oui. Un module contient les tâches que vous y placez, quel que soit leur langage.

Quelle version de Python est utilisée ?

Python 3.13. La version est affichée dans l’éditeur lui-même, pour que personne n’ait à poser la question.

Les élèves peuvent-ils installer des paquets ?

Oui, dans toute tâche qui a un fichier de paquets, c’est-à-dire tout langage de programmation sauf Bash, C, C++, C#, Haskell, OCaml, R, Ruby, PHP, Rust, Kotlin et Prolog, à condition que vous l’ayez autorisé. Les élèves voient toujours la liste ; c’est la tâche qui décide s’ils peuvent la modifier.