Adopte un langage de programmation nouveau

Bonjour,

Je suis de ceux qui ont encore pour langage de prédilection un langage de programmation dont la création date d’avant les années 2000 (le mien date de 1995). Cependant je commence a me dire qu’il serait temps d’adopter un langage de programmation plus récent sans forcément rester sur les même propriétés que mon ancien langage de prédilection.

J’aimerai donc obtenir un retour d’expérience de la part de la communauté, qui pourra peut-être servir à d’autres.

Pour ceux qui ont sauté le pas vers des langages de programmation des années > 2000 (voir la liste en secret):

• Quel(s) étai(en)t votre/vos ancien(s) langage(s) de programmation de prédilection ¹
• Quels langages nouveaux avez vous essayés (essayé dans le sens aller plus loin que le simple Hello Word) ?
• Quel langage nouveau avez vous adopté ? et pourquoi ?

Pour ma part, mon ancien langage de prédilection était jusqu’ici Java (je ne choisit autre chose que lorsque c’est vraiment nécessaire), j’ai déjà essayé C#, Scala et Go, mais pour le moment je n’ai encore adopté aucun. Et vous ?

J’ai beaucoup de plaisir avec Elixir.

"Ancien" langage : JavaScript.

Perso, le C et le Python en « ancien », le Rust a l’air vraiment pas mal.

Mais bon, je vois pas l’intérêt de changer de langage, le Python et le C sont très bien.

Java -> Kotlin. Kotlin, c’est Java sans ses inconvénients tout en restant compatible avec la gigantesque base de code de Java.

C’est simple : quand j’ai écrit le Kotlinquarium j’avais l’impression que tout ce que j’écrivais avait une utilité. Le langage me fait penser à un Ceylon en mieux conçu et soutenu.

Pareil, que le monsieur du dessus Java -> Kotlin. Aucun regret.

• Quel(s) étai(en)t votre/vos ancien(s) langage(s) de programmation de prédilection [^predilection]

C, C++ et Python.

• Quels langages nouveaux avez vous essayés (essayé dans le sens aller plus loin que le simple Hello Word) ?

J’ai essayé Go, je me suis découragé sur Rust. À charge de revanche.

Je ne dirais pas que j’ai adopté Go, parce que je n’ai toujours pas eu l’occasion de travailler sur un projet sérieux avec et que de toute façon je ne lâcherai pas ma toolbox C/Python, mais j’aime ce que j’en ai vu et j’ai envie de continuer à jouer avec.

Python (3) et Fortran (95 à 2008) comme ancien. Après, dire que python3 est ancien… J’ai essayé Rust et Julia. Je ne suis pas du tout convaincu par Rust (trop complexe, pas très cohérent, et les fois où je suis allé voir leur communauté, c’était très moyen¹).

Julia m’a beaucoup plus convaincu, j’attends un projet concret pour l’utiliser et voir ce qu’il donne. Je le trouve simple et efficace. Il fait son boulot sans enquiquiner le monde, à priori. Les problèmes potentielles, ce sont le manque de bibliothèque (accès à celles en C et Fortran, mais pas de bonne bibliothèque graphique facile d’accès à ma connaissance), et de voir ce que ça donne en vrai dans un programme un peu gros.

Bon, en pratique, j’ai remplacé Fortran par le C++ 2011/2014, mais je ne suis pas convaincu de rentrer dans le sujet.

Ouai c’est très souvent le cas. Mais au moins les développeurs de Rust connaissent le problème et vont travailler la dessus..

J’ai vu que c’était dans leurs priorités 2017 de baisser de prix du ticket d’entrée, et je salue cette décision.

Java ->

• Groovy (quand besoin d’un petit script rapide ou quand j’ai vraiment vraiment besoin de faire des trucs très spéciaux : modification de l’AST, missingProperty, etc.)

• Kotlin (pour tout le reste)

• Scala (pour les références de méthode, vraiment pénible que ça manque en Kotlin)

Pas tout à fait d’accord avec SpaceFox cependant. Je trouve Ceylon (et Scala) mieux "conçus" que Kotlin. Notamment Ceylon qui propose l’algèbre de type. Par contre je trouve Kotlin beaucoup plus facile d’accès quand on vient de Java. J’ai vraiment eu du mal à jouer avec Ceylon sur certains projets uniquement parce que la marche est plus haute, par contre les possibilités sont vraiment immenses.

