Sortie de Julia 0.6

Julia est un langage de programmation de haut niveau, dynamique, mais orienté applications de haute performance (surtout pour le calcul scientifique). Malgré son jeune âge (il est apparu pour la première fois au grand public en 2012), il a déjà réussi à fédérer une certaine communauté (on estime à 250 000 son nombre d’utilisateurs en 2017), dans bon nombre de domaines.

Sa version 0.6 est sortie, un peu moins d’un an après la précédente. Elle marque le dernier jalon avant la version finale : la 0.7 et 1.0 sortiront presque simultanément, la seule différence étant la gestion d’anciennes syntaxes et l’émission de messages correspondants pour la 0.7 (ce dont la 1.0 ne s’alourdira pas).

Le plus gros changement de Julia 0.6 concerne le moteur d’inférence des types, qui a été complètement réécrit pour être plus rapide, donner des résultats plus précis (ce qui permet d’optimiser le code exécuté) et permettre de nouvelles fonctionnalités. Ainsi, en définissant un nouveau type avec des paramètres (comme une classe générique dans bon nombre d’autres langages), on peut faire référence aux types des paramètres précédents. Par exemple, avec struct Foo{R<:Real, A<:AbstractArray{R}}, on définit un type Foo par rapport à un type particulier de nombres réels (comme Float64) et un tableau (dont les éléments doivent avoir le même type que mentionné précédemment).

Au niveau syntaxique, les mots clés pour définir des types ont été changé pour promouvoir par défaut des valeurs immuables : le code généré est bien souvent plus rapide, cela réduit le risque d’erreur lors de l’écriture du code, avec un impact souvent minime sur l’utilisateur. Ainsi, type devient mutable struct tandis que immutable devient simplement struct.

Pour la performance, les opérateurs et fonctions sont tous vectorisés automatiquement à l’aide d’un point : a .⨳ b est la syntaxe équivalente à l’application de l’opérateur  entre tous les éléments de a et de b. L’avantage principal est que ce mécanisme est géré au niveau du langage, il n’y a plus de traitement particulier des opérateurs vectorisés. Grâce à ce changement, l’écriture de code très optimisé sur des vecteurs devient très facile : pour évaluer une expression utilisant une série d’opérateurs vectorisés, Julia n’exécute qu’une seule boucle à travers les opérandes.

Voir aussi : les notes de version de Julia 0.6.

En route vers Scala 3 : sortie de Dotty 0.1.2 RC 1

La version 0.1.2 RC 1 du nouveau compilateur Scala, Dotty, est sortie fin mai. Il s’agit d’une réécriture complète du compilateur Scala, avec des changements au niveau syntaxique. La 0.1.2 est spéciale en ce sens qu’il s’agira de la première version publique de Dotty, même si le projet est connu de longue date — son développement dure déjà depuis quatre ans, le compilateur peut se compiler lui-même depuis 2015.

Par rapport à Scala 2, la syntaxe est légèrement épurée : notamment, il n’y a plus moyen d’écrire directement du XML dans du code Scala ; le langage fournit moins de types, mais des constructeurs revenant aux fondamentaux. La différence principale par rapport à Scala 2 se situe au niveau théorique : Dotty se base sur le modèle de calcul DOT (plus simple que les machines de Turing ou le calcul lambda, par exemple, mais surtout plus adapté au code réel). Cela permet de réaliser des preuves formelles à propos de morceaux de code. Ce modèle de calcul est forcément réduit par rapport aux fonctionnalités du langage, mais la plupart des constructions syntaxiques peuvent se réécrire dans ce modèle.

Quelques nouveautés par rapport à Scala 2 peuvent déjà être notées, comme les types d’intersection (un objet passé en argument à une fonction doit posséder plusieurs traits) et d’union (au moins un trait).

def f(x: Resettable & Growable[String]) = { // Intersection : à la fois Resettable et Growable[String]
  x.reset()
  x.add("first")
}

def help(id: UserName | Password) = { // Union : soit un UserName, soit Password (soit les deux)
  // ...
}

Les traits peuvent aussi posséder des paramètres, tout comme les classes.

trait Greeting(val name: String) {
  def msg = s"How are you, $name"
}

Les énumérations font leur apparition.

enum Color {
  case Red, Green, Blue
}

Dès maintenant, les développeurs se forceront à produire de nouvelles versions régulièrement : des versions compilées chaque jour et des RC toutes les six semaines, ces dernières devenant des versions finales après six semaines.

Sources : Announcing Dotty 0.1.2-RC1, a major step towards Scala 3, 0.1.2 release notes.

Plus de détails sur DOT.

Des nouvelles de Flang, le compilateur Fortran basé sur LLVM

Après un an et demi de travaux, le compilateur Fortran basé sur LLVM promis par NVIDIA arrive enfin sur GitHub, bien que sans annonce officielle. Le projet a commencé avec un étudiant (financé par le programme Google Summer of Code) en 2013 sous le nom de Flang (analogue de Clang, le compilateur LLVM pour le C et ses dérivés), puis a été repris par NVIDIA et la sécurité nucléaire du département américain en 2015. L’objectif était de fournir un compilateur libre de très haute qualité, notamment basé sur celui de PGI.

Avec le développement de LLVM, ce projet apporte de plus en plus de promesses à l’écosystème Fortran. Par exemple, LLVM permet de compiler du code pour les GPU NVIDIA : grâce à Flang, il sera très facile d’offrir un compilateur libre pour ce faire (sans devoir utiliser celui de PGI). Également, OpenMP permet de décharger l’exécution du code sur un accélérateur : GCC ne le permet pas encore pour des cartes graphiques, uniquement les coprocesseurs Intel Xeon Phi ;  LLVM, quant à lui, gère les cartes NVIDIA et les coprocesseurs Intel Xeon Phi.

Pour le moment, Flang fonctionne avec LLVM 3.9 (presque la dernière version). Les sources de la version 1.0 sont en ligne depuis une semaine (avec des commits d’employés de NVIDIA et de PGI), mais aucune annonce officielle n’a encore été faite (la documentation fait référence à un site qui n’existe pas encore, http://flang.nvidia.com/). La norme Fortran 2008 est implémentée, mais aucune information n’est donnée sur le niveau de compatibilité (le compilateur de PGI n’implémente pas toute la norme). La grande différence par rapport au compilateur de PGI devrait être la qualité des messages d’erreur, du niveau de Clang.

Sortie de CLion 2017.1

JetBrains est une société spécialisée dans la conception d’environnements de développement. Ses produits les plus connus sont IntelliJ (un EDI indépendant d’abord orienté Java) et ReSharper (une extension C# pour Visual Studio), sans oublier PyCharm (pour Python) ou encore WebStorm (pour le développement Web). En 2015, la firme a lancé CLion, son EDI pour les langages C et C++, en partie dérivé d’AppCode (destiné, quant à lui, à la création d’applications iOS en Objective-C). À presque deux ans, voici la version 2017.1 de l’EDI, qui continue à gagner en maturité et à faire de l’ombre aux grands que sont Visual Studio ou encore Eclipse.

Au niveau des dernières fonctionnalités, on trouve principalement les nouveautés de C++14 et 17. De manière générale, presque tout C++14 est géré (tout sauf constexpr) : par rapport à la version précédente, ce sont donc le type auto, les fonctions anonymes génériques, les modèles variables (au lieu d’un nombre fixé de paramètres) et les captures généralisées. Côté C++17, seuls les espaces de noms imbriqués sont apparus (c’est l’apport de la nouvelle norme plébiscité par les utilisateurs) — le reste de la norme suivra dans les versions à venir de l’EDI. Cela signifie que tous ces aspects du langage bénéficient d’une coloration syntaxique et d’une complétion automatique, sans oublier une intégration aux mécanismes de navigation et de refactorisation du code ; par exemple, CLion peut déterminer le type que prendra une variable automatique afin de proposer l’autocomplétion en conséquence.

Une nouvelle intention est disponible. Elle permet de moderniser d’un clic un bout de code : plus précisément, de remplacer le type d’une variable par le mot clé auto.

Le débogueur a été l’objet de bon nombre d’attentions, avec la correction d’un grand nombre de défauts (notamment des temps d’attente expirés avec GDB). Un désassembleur est maintenant intégré, de telle sorte qu’il est possible de poursuivre l’exécution pas à pas y compris dans du code pour lequel les sources ne sont pas disponibles (une version future de CLion permettra d’accéder à ce désassembleur de manière autonome). Le code assembleur aura aussi une coloration syntaxique (même en dehors du débogueur), à condition de respecter la syntaxe AT&T et de ne pas utiliser de préprocesseur.

CLion est maintenant compatible avec de nouveaux outils de l’écosystème C++. Pour les tests, Google Test est géré depuis le début, Catch apparaît avec cette version. Le compilateur Visual C++ est aussi de la partie (versions 2013 à 2017), sous Windows, mais uniquement de manière expérimentale. Ainsi, CLion ne cherche pas automatiquement le compilateur, il faut l’activer manuellement (le résultat n’est pas encore parfait). msbuild n’est pas géré, CMake reste la seule manière de créer un projet avec CLion. Le débogueur de Visual C++ n’est pas intégré.

Ceci n’est qu’un aperçu des différences fonctionnalités apparues. On peut aussi compter la saisie sans délai (la latence entre l’appui d’une touche sur le clavier et l’impact à l’écran est le plus faible parmi tous les EDI !), la recherche dans un dossier avec prévisualisation automatique, une vue améliorée de l’historique d’un dépôt (avec possibilité d’utiliser des expressions régulières !) ou encore une extension pour les langages Swift (remplaçant d’Objective-C) et Go (un EDI spécifique est en cours de développement).

Télécharger CLion 2017.1.

Source et images : CLion 2017.1 released: C++14, C++17, PCH, disassembly view, Catch, MSVC and more.

Sortie de Mathematica 11.1

Sept mois après la version 11, voici que Mathematica 11.1 arrive. Cet environnement de développement complet continue d’apporter de nouvelles fonctionnalités au niveau de l’apprentissage automatique et de la visualisation, entre autres, avec une remise à plat de la présentation de l’aide. 29 ans après la première version publique de Mathematica, le logiciel continue de s’étoffer : 132 nouvelles fonctions, 98 autres améliorées. Il ne s’agit pas vraiment de pans complets de fonctionnalités (comme on avait pu le voir avec les réseaux neuronaux de Mathematica 11, par exemple), mais plutôt d’améliorations continues.

Apprentissage automatique

L’interface de très haut niveau pour définir des réseaux neuronaux de manière symbolique a continué son extension, notamment au niveau des réseaux récurrents et LSTM, sans oublier des couches pour gérer les séquences de longueur variable. NetEncoder permet d’encoder une entrée (comme une image ou du son) de n’importe quelle manière.

De manière plus générale pour l’apprentissage automatique, FeatureSpacePlot représente une série d’échantillons dans un espace de variables déterminé automatiquement, selon le type d’entrée.

De nouvelles fonctions ont fait leur apparition pour l’apprentissage de séquences (SequencePredict) et l’apprentissage actif, c’est-à-dire que Mathematica décide où évaluer la fonction à apprendre (ActiveClassification et ActivePrediction).

Toutes ces fonctions ne sont pas encore dans leur version finale, c’est-à-dire que leur interface pourrait encore changer dans les versions à venir. Cependant, une fois l’interface figée, elle ne changera plus dans le futur : des  programmes Mathematica 7 (2008) et plus anciens continuent de fonctionner sans modification sur les versions actuelles.

Audio et vidéo

Il devient plus facile de capturer l’information des micros (AudioCapture) et caméras de l’ordinateur (CurrentImage). L’affichage des cepstres d’un son devient aisé, tout comme l’application d’effets. TextRecognize peut aussi trouver la structure d’un texte (paragraphe, colonne, etc.).

Visualisation

Mathematica est connu pour la puissance de son moteur de calcul symbolique, mais aussi pour celle de ses visualisations. L’affichage de texte dans les graphiques s’est simplifié avec Callout, tout comme la mise à l’échelle des graphiques avec ScalingFunctions. BubbleChart permet d’afficher des bulles de taille variable.

Sources et images : The R&D Pipeline Continues: Launching Version 11.1, Summary of New Features in 11.1, Mathematica 11.1 Is Out Now!.

Feuille de route pour Scala 2.13

Dans la communauté Scala, 2017 sera l’année du développement de la version 2.13 du langage (la première RC devrait arriver début 2018). La version 2.12 est donc encore là pour un certain temps. La feuille de route est déjà établie pour Scala 2.13, avec les fonctionnalités souhaitées — modulo les autres envies de la communauté qui seront intégrées d’ici-là. Quatre axes ont été définis : une réécriture de la bibliothèque de collections, des améliorations de performance pour le compilateur, la modularisation de la bibliothèque standard, des simplifications pour les utilisateurs du langage.

Collections

La bibliothèque des collections de Scala est assez régulièrement retravaillée pour la rendre plus facile à utiliser, en améliorer la performance ou la qualité du code. L’itération actuelle date de Scala 2.8 et utilise un grand nombre de couches d’abstraction, très flexibles, qui généralisent tant les collections immuables qu’altérables, parallèles que séquentielles. Chaque nouvelle collection peut ainsi réutiliser une grande partie du code déjà écrit.

Cette implémentation a cependant un certain nombre de défauts. Principalement, pour créer de nouvelles collections, il faut se plonger en profondeur dans la documentation pour déterminer les paramètres implicites à utiliser et vérifier les fonctions héritées à réécrire. Les utilisateurs ne sont pas en reste : niveau performance, tout n’est pas parfait. Par exemple, Slick a pu grandement accélérer certaines étapes de calcul (de l’ordre de 25 % !) en réimplémentant certaines collections, sans chercher à adapter leur implémentation à leurs besoins.

Les modifications prévues visent principalement à réduire fortement l’utilisation de l’héritage pour les collections, tout en gardant un très haut niveau de compatibilité des sources avec l’implémentation existante (soit garder l’API l’existante, soit proposer un outil pour corriger automatiquement le code source). Les développements sont visibles sur GitHub.

Modularisation

La modularisation de la bibliothèque standard de Scala a commencé avec la version 2.11. L’objectif est de déporter une partie du code en dehors du cœur de l’implémentation du langage et de laisser la communauté proposer des solutions. L’avantage principal est que les solutions proposées peuvent évoluer nettement plus vite que Scala.

Un autre avantage est que le cœur peut garder une compatibilité binaire nettement plus facilement entre versions de Scala, ce qui limite les problèmes lors des mises à jour. Il faut noter que Scala laisse toujours accès à la bibliothèque standard Java, ce qui est loin d’être négligeable.

Avec Scala 2.13, la bibliothèque standard se réduira aux collections et à quelques types de base (Option, TypleN, Either, Try).

Améliorations du compilateur

Le langage en lui-même n’évoluera pas tellement avec la version 2.13, celle-ci se focalisant sur les aspects des bibliothèques. Cependant, le travail continue sur le compilateur, principalement pour le rendre plus rapide. Le premier objectif poursuivi sera de développer l’infrastructure nécessaire pour mesurer finement la performance du compilateur. Ensuite, les développeurs de Scala utiliseront tous les outils à leur disposition pour détecter les problèmes (principalement, des profileurs JVM).

Sortie de Julia 0.5

Julia est un langage de programmation assez récent (son développement a commencé en 2012), mais il a déjà réussi à attirer une assez grande communauté autour de lui. Initialement, il est prévu pour le calcul scientifique, en fournissant un langage dynamique et facile à utiliser (comme Python ou MATLAB) tout en gardant une très bonne performance (digne d’un langage compilé : Julia est très proche du C ou du Fortran dans les temps d’exécution).

La version 0.5 vient de sortir, un an après la précédente… et avec pas loin de trois mois de retard sur le programme. Elle ne se focalise pas exclusivement sur la performance, mais plutôt sur les fonctionnalités : certains changements syntaxiques préparent le terrain pour des améliorations de performance pour les prochaines versions du langage. Ses développeurs cherchent à stabiliser le langage dès que possible pour favoriser son adoption : la première version finale, la 1.0, ne devrait plus tarder (courant 2017).

Dans les nouveautés intéressantes pour bon nombre de programmeurs, les expressions de la forme f(i) for i in 1:n sont maintenant des génératrices : elles correspondent à des itérateurs sur les valeurs demandées. Ainsi, pour calculer la somme de toutes ces valeurs, il n’est plus nécessaire de créer un tableau à cette occasion : sum(f(i) for i in 1:n) au lieu de sum([f(i) for i in 1:n]) précédemment (les crochets ne sont plus nécessaires). Toujours au niveau des génératrices, il devient possible d’ajouter des conditions avec le mot clé if et d’effectuer des boucles imbriquées en utilisant plusieurs fois for.

Les opérateurs avec point existent depuis un certain temps et servent à effectuer une opération sur chaque élément séparément (par exemple, a .+ b effectue la somme de chaque élément de a et de b). Désormais, ce point est généralisé pour toutes les fonctions ; l’interpréteur se charge alors d’appeler la fonction broadcast. Dans le futur, ces nouvelles possibilités syntaxiques seront utilisées pour optimiser le code, en fusionnant ces opérations.

Julia étant prévu pour le calcul scientifique, le parallélisme est une thématique très importante. Certaines facilités syntaxiques existent déjà depuis longtemps pour la communication entre processus, mais les développeurs cherchent depuis un certain temps la meilleure approche pour la programmation multifil (c’est-à-dire à mémoire partagée). Les idées convergent vers une implémentation disponible dès cette version 0.5, mais la syntaxe pourrait encore évoluer. Pour exploiter les différents cœurs d’une machine, il suffirait d’utiliser une macro @threads sur chaque boucle à paralléliser, sans plus d’action requise de la part de l’utilisateur.

Un débogueur fait maintenant son apparition dans Julia. Il n’est pas livré avec l’interpréteur, mais est très facile à installer. Gallium est en développement depuis de nombreux mois et est aussi intégré dans l’environnement de développement Juno.

Cette version regorge de modifications en tout sens pour donner plus de cohérence à la bibliothèque standard et pour alléger son cœur (de telle sorte qu’il reste possible d’utiliser Julia dans n’importe quelle situation). Ces optimisations sont, par exemple, utiles dans l’embarqué ; à ce sujet, l’exécution sur des plateformes ARM (généralement utilisées dans l’embarqué) a été largement améliorée ; de même, l’architecture IBM POWER est maintenant gérée.

Source : Julia v0.5.0 Release Notes.