Résultats de l’Enquête 2021 sur les fonctionnalités de Kotlin
Il y a quelques mois, nous avons organisé le deuxième sondage sur les fonctionnalités de Kotlin les plus attendues. Les principaux objectifs de cette enquête étaient de savoir quelles futures fonctionnalités de Kotlin étaient les plus importantes pour les utilisateurs et de déterminer la diversités des cas d’usage. Les résultats de cette enquête vont nous aider à établir les priorités de nos plans de développement du langage sur le long terme. Merci à toutes les personnes qui ont répondu aux questions !
Vous trouverez ci-dessous les résultats de l’enquête et un compte rendu de Roman Elizarov, Chef de projet pour Kotlin, sur nos projets concernant les fonctionnalités ayant reçu le plus de votes. Pour en savoir plus, vous pouvez consulter les descriptions des fonctionnalités et le webinaire réalisé par Roman Elizarov et Svetlana Isakova.
Veuillez noter que cette enquête n’est pas exhaustive car elle ne couvrait pas les fonctionnalités sur lesquelles nous travaillons actuellement et les fonctionnalités mentionnées dans l’enquête sont à différents stades de développement. Même si une fonctionnalité a reçu de nombreux votes, nous ne pouvons pas promettre qu’elle sera ajoutée au langage prochainement. Vous ne trouverez pas ces fonctionnalités dans les versions 1.6.x car vos votes nous aident à établir des priorités pour notre travail à long terme.
Dans ce cadre de cette enquête, trois choses étaient attendues de la part des participants :
- Choisir jusqu’à 3 fonctionnalités qu’ils souhaiteraient voir ajoutées au langage (obligatoire).
- Sélectionner une fonctionnalité qu’ils ne voudraient jamais voir implémentée (facultatif).
- Préciser pourquoi ils n’aimeraient pas avoir cette fonctionnalité dans le langage (facultatif).
Nous avons également donné aux participants la possibilité de partager des informations sur leur nombre d’années d’expérience avec Kotlin, leurs objectifs d’utilisation de Kotlin et les types de développement logiciel réalisés avec Kotlin, ce qui nous a permis de mieux comprendre la nature des cas d’utilisation du langage.
Nous avons reçu 1 540 réponses complètes. Les données brutes anonymisées sont disponibles, au cas où vous auriez envie d’approfondir la question.
Les fonctionnalités les plus attendues
Les 3 fonctionnalités ayant reçu le plus de votes sont les suivantes :
- Multicatch et types d’union (45 %)
- Les littéraux de collection (32 %)
- Récepteurs multiples sur les fonctions et propriétés des extensions (30 %)
Toutefois, les fonctionnalités de la liste occupant de la 4e à la 9e position ont également été largement plébiscitées par la communauté. Les six fonctionnalités en bas de la liste ont toutes reçu nettement moins de votes. Certaines d’entre elles se sont également retrouvées dans le top 3 des fonctionnalités les plus moins demandées, comme Lateinit pour les types nullables et primitifs et les opérateurs bit à bit surchargeables comme I et &.
Étant donné qu’il existe également plus d’une façon de mettre en œuvre la caractéristique Multicatch et les types d’union, nous avons demandé à la communauté Kotlin de nous indiquer laquelle des deux implémentations possibles elle préférait :
- 87 % ont voté en faveur des types d’union, cela permettrait de déclarer une fonction retournant une des valeurs possibles sans avoir à introduire un type
ParseResultdédié. - 13 % ont suggéré de ne pas apporter de modifications spécifiques aux exceptions, car les API Java modernes n’ont pas une utilisation abusive des exceptions (et les anciennes seront finalement remplacées). Les participants préféreraient disposer d’une syntaxe concise de type enum pour déclarer les classes scellées, afin de faciliter l’écriture des fonctions de retour d’erreur de type Kotlin.
Les fonctionnalités les moins demandées
Les répondants n’ont pas massivement voté contre des fonctionnalités. 40 % d’entre eux ont déclaré qu’ils n’avaient aucun problème avec l’implémentation des fonctionnalités proposées. Les autres réponses étaient réparties comme suit. Les 3 fonctionnalités les plus citées ont été :
- Opérateurs bit à bit surchargeables comme I et & : 10 %.
- Visibilité privée des paquets : 7 %.
- Lateinit pour les types nullables et primitifs : 6 %.
Données démographiques
71 % des répondants ont plus de deux ans d’expérience avec Kotlin.
85 % d’entre eux ont déclaré utiliser Kotlin dans le code en production
Voici la liste des types de logiciels développés par les participants.
Conclusion et état des lieux par Roman Elizarov
Pratiquement toutes les caractéristiques qui ont reçu le plus de votes sont à différents stades de recherche dans l’équipe Kotlin.
- Les types d’union et multicatch (KT-13108) sont l’ajout potentiel le plus populaire au langage, mais également le plus complexe à y intégrer. Cette implémentation nécessitera l’intervention d’un grand nombre d’experts de l’équipe en charge du compilateur principal. Il ne faut donc pas s’attendre à une avancée significative tant que cette équipe est occupée à mettre en production le frontend du compilateur K2. Mais une fois que cela sera fait, nous commencerons à travailler activement sur les types d’union.
- Les littéraux de collection (KT-43871) n’ont pas été intégrés à notre feuille de route publique actuelle, mais nous avons commencé à réaliser des prototypes pour déterminer les approches de conception les plus adaptées.
- Les récepteurs multiples (KT-10468) sont très proches d’une publication en preview. Vous pourrez bientôt vous amuser avec cette caractéristique à l’aide d’un commutateur de compilateur en avant-première. Restez à l’écoute !
- La déstructuration basée sur les noms (KT-19627) opère des choix syntaxiques assez controversés. Nous planifions donc une étude d’ergonomie sur les différentes options syntaxiques pour déterminer les plus compréhensibles pour les développeurs Kotlin.
- Les types de propriétés « publics » et « privés » (KT-14663) se sont avérés relativement faciles à implémenter dans l’architecture du nouveau frontend du compilateur K2 et ils seront disponibles en preview avec le nouveau compilateur.
- La visibilité privée des paquets (KT-29227) a reçu beaucoup de votes mais arrive également en deuxième place des fonctionnalités les moins souhaitées. Elle permet plusieurs options de conception et certaines d’entre elles peuvent compliquer l’apprentissage du langage, car elles exigeront des novices d’appréhender davantage de choix. Nous prenons cette question au sérieux et, tout comme pour l’approche originale de la conception des visibilités en Kotlin, nous étudions actuellement les données réelles sur la façon dont les développeurs Kotlin structurent leurs bases de code pour déterminer quel type de solution, avec quel type de paramètres par défaut, conserverait l’esprit de Kotlin : des paramètres par défaut qui vous permettent de démarrer facilement tout en vous offrant la possibilité de les ajuster et de les personnaliser au fil de la complexification de votre projet.
Auteur de l’article original en anglais :
Subscribe to Kotlin Blog updates
