Discussion :

[DonQuiche]

En -9-
Lâcher son langage/framework favori depuis dix ans et essayer une nouvelle techno qui fait le buzz le temps d'un week-end. On adoptera ou on mettra tout à la poubelle derrière, mais au moins cela permet de sortir de son champ d'expérience et de sa zone de confiance pour découvrir de nouveaux modèles de conception et paradigmes.

Justement je ne vois pas beaucoup de nouveauté : les technos d'aujourd'hui ressemblent fortement à celles d'hier et ce n'est pas un énième framework qui va me faire vibrer. Sans parler du fait que cette valse de technos jetables se déroule avant tout côté JS où trop souvent on reproduit péniblement ce qui a été fait ailleurs il y a dix ans, et notamment sur le desktop.

Les vraies innovations qui me viennent en tête c'est la vague NoSQL, les travaux de Duffy sur des sémantiques concurrentes, F# et sa mise en oeuvre du système Hindley-Miller, Ceylon, les calculs dans le nuage, le calcul hétérogène, asm.js et NaCl, Midori, le big data, la robotique, etc.

Mais un énième framework de plus ? Pfffffffffff ! La barbe !

[SylvainPV]

Mais un énième framework de plus ? Pfffffffffff ! La barbe !

On parle de quoi là exactement ? C'est le mot "framework" qui te donne des boutons ? Parce que j'aurais pu dire logiciel, bibliothèque ou langage, ça aurait été un terme tout aussi générique et abstrait. Présumer que tous les frameworks actuels et à venir sont des technos jetables et déjà vues, sans préciser à quoi tu fais allusion, n'est pas très constructif à mon avis...

C'est cette tendance à la généralisation et à l'attentisme qui m'agace. Certes, on a une forte tendance à réinventer la roue dans notre métier. Et parmi tous les nouveaux projets qui débarquent tous les jours sur Github et compagnie, il y en a sans doute moins d'1 sur 100 qui s’avéreront vraiment innovants, utiles et pérennes. Mais pour que ce 1% puisse émerger, il faut qu'on prenne la peine de s'intéresser et de tester les nouveautés. Derrière ces projets, ce sont des développeurs qui se basent sur leurs expériences passées pour essayer d'améliorer les choses.

D'ailleurs, ça me fait penser à une expérience de programmation à recommander : créer et publier en open-source une bibliothèque/un plugin/une API

[DonQuiche]

C'est le mot "framework" qui te donne des boutons ?

En général quand on nous parle de framework c'est pour l'UI, les entrées-sorties, etc. Le genre de choses essentielles mais pas très intéressantes du point de vue de l'innovation. On ne parle guère de framework pour ce que j'ai énuméré.

Après sur le fond ton argument est qu'il faut se donner la peine de tester pour dénicher les pépites. C'est tout à fait vrai, encore que je ne vais pas perdre du temps à tester un nouvel outil sur un créneau archi-défriché où l'on possède déjà des hordes de technos mûres et satisfaisantes. Justement parce qu'il n'y a pas grand chose à attendre d'un outil réinventant la roue, même si elle est soi-disant encore plus ronde que la concurrence.

[Mat.M]

Justement je ne vois pas beaucoup de nouveauté : les technos d'aujourd'hui ressemblent fortement à celles d'hier et ce n'est pas un énième framework qui va me faire vibrer. Sans parler du fait que cette valse de technos jetables se déroule avant tout côté JS où trop souvent on reproduit péniblement ce qui a été fait ailleurs il y a dix ans, et notamment sur le desktop.

pourtant dans un fil de discussion précédent tu me soutenais le contraire
sinon je suis d'accord avec toi

On parle de quoi là exactement ? C'est le mot "framework" qui te donne des boutons ? Parce que j'aurais pu dire logiciel, bibliothèque ou langage, ça aurait été un terme tout aussi générique et abstrait. Présumer que tous les frameworks actuels et à venir sont des technos jetables et déjà vues, sans préciser à quoi tu fais allusion, n'est pas très constructif à mon avis...