Frege mérite d’être envisagé aussi, notamment pour l’utilisation de FregeFX.

Sinon,

JavaScript ->

• TypeScript

• Elm (qui dispose du meilleur compilateur que je n’ai jamais utilisé). Là encore, la marche est haute quand on vient du JS, mais quel régal… Un travail magnifique.

Si on parle de ce genre de chose, ça existe en Java 8 et aussi en Kotlin sous le terme de Function References.

Tout dépend de ce que tu appelles « bien conçu » en fait. Pour moi, un langage bien conçu, c’est un langage qui me permet de faire ce dont j’ai besoin avec un maximum de simplicité, de sûreté et d’efficacité. L’algèbre de type à la Ceylon, c’est joli, mais je ne me rappelle pas m’être dit que ça m’aurait vraiment servi un jour.

Je viens du Fortran (77 FTW), C++ et un peu plus récemment Python.

Go pour ma part. J’ai eu l’occasion de tester sur des projets sérieux et c’était franchement sympathique. Je ferais du Scala si j’avais du temps simplement parce que beaucoup de plateforme et outils de traitement de données propose une version Scala.

Python 3 ça compte dans les langages post-2000 ?

Sinon je n’ai pas essayé plus que ça de langages récents, encore moins adoptés. Mais j’ai Rust et Nim que je garde de côté, pour m’y intéresser plus tard, quand je prendrai le temps.

Merci à tous pour vos interventions, donc je vais peut-être mettre le nez dans Kotlin qui semble revenir assez souvent pour les anciens du Java afin de comparer ça avec Scala que je connais déjà.

Vous pouvez continuer, c’est très interessant de lire vos retours d’expérience.

Pour moi, c’est presque comme nohar : C#/Python en vieux langage, j’ai testé Go et Rust, les deux me semblent bien mais j’ai pas vraiment été plus loin que le "Hello World!" en Rust.

btw, C# a été crée en 2000, ça compte ?

Pour finir, F# c’est littéralement OCaml avec .NET et sans les points-virgules !

Cool, j’ai enfin une bonne raison de ne pas apprendre Rust maintenant et d’attendre un peu.

Récemment — depuis un an et demi je dirais —, j’ai testé pas mal de choses. Go brille vraiment pour sa simplicité de prise en main. Tu peux facilement avoir vu l’ensemble de ce qu’il y a à savoir du langage en quelques jours ; après, c’est comme le reste, l’aisance vient avec la pratique. Mais typiquement, le fait que la spécification du langage soit à taille humaine permet à quiconque de la lire en cas de doute sur le fonctionnement du machin. Je ne sais plus s’ils ont des undefined behavior, tiens.

J’ai essayé le Rust et j’aime beaucoup ; surtout, le système de type permet de faire des choses élégantes. Par exemple, expliciter très facilement le fait qu’une variable n’est plus disponible après un appel de fonction (c’est lié à l’ownership des variables intégrées au langage). Après, je n’en fais actuellement plus régulièrement, parce que j’ai découvert que ce que j’aimais vraiment dans Rust, c’était ses touches fonctionnelles. Du coup, je me suis mis à un langage fonctionnel (Haskell en l’occurence).

Par ricochet, j’ai découvert le PureScript, qui est globalement un Haskell pour le web (à ne pas confondre avec ghcjs, qui compile effectivement du Haskell vers du javascript ; ici c’est un langage différent, très très proche, j’ai pu m’en rendre compte quand j’ai porté un parseur d’Haskell vers PureScript, nais différent tout de même). Ils ont des libs vraiment sympas : j’ai adoré Halogen, qui est globalement une espèce de React très fortement typé.

Pour ma thèse, j’ai appris le Coq. Je ne sais plus s’il est post-2000 ou pas, mais j’imagine que tu ne le retiendras pas dans tous les cas d:. Ça fait un moment que je lorgne vers le racket, mais les syntaxes à la lisp me rebutent pas mal… Je ne renonce pas. Son système de macro/méta-programming à l’air sympa.

Enfin, il y a tout juste cinq jours, je me suis mis à Elixir. Je déteste l’absence de vrai système de types (je me rends compte de combien c’est devenu important pour moi) et le fait qu’il n’est pas possible de faire une application partielle (si je me trompe, vite ! dites le moi). Une fois mis ça de côté, c’est vraiment un langage très agréable à utiliser. Ça demande un changement complet de paradigme pour tirer parti d’OTP, mais mon dieu que c’est cool ! Petit bémol sur la syntaxe par contre, mais là on rentre dans des considérations esthétiques.

Si on parle de ce genre de chose, ça existe en Java 8 et aussi en Kotlin sous le terme de Function References.

En fait les Function references sont présentes depuis un bon moment, mais ce n’est pas ce dont je parlais, je parlais vraiment des method references.

Genre si j’ai un objet foo de type Foo qui possède une méthode Integer bar(String s), en Java 8 je peux écrire Foo foo = new Foo(); Function<String, Integer> baz = foo::bar;. Donc la référence de méthode sur l’objet instancié. Je peux même écrire BiFunction<Foo, String, Integer> baz = Foo::bar;.

En gros en Java 8 j’ai 3 types de références :

• les références de fonction (pures) => en gros des références de méthode vers des méthodes statiques, ça c’est présent en Kotlin, depuis pas mal de temps et ça colle bien avec l’approche fonctionnelle. Exemple : System.out::println

• les références de méthode sur un objet instancié, genre "something"::length

• les références de constructeur (qui mappe sur un Supplier ou une Function) genre : String::new

• les références de type, genre String::length

Jusqu’à Kotlin 1.1 j’avais juste trouvé la première et la troisième fonctionnalité. Top quand tu travailles avec Kotlin "tout seul" (et donc très orienté fonctionnel) par contre un peu pénible pour l’interopérabilité avec des libs "orientées objet". Apparemment en Kotlin 1.1 ils vont ajouter le second, tant mieux !!

Le truc qui me manquait en Kotlin, à voir si ça va arriver avec Kotlin 1.1, c’est l’association entre une lambda (au sens Kotlin du terme) et une @FunctionalInterface de Java 8 (encore une fois pour l’interopérabilité), ça, ça serait excellent.

mais je ne me rappelle pas m’être dit que ça m’aurait vraiment servi un jour.

Ca arrive quand même, et ça permet vraiment de jouer avec ce que j’appelle (sans doute à tort) des "mixins" : List<String | Number>, Function<Closeable & Readable> et du coup de se passer de l’héritage "conventionnel" parent <-> enfant, en composant très simplement des comportements.

Y’a encore quelques trucs où en Scala ou en Ceylon je me dis : waouh, c’est sacrément chouette, mais qui me manquent en Kotlin, ça viendra certainement, le langage est très prometteur. Les extensions sont vraiment une feature top du langage, mais il reste juste quelques micro-points gênants pour que ce soit totalement parfait.

EDIT :

Par ricochet, j’ai découvert le PureScript, qui est globalement un Haskell pour le web (à ne pas confondre avec ghcjs, qui compile effectivement du Haskell vers du javascript ; ici c’est un langage différent, très très proche, j’ai pu m’en rendre compte quand j’ai porté un parseur d’Haskell vers PureScript, nais différent tout de même). Ils ont des libs vraiment sympas : j’ai adoré Halogen, qui est globalement une espèce de React très fortement typé.

Si jamais t’as du temps et envie, regarde Elm. C’est vraiment l’approche React + Redux, mais en lieu et place des composants, tu trouveras des fonctions pures. A la place des JSX, une lib Html qui possède des fonctions div, span, etc. Super facile de jouer avec canvas et webgl. Je ne connais pas PureScript, donc je ne veux surtout pas dresser de comparaison, mais ça serait top d’avoir une comparaison de quelqu’un qui connaît les deux !

J’ai entendu parler de Elm quand j’étudiais la FRP (Functional Reactive Programming) en Haskell ; de ce que j’ai compris, il était un des rares langages avec du FRP intégré (mais je crois avoir lu qu’ils avaient depuis un peu fait marche arrière). J’ai jamais eu le courage de me lancer, cependant ):.

Edit : après, je vais devoir coder un client de jeu bientôt… elm + canvas, ça peut être intéressant de me saisir de cette opportunité pour apprendre. Je chercherai des ressources dessus.

J’ai entendu parler de Elm quand j’étudiais la FRP (Functional Reactive Programming) en Haskell ; de ce que j’ai compris, il était un des rares langages avec du FRP intégré (mais je crois avoir lu qu’ils avaient depuis un peu fait marche arrière).

Oui, ils sont passés à une approche plus proche du modèle "publish / subscribe" pour la gestion des évènements. Je dois reconnaître qu’à l’époque (pré 0.17) j’ai essayé de jouer un peu avec les signaux mais j’avais beaucoup de mal.