Je me suis toujours plus ou moins interdit d'apprendre de nouveau langage car je considéraient ça comme une perte de temps.
De nombreux langage existe deja, tous ayant leurs domaines et leurs base de code forte utile.
Aujourd'hui jobserve de plus en plus de zesteux intéresser par ces nouveauté et je me demande ce qu'il en espèrent/attendent.
Je conçois que le nouveau ceylon à l'avantage d'être entièrement défensif, que le go est innovant ou que le brainfuck à l'air pratique mais est ce vraiment utile de les apprendre?
Pour moi les problématiques existantes sur les langages existant ne sont pas blocante mis à part dans certains domaine de niche (j'imagine…). Je ne vois pas alors ce que mapporterai de m'investir dans un langage au futur douteux. Je préfère m'investir dans l'apprentissage des bonnes pratique de gestion de code, de conception , de maintenance ou dans l'apprentissage de librairie/framework.
Et bien, question abstraction je dirait que ça forge l'esprit. Quand on est passionné, quand on connais son domaine alors on creuse. Perso, je suis très bas niveau mais c'est bien de programmer en ruby pour changer du langage C et ses pointeurs…
En plus, je trouve ça génial d'offrir des cours variés et de découvrir de nouvelles méthodes d'apprentissages plutôt que se taper l'éternel : variables, conditions, boucles, fonctions…
Un nouveau langage c'est potentiellement le moyen de voir une autre manière de faire et de penser à la résolution d'un problème. Se couper des nouvelles idées qui apparaissent (même si finalement elles ne sont pas bonnes) et considérer que l'on a rien à apprendre de cela, c'est un bon moyen de se mettre à stagner et potentiellement à régresser.
De nombreux langage existe deja, tous ayant leurs domaines et leurs base de code forte utile.
Et si ça … c'était ton langage qui pouvait te le garantir ? Sans que cela nécessite que tu t'imposes une discipline de programmation que tu risques d'oublier de respecter pendant quelques secondes (au risque de provoquer un désastre). L'avantage de l'automatisé, c'est qu'il n'oublie pas.
C'est ce que proposent ces "nouveaux" langages. Coq qui te demande de prouver ce que tu écris, Rust qui te permet d'écrire du code relativement bas niveau plus simplement et avec plus de garanties, etc.
Et bien sûr les idées qu'apportent ces "nouveaux" langages peuvent ensuite être ramenées vers nos "anciens" langages pour les enrichir et les améliorer. Avec des analyseurs nous permettant de spécifier et de prouver du C par exemple. Avec des projets comme la GSL du côté de C++.
Les nouveaux langages sont tout sauf inutiles. Ils apportent de nouvelles idées qui peuvent les amener à devenir des langages majeurs et même s'ils échouent ils ont de bonnes chances d'améliorer l'existant au passage. Et ils ont la possibilité de bosser from scratch sur une formalisation qui ne se trimballe les moultes erreurs que contiennent les normes des mastodontes actuels.
Sinon, comme l'a dit Ozmox, si l'on aime ce que l'on fait, il est toujours agréable de découvrir de nouvelles choses. Pour mon cas personnel, j'utilise principalement Perl et Python en ce moment. Mais par curiosité, j'ai également essayé Ruby, Haskell, PHP, Java, C#, Rust, etc… Je ne peux pas dire que j'ai appris ces langages, mais je suis capable de faire des petites choses avec.
Découvrir de nouveaux concepts peux également être intéressant. Je pense que plusieurs personnes pourront te le dire sur le forum, l'apprentissage d'un tel langage a changé leur approche et donc leur manière de programmer dans un autre langage.
Découvrir de nouveaux concepts peux également être intéressant. Je pense que plusieurs personnes pourront te le dire sur le forum, l'apprentissage d'un tel langage a changé leur approche et donc leur manière de programmer dans un autre langage.
Je suis totalement d'accord avec toi. Il y a quelques temps je me suis mis à ruby parce un ami m'en avait parlé et depuis ca a changé des trucs dans ma manière de programmé. Avant, je ne voyais pas à quoi servait les classes, je m'en servait un peu n'importe comment et puis j'ai découvert des trucs sympas comme les blocs.
Je pense qu'on a toujours à y gagner à passer une ou deux semaines à apprendre un langage même si après on ne l'utilisera plus jamais. On apprend des trucs sympas et parfois de nouveaux concept.
C'est pas tant apprendre de nouveaux langages qu'apprendre de nouveaux paradigmes qui est intéressant et qui ouvre l'esprit. Si je connais déjà C++, je ne vais pas trop voir l'intérêt d'apprendre Java, mais par contre Haskell qui en est très différent ou Rust oui.
Avant je faisais du C et du Python. J'aime bien les 2 langages, que je continue à utiliser (enfin surtout Python maintenant). Je suis tombé sur Haskell un peu plus tard et OCaml, et ça a clairement modifié ma façon de programmer. Ça m'a appris à toujours réfléchir aux types qu'on utilise, et au passage j'ai pu comprendre les concepts fonctionnels qu'on retrouve dans Python. J'utilise toujours de l'impératif mais le fonctionnel m'a beaucoup apporté dans ma manière de voir les choses. Le fait d'avoir déjà fait du C me permet de mieux comprendre le côté bas-niveau.
En somme, apprendre un nouveau langage c'est bien mais surtout quand le langage en question est très différent.
Ta formulation laisse à penser que tu as pourtant envie d'apprendre des nouveaux langages. Pourquoi te brimes-tu ainsi ? Si un langage te fait envie, il faut jouer un peu avec et l'apprendre si affinité, non ?
Merci de vos réponses, décidément le sujet était chaud bouillant xD
A vrai dire je me l'interdisait dans le but d'optimiser mon temps de travail. Je trouver plus utile de travailler sur l'apprentissage des incontournable que d'apprendre des langages encore méconnus de tous. De même je préfère travailler la ou énormément de programmeur on des lacunes de manière a trouver une place plutôt que de taper dans la nouveauté.
Si les nouveaux langages m'attire c'est effectivement dans leurs nouvelles façon de voir les choses, les paradigmes sont parfois intéressant et c'est vrai qu'on a l'impression d'ouvrir tout un monde devant nous.
Malgré tout je suis toujours blasé de voir mes collègues apprendre le Go pour faire des sites web quand ils ne savent même pas encore faire du PHP… Je trouve que cela fait un peu trop "a la mode" et qu'on y perd du sérieux dans le choix des outils a apprendre.
Malgré tout je reste intéresser, comme je le dit j'apprends beaucoup sur la conception et les standard pour améliorer ma gestion de code dans de plus gros projet. Je serais aussi très intéresser d'apprendre des langages plus bas niveaux comme le C++, le C ou encore l'ASM si un jour j'en ai l'occasion. J'ai d'ailleurs fait en sorte d'être diplômé en réseaux, télécommunication et en développement logiciel de manière a gérer un peu tout.
Mais je ne trouve pas de valeur ajouté a vraiment apprendre et coder de manière soutenu dans un nouveau langage comme le Go. On y réinvente la roue déjà existante. Certe en mieux d'après certain, mais est-ce un choix d'apprentissage "prioritaire".
Après je conçois que dans la détente on peut toujours s'éclater dans un autre langage jamais utilisé. La c'est juste une question de goûts loin du bon sens, certains c'est le macramé, d'autre la pétanque, pourquoi pas le Ceylan.
Mais je ne trouve pas de valeur ajouté a vraiment apprendre et coder de manière soutenu dans un nouveau langage comme le Go. On y réinvente la roue déjà existante. Certe en mieux d'après certain, mais est-ce un choix d'apprentissage "prioritaire".
Il n'est pas prioritaire d'apprendre de nouveaux langages. Mais il faut bien se rendre compte que les langages en place sont pourris de défauts en tous genre. Mais genre vraiment. Et que le graal du logiciel sans bugs dans ces langages, il est loin.
Avec des langages mieux conçus à la base on a largement plus de chances de s'en rapprocher.
Il y a effectivement des problèmes dans les langages, ça je le vois de plus en plus en lisant les articles présent sur ZdS mais est-ce vraiment un problème insurmontable?
D'une part le développeur peut apprendre a les éviter, car comme dans tout langage on aura forcément des problèmes et donc des choses a éviter, de part une meilleur conception par exemple.
D'autre part le langage pourrait être améliorer (enfin j'imagine), e manière a prendre en compte de meilleur pratique. Un peu a l'image du C++ qui intègre un certain nombre de points d'amélioration d'après ce que j'ai lu.
A mon sens c'est plus logique dans le fait qu'on ne perd pas toute la base de code, qu'on ne divise pas la communauté en trop petit groupe (et donc l'effort) et que c'est un temps d'apprentissage réduit.
Après effectivement, peut-être que le bon sens voudrait que quelques langages fassent apparition mais que la communauté dérive ça en faisant trop de nouveau langage qui du coups ne décolle pas.
Non la communauté ne dérive pas. Chaque langage a sa pierre à apporter à l'édifice qui est unique (ou presque). Ils ont tous des particularités: je vais pas sortir C++ pour faire du scripting par exemple. Le fait d'avoir trouzemille langages est plutôt une bonne chose à mon sens, ça me permet d'avoir plus de choix.
Il y a effectivement des problèmes dans les langages, ça je le vois de plus en plus en lisant les articles présent sur ZdS mais est-ce vraiment un problème insurmontable?
Quand ta norme est cassée, tu as deux possibilités.
Soit tu laisses tel quel et tu dis aux gens de ne pas écrire de conneries, mais c'est problématique parce que les cas où c'est cassé sont systématiquement fourbes et complexes, donc trouver un procédure automatique qui vérifie ça, c'est mission impossible.
Soit tu répares ta norme mais tu brises la rétro-compatibilité parce que les codes qui tombaient dans les cas où c'est cassé ne compileront plus. Et ça va être une code base potentiellement énorme à réparer. Quand on parle d'un langage comme C ou C++, ça se mesure en milliards de lignes potentiellement impactées.
Et quand on parle de problèmes comme la syntaxe horriblement lourde, ça implique de changer la grammaire du langage. C'est juste impensable. Et une syntaxe trop lourde, ce n'est pas un faux problème.
D'une part le développeur peut apprendre a les éviter, car comme dans tout langage on aura forcément des problèmes et donc des choses a éviter, de part une meilleur conception par exemple.
On peut apprendre à éviter les undefined behaviors en C. Le problème c'est qu'il y en a énormément, qu'ils sont très difficiles à tracer et que parfois tu es obligé d'en utiliser (écriture d'un OS). Les bonnes pratiques ne font pas tout.
Des softs et des bibliothèques développés en C, il y en a un paquet des très biens, faites par des gens qui sont loin d'être des manches, et si on y regarder de près c'est blindé d'undefined behaviors. On estime que dans un OS comme Linux il y a 15 bugs par millier de lignes, il y en a un paquet qui ne provoqueront jamais de catastrophes, mais ils sont là, à attendre.
Et quand c'est ton compilateur qui te lâche dans les pattes, là tu peux vraiment commencer à pleurer.
D'autre part le langage pourrait être améliorer (enfin j'imagine), e manière a prendre en compte de meilleur pratique. Un peu a l'image du C++ qui intègre un certain nombre de points d'amélioration d'après ce que j'ai lu.
C++ est mon langage préféré. Pour autant, ça ne m'empêche pas de dire qu'il est irréparable. Si demain matin, un langage arrive avec les mêmes performances par défaut, et le même contrôle que C++. Mais avec un typeur meilleur, une sémantique clairement définie, une programmation par contrat de la mort, une safety par défaut 2 fois meilleure, et des outils de preuve, je lâcherai C++ sans hésiter (et non, pas Rust). Je trouve même ça hyper dommage de ne pas avoir mieux que C++ pour bosser dans ses domaines d'actions. Cela veut dire qu'en 20 ans, on n'a pas réussi à faire mieux.
Les bonnes pratiques ne font pas tout. Même avec des outils.
@Grimur : Pour moi au contraire je trouve cela dommage. Je trouve que seul le langage le plus adapté devrait-être utilisé de manière a rassembler les gens, facilité les échange et raccourcir le temps d'apprentissage par l'augmentation du nombre de code exemple, de bibliothèque déjà construite et de gens connaisseur disponible.
@Ksass`Peuk : Hum je comprend.. C'est effectivement des problèmes pour lesquels ils faudrait voir a changer de langage. Tout comme j'imagine que c'est ce genre d'erreur qui nous on mené aux langages actuel. Après pour ton domaine par exemple tu crois que ça t'apporterai quelques chose (d'utile et pas superflu) de coder en C++ mais aussi en Rust de manière égale ? (sur un problème pouvant être comblé par les deux)
Je sais pas pour vous mais moi par exemple j'ai orienté mon apprentissage sur un langage par utilité :
Python pour le scripting
HTML/CSS pour le web
PHP essentiellement pour le web a l'époque puisque python est venu ensuite
JS pour le dynamique
SQL pour les databases
Java pour le logiciel
J'apprends doucement C++ pour le logiciel nécessitant plus de ressources
Je me verrais mal apprendre le Go pour faire du web, ou le ceylan pour remplacer Java. Ou du moins pas avant qu'une majorité d'application sois disponible dessus et que la base de code soit correct. Donc possiblement avant que de grande société investisse dedans en temps ou en argent.
@Grimur : Pour moi au contraire je trouve cela dommage. Je trouve que seul le langage le plus adapté devrait-être utilisé de manière a rassembler les gens, facilité les échange et raccourcir le temps d'apprentissage par l'augmentation du nombre de code exemple, de bibliothèque déjà construite et de gens connaisseur disponible.
Ben justement, le coup du langage le plus adapté c'est complètement subjectif. Il faut se sortir de la tête l'idée qu'il existe un langage parfait. Le reste de ton message donne l'impression que tu vois les choses de manière assez tranchées. Prenons le cas du dynamique: il n'y a pas que JS, pareil pour NoSQL, pareil pour le logiciel, idem scripting … Du coup, le concept de "langage le plus adapté" est très dépendant de tes goûts, et "la communauté" compte un sacré gros paquet de membres avec des goûts assez variés. Par exemple, pour faire du fonctionnel je pourrais prendre OCaml ou Haskell. Imaginons que c'est pour du calcul matriciel avec précision. Untel va te dire "OCaml c'est mieux parce que tu pourras écrire des bouts de code impératifs et puis Haskell c'est paresseux alors j'y pige rien", un autre dira "Haskell c'est mieux parce que c'est plus propre et que machin" alors que ni l'un ni l'autre ont raison: tu prends le langage que tu préfères et qui sera assez adapté, qui sera très différent selon les personnes.
Pensez-vous que les outils d'analyse formelle seront un jour assez performants pour éviter la majorité des bugs ? Je pense à des choses comme Astrée ou des logiciels prouvés comme SEL4.
@Ksass`Peuk : Après pour ton domaine par exemple tu crois que ça t'apporterai quelques chose (d'utile et pas superflu) de coder en C++ mais aussi en Rust de manière égale ? (sur un problème pouvant être comblé par les deux)
Le domaine dans lequel je bosse actuellement n'est pas adapté à C++ (et j'y développe en OCaml). Pour ce qui est de l'usage de l'un et de l'autre. Actuellement c'est d'abord un problème d'éco-système. Pour le reste, le compilateur est pour l'instant insuffisamment optimisant (et ce n'est pas l'objectif numéro 1 de Mozilla pour Rust) et un sacré paquet de contrôles sont conservés au runtime alors qu'on ne voudrait parfois plus les voir du tout. Mais je ne me prononcerai pas pleinement avant d'avoir beaucoup plus manipulé.
Pensez-vous que les outils d'analyse formelle seront un jour assez performants pour éviter la majorité des bugs ? Je pense à des choses comme Astrée ou des logiciels prouvés comme SEL4.
C'est en tout cas ce en quoi je crois. La preuve de programme est un domaine super1, plus encore dans un monde où l'on vise de plus en plus le multi-coeur, le test devient de plus en plus difficile, voir impossible (en présence de weak memory models, le test est juste impuissant). La preuve pour le multi-coeur se complexifie … mais reste de l'ordre du possible. Simplement parce que la preuve ne demande pas de réfléchir au cas qui peuvent échouer, seulement à s'assurer que seul les cas valides sont possibles.
Le projet seL4 est une merveille, il a demandé beaucoup d'expertise malgré tout, mais les outils sont de plus en plus performants et de plus en plus pratiques. Dans les autres projets super, on peut aussi citer CompCert un compilateur C écrit et prouvé en Coq.
Je prépare d'ailleurs un tutoriel à ce sujet qui se basera sur la preuve déductive avec Frama-C, je dois encore le terminer et le faire passer dans quelques moulinettes avant de le mettre en bêta. ↩
Concernant Go, c'est un langage simple à apprendre et à utiliser coté web. Quand tu vois un micro framework comme Gin et que tu as déjà touché à du NodeJS avec ExpressJS , la structure du code est assez semblable (<troll>si ce n'est que Go est un poil plus performant que Node</troll).
Pensez-vous que les outils d'analyse formelle seront un jour assez performants pour éviter la majorité des bugs ? Je pense à des choses comme Astrée ou des logiciels prouvés comme SEL4.
« La majorité des bugs », c'est un peu trop vaste pour pouvoir répondre oui. Mais Astrée a par exemple réussi à montrer l'absence d'erreurs numériques à l'exécution dans la commande de vol des A340 et A380. Je pense qu'on peut commencer à parler de performance, non ?
En parlant de CompCert, son auteur a fait une conférence à l'UPMC mardi dernier. La vidéo n'est pas encore dispo, elle sera normalement mise en ligne ici dans quelques jours.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
En plus, je trouve ça génial d'offrir des cours variés et de découvrir de nouvelles méthodes d'apprentissages plutôt que se taper l'éternel : variables, conditions, boucles, fonctions… 