je suis d'accord avec toi mais Don Quiche a parfaitement raison : à l'heure actuelle on est noyé dans des tonnes de technologies qui sortent , il faut faire le tri entre celles qui sont vraiment pertinentes et celles qui apportent vraiment un plus.
Or moi je ne suis vraiment pas convaincu..et comme Don Quiche je demeure perplexe sur les véritables apports.
Maintenant je peux me tromper également..
Mais la multiplicité des "frameworks" qui sont certainement des outils très intéressants fonctionnellement parlant tend au niveau des projets informatiques à produire de plus en plus d'usines-à-gaz ;
et donc à se lancer dans des projets de plus en plus risqués.
Ensuite en entreprise on n'a pas trop le temps à tester et éprouver des frameworks divers et variés..ok pour le passioné du développement mais pas en entreprise...

[SylvainPV]

Mais la multiplicité des "frameworks" qui sont certainement des outils très intéressants fonctionnellement parlant tend au niveau des projets informatiques à produire de plus en plus d'usines-à-gaz ;
et donc à se lancer dans des projets de plus en plus risqués.
Ensuite en entreprise on n'a pas trop le temps à tester et éprouver des frameworks divers et variés..ok pour le passioné du développement mais pas en entreprise...

D'accord sur le temps à consacrer, c'est vrai que c'est très chronophage et que tout le monde ne peut pas se le permettre. Dans ma boîte, on a une conférence hebdomadaire de 2h à libre participation où chacun peut présenter rapidement un framework qu'il a découvert et dont il pense du bien. Et pour le reste, il y a les newsletters, blogs spécialisés et... developpez.net bien sûr Ça aide à faire le tri, bien qu'à un moment il faut s'y essayer pour se faire une opinion.

Je ne comprends pas le lien que tu fais entre frameworks et logiciels usines à gaz. Les frameworks sont des socles techniques, plus ou moins polyvalents, plus ou moins complexes, mais avec comme objectif commun de simplifier le développement. L'usine à gaz apparaît bien après le choix d'un framework qui se fait en début de projet.

La notion de risque est intéressante, car finalement ça se résume à ça : le jeu n'en vaut pas la chandelle. On ressort les valeurs sûres ou les outils internes, malgré que l'on connaisse leurs défauts, pour rester dans le champ d'expérience. Seulement, on ne peut pas reposer éternellement sur les mêmes outils et on est contraints de toujours évoluer dans notre métier, alors autant prendre le train en marche plutôt qu'en pleine face en bout de voie. Enfin, c'est comme ça que je vois les choses.

[paulolol]

Personnellement je ne connais Erlang que de nom mais ce langage ne m'a pas attiré plus que ça...
En ce qui concerne le Node.js, j'ai essayé... Ce n'est pas vraiment l'idéal pour développer des applications web... à part peut-être l'API Google Maps qui serait plus facile d'utilisation en Node qu'en HTML5.
Justement, pour le HTML5, là je mets 10/10, surtout avec d'autres langages associés comme le CSS3, jQuery, JavaScript, etc. et même de la 3D avec WebGL, Three.js, etc. Franchement, je pense continuer longtemps de l'utiliser pour sa facilité (ex.: mettre une vidéo sans flash player :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<video [...] controls><source src="movie.mp4" type="video/mp4"></video>

)
Pour le R, je n'ai jamais essayé mais il a l'air relativement simple pour tout ce qui est gestion de données (et en plus, c'est du GNU )
En NoSQL... bah j'ai jamais vraiment eu besoin de faire des bases de données même si il vas falloir que je m'y mette. Honnêtement, si j'ai besoin d'en faire, ce ne seront pas des très complexe donc je pense que quelque MySQL me suffiront.
Et enfin, pour ce qui est du Go, honnêtement, je vois pas ce que ça peut apporter, à part un nouveau langage de Google au même titre que le Dart...

[Invité]

Personne ne veux tenter le XML en COBOL sous z/OS ?

[el_slapper]

Personne ne veux tenter le XML en COBOL sous z/OS ?

Déjà fait. A partir de cobol 3, il existe des ordres dédiés au XML, mais comme on était encore en cobol 2, j'avais fait un moteur de génération XML. En cobol natif

(je sais, il existe aussi des asiles pour aliénés).