PolyConf est une conférence pour échanger sur les meilleures pratiques de la programmation. Les programmeurs sont trop souvent réduits à un langage de programmation alors qu’il est plus sage, dans un contexte d’innovation constante, d’apprendre à apprendre et de combiner le meilleur de chaque langage dans des solutions ad hoc. Autrement dit, le fait de ne pas se spécialiser en tant que développeur sur un langage spécifique, pour préférer une approche polyvalente. Concrètement, cela s’est reflété dans le programme de l’événement qui a traité de nombreux sujets : Ruby, Python, Haskell, Rust, Erlang, Go, Java, F#, JavaScript…
NdM. : cette édition est intitulée « L’univers des langages de programmation. Ne voyez pas les frontières / limites, voyez les horizons » (The Universe of Programming Languages. Never see boundaries, but only horizons). Les trois précédentes éditions ont eu lieu à Poznan en Pologne. Les huit éditions précédentes (à l’époque l’événement se nommait « RuPy », a priori plus centré sur Ruby et Python) ont eu lieu à Budapest, Brno, au Brésil et en Pologne.
L’appel à conférences se termine le 19 mars.
Aller plus loin
- PolyConf (210 clics)
# Juste pour la discussion...
Posté par arnaudus . Évalué à 4.
D'après mon expérience, c'est quand même dans l'exploitation de leurs subtilités que les langages deviennent intéressants, et l'expertise du programmeur également.
Le problème de l'approche polyvalente, c'est quand même qu'un programmeur ne peut pas connaitre à fond des dizaines de langages. Du coup, il va écrire du code passe partout, c'est à dire du pseudocode traduit dans la grammaire du langage en question. Ça pose un certain nombre de problèmes, notamment le fait de ne pas maitriser correctement un seul langage, et de manière plus générale ne pas exploiter les possibilités d'un langage. On peut aussi écrire du code qui respecte la grammaire du langage mais pas son esprit (par exemple l'(in)fameux C/C++).
L'autre problème, c'est que pour un projet donné, on ne peut pas écrire un bout de code en C, un bout en Rust, un truc en javascript, l'interface en perl et le serveur en C++… Au bout d'un moment, il faut savoir maintenir une cohérence dans un projet, parce que d'autres êtres humains sont susceptibles de lire le code et d'essayer de modifier le truc.
Au final, j'ai du mal à comprendre ce principe de la connaissance superficielle des outils. Pour trouver du boulot, peut-être? Mais après, forcément, on risque d'être impliqué des années dans un projet basé sur un ou deux langages, et donc se spécialiser.
[^] # Re: Juste pour la discussion...
Posté par ɹǝıʌıʃO . Évalué à 6.
À fond des dizaines, non. Mais avoir une connaissance assez large pour pouvoir s’adapter, oui. Écrire du code métier en Ruby parce que c’est le plus pratique et lui faire appeler des microservices écrits en Go parce qu’on a un gros besoin de performances sur ces quelques services-là spécifiquement, par exemple. Ou avoir une base de code en PHP parce que c’est l’habitude de l’entreprise, et quand on a besoin de faire des calculs lourds, les réaliser avec Spark et les écrire en Scala. D’ailleurs, à ma connaissance, la plupart des gens trouvent déjà normal d’utiliser un langage pour le code métier et un autre — l’une ou l’autre variante de SQL — pour les requêtes en bases de données, ce qui n’a rien d’évident (on pourrait très bien gérer ses données dans le même langage que le reste).
[^] # Re: Juste pour la discussion...
Posté par arnaudus . Évalué à 1.
Oui mais là, ce que tu décris, c'est simplement de maitriser une panoplie d'outils : un langage compilé pour les perfs, un langage de haut niveau pour parser des fichiers, un shell pour automatiser les tâches, et éventuellement quelques langages spécialisés en fonction des besoins (service web, bases de données, gestion des tâches sur un cluster de calcul…). Je pense que personne ne peut vraiment imaginer que c'est inutile.
Là où ça devient vraiment discutable, c'est (si j'ai bien compris l'approche proposée dans le journal) l'idée d'avoir une culture générale très large en terme de langages de programmation. Mon point de vue, c'est que si on est à l'aide en perl, il n'y a aucune raison d'apprendre python et ruby sans avoir auparavant identifié un besoin précis. Même si chaque langage a ses particularités, et qu'un traitement pourrait être plus efficace ou plus facile à coder avec un langage précis, mieux vaut certainement utiliser un langage dont on maitrise les caractéristiques plutôt que de pondre un code de débutant dans un langage qu'on connait mal. Ça pose trop de problèmes de lisibilité, de maintenance, de performances, ou même de sécurité.
[^] # Re: Juste pour la discussion...
Posté par ɹǝıʌıʃO . Évalué à 2.
Pas seulement. C’est en connaissant plusieurs langages qu’on peut s’inspirer de ce qui se fait ailleurs, ce qui amène à des façons de programmer, ou des bibliothèques, inspirées d’autres (familles de) langages. Si je prends l’exemple de la programmation fonctionnelle en Javascript, on obtient les IIFE, les promesses, ou des bibliothèques comme Ramda (il y en a plein d’autres). Ce genre de choses ne peut venir que de développeurs expérimentés dans des langages fonctionnels.
Je pense aussi que ça dépend du niveau du développeur. De mon point de vue, grosso modo, ce que tu dis se justifie pour un technicien, pas pour un ingénieur.
[^] # Re: Juste pour la discussion...
Posté par whity . Évalué à 1.
C’est quand même beaucoup une question de paradigmes plutôt que de langages.
C’est intéressant d’apprendre des langages différents quand ça permet d’aborder de nouveaux paradigmes. Apprendre C# quand on connaît déjà Java… mouais… Ça ira vite, par contre on n’en retirera pas grand chose.
À côté de ça :
On a inventé les ORMs pour entre autres éviter ça.
Mais ce n’est pas le principal soucis que je vois. Le problème de la multiplicité des langages, c’est que l’interfaçage entre eux est pauvre. Et souvent, parce qu’interfacer coûte plus cher que redévelopper, on se retrouve avec de nombreux composants dupliqués (par exemple, l’orm, justement, qui ne sera pas le même pour le module php de visualisation web que pour le module go de traitement des données). Côté produit, il faut de vraiment bons arguments pour introduire une techno « alien », parce que tu en paies le prix dans la durée.
Autrement dit, la multiplicité des langages, c’est effectivement très bien pour le programmeur, mais pour le produit, c’est souvent plus une plaie qu’autre chose.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Juste pour la discussion...
Posté par ɹǝıʌıʃO . Évalué à 2.
Oui. Mais j’aimerais bien voir la tête, pour rester sur le même exemple, d’une bibliothèque de monades en Javascript écrite par quelqu’un qui n’a jamais écrit de Haskell (ou un autre langage fonctionnel), mais seulement suivi des cours sur les monades. Pour apprécier un paradigme à sa juste valeur, il faut le pratiquer.
Pour ne pas avoir à faire du SQL au quotidien, oui. Mais connaitre un ORM ne dispense absolument pas de connaitre SQL.
Ah mais complètement, c’est bien mon point de vue, il ne faut pas exagérer le nombre de technos différentes dans un même produit. Reste à définir ce qu’est un produit, à l’heure des microservices.
[^] # Re: Juste pour la discussion...
Posté par Antoine . Évalué à 1.
Quel est l'intérêt d'écrire une bibliothèques de monades en Javascript ? Quels sont les problèmes concrets que cela permettrait de résoudre mieux qu'une approche plus idiomatique ?
[^] # Re: Juste pour la discussion...
Posté par ɹǝıʌıʃO . Évalué à 4.
L’intérêt est le même que celui qui a conduit à les introduire en Java 8, dont la spécification est pourtant décidée par un comité autrement plus conservateur.
Pour prendre un cas concret : les Promise sont des monades (au moins dans leurs version A+), leur chainage n’est rien d’autre qu’un flatMap, et elles sont largement adoptées. On les trouve d’ailleurs aussi en Java 8.
[^] # Re: Juste pour la discussion...
Posté par Antoine . Évalué à 1.
Et donc, concrètement, qu'est-ce que cela apporte d'utiliser des monades pour implémenter des « Promise » (ou Future, etc.) ?
[^] # Re: Juste pour la discussion...
Posté par ɹǝıʌıʃO . Évalué à 4.
Je laisse la parole à Douglas Crockford, bien connu des amateurs de Javascript, qui explique ça beaucoup mieux que moi dans une présentation sobrement intitulée Monads and Gonads. En bonus, si tu ne le sais pas déjà, tu apprendras ce que sont des « couilles de chien » en Javascript.
[^] # Re: Juste pour la discussion...
Posté par Antoine . Évalué à 2.
J'en étais resté à l'excrément de taureau. Je suis content de voir que la communauté Javascript renouvelle les paradigmes :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.