Discussion :

[Camille_B]

Avec des frameworks comme GWT ou Wicket, ça reste à voir... (encore faut-il les connaître)

Oui, on pourrait aussi citer Grails ou Play.

Malheureusement il y a la réalité du langage et de son écosystème, et sa "réputation".

Prenons Perl, par exemple. Qui sait que Perl (sa version 5) est un langage qui s'est très largement "modernisé" ? Qu'il offre plusieurs modèles objets extrêmement souples (voire MooseX) ? Qu'il permet de faire des trucs fun "à la" Ruby avec beaucoup de sucre syntaxique ? Tout en conservant son "framework" monstrueux (CPAN), une excellente documentation, et une histoire suffisamment longue pour en faire un langage solide et dont la communauté a atteint une grande maturité ?

Presque personne, car Python et Ruby ont meilleure réputation.

Qui connaît les extraordinaires framework web écrits en Common LISP ? Qui sait que les langages de la famille LISP ont bien souvent des performances proche du C pour une souplesse inégalée et une concision dans l'écriture semblable aux Python et aux Ruby ?

Personne, car LISP a une réputation de langage vieux et conçu exclusivement pour l'intelligence artificielle.

Bref, il y a le langage, et son image. Et parfois, malheureusement, le monde industriel (ou amateur) passe à un nouveau langage pour de simples raisons de "réputation".

Or, au jour d'aujoud'hui, Java a toujours sa réputation de langage verbeux (alors que l'on peut garder le framework et passer à Scala, Rhino, Clojure etc.) aux framework lourdingues.

Peut-être la communauté a-t-elle un rôle à jouer sur ces points ? Sans doute le joue-t-elle déjà d'ailleurs !

[Antoine_935]

GvR n'aime pas la programmation fonctionnelle, GvR se moque de la programmation concurrentielle.

Python est pourtant un langage au moins autant fonctionnel qu'objet.

Pour ce qui est de la programmation concurentielle, je le lui accorde... les race conditions, c'est sans doute le moyen le plus sur de se farcir des bugs.

À mon sens, c'est d'ailleurs ce qui est vicié dans ces langages, avec l'arrivée des multicores: les race conditions qui infestent le code.

[cfranco]

Par rapport au cas de Java, il est clair que l'ajout des génériques a rendu le language beaucoup plus verbeux... Mais beaucoup plus sûr aussi, et finalement plus simple à utiliser (quand on les a bien compris) puisque cela évite tout un tas de casts plus ou moins hasardeux. Et au niveau du développement, on gagne forcément à détecter les erreurs dès la compilation (ou même plus précisément dès la frappe du code source, la plupart des IDE les signalant en temps réel), qu'à l'execution.

Le véritable problème est à mon avis plutôt lié au fait que bon nombre de développeurs sont incapables de structurer leur programmes. Or ce type de langage ne peut être utilisé sur un projet un peu plus gros qu'un exercice scolaire que si les méthodes, les classes, les packages sont délimitées de manière extrèmement restrictive, et logique. Dans le cas contraire, on se retrouve vite avec un boxon incompréhensible.

Mais dès qu'on travaille sur un projet un peu gros, ça implique plusieurs personnes travaillant ensemble et/ou de reprendre un code source qu'on a soi-même écrit, plusieurs mois voir plusieurs années après l'avoir vu pour la dernière fois. Et là, ce genre de fonctionnalités du langage s'avère incontournable pour réussir à s'en sortir sans trop s'arracher les cheveux.

Je programme en Java, Javascript et Objective-C, et très clairement c'est en Java que je peux avoir le plus de facilité à programmer, et c'est grâce justement à la complexité du langage. Par contre, c'est sûr que ça ne se maîtrise pas en 5min...

[Camille_B]

Python est pourtant un langage au moins autant fonctionnel qu'objet.

Pas vraiment, il lui manque la "tail recursion", un support correcte des expressions lambda, la "currification automatique" etc.

Le support des fermetures (closures) est très mauvais.

Le retrait de map, de filter et de reduce dans Python 3 est assez significatif de l'idée que GvR se fait de Python : un langage qui promeut la programmation impérative et OO.

Et dans ce domaine il est très bon !

Pour ce qui est de la programmation concurentielle, je le lui accorde... les race conditions, c'est sans doute le moyen le plus sur de se farcir des bugs.

À mon sens, c'est d'ailleurs ce qui est vicié dans ces langages, avec l'arrivée des multicores: les race conditions qui infestent le code.

Je suis plutôt d'accord. D'ailleurs j'apprécie beaucoup le GIL de Python.

Mais il y a ce qui nous semble bon et ce qui est attendue par "l'industrie"

[gangsoleil]

Pensez-vous que Java et C++ soient devenus trop complexes ?

Oui. Les dernières discussions à propos de C++0x (euh pardon, c++10) montrent bien la complexité du langage, et de ses dernières implémentations, qui ne seront d'ailleurs probablement pas toutes implémentées.

Pourquoi les langages gagnent-ils toujours en complexité ?

Parce que quant on a un marteau, tous les problèmes ont une forme de clous.

Autrement dit, quand on a un logiciel dans un langage, très peu de gens vont penser à écrire la nouvelle fonctionnalité dans un autre langage, qui serait pourtant beaucoup plus approprié.

Et d'un autre coté, c'est aussi ce qui permet d'être efficace avec un langage : plus il est complexe, plus il propose de fonctionnalités à un développeur, et plus celui-ci aura de facilite à écrire un programme. Le fait de simplifier à outrance un langage en espérant que n'importe qui devienne développeur est une erreur, qui va encore une fois mener à une vaste fumisterie :-)

Que pensez-vous de l'initiative Go ?

Encore un langage inutile et incertain. Google prêche pour sa paroisse, ce qui n'a rien de surprenant. Mais un langage a la fois compilé et interprété, qui se veut la simplification d'autres langages, ce n'est pas le premier, ni probablement le dernier. Reste à savoir s'il sera utilisé pour quelque chose ou non...

Go deviendra-t-il à terme aussi compliqué que les autres langages lorsqu'il sera beaucoup utilisé ?

[Antoine_935]

Pas vraiment, il lui manque la "tail recursion", un support correcte des expressions lambda, la "currification automatique" etc.

Le support des fermetures (closures) est très mauvais.

Il est vrai que la syntaxe des lambdas et des closures aurait pu être un peu plus légère. Mais c'est le prix pour la programmation OO je crois (bien que Javascript et... PHP s'en sortent mieux sur les closures).

Pour ce qui est du currying, il n'est pas automatique (faute encore au côté OO ?), mais functools.partial() a été introduit dans la version 2.5 de python, qui n'est pas si vieille.

Le retrait de map, de filter et de reduce dans Python 3

Si reduce a de fait disparu (et je le regrette), map et filter sont toujours là, alors que c'est justement ces derniers qui sont un peu obsolètes avec les list comprehension.

[Camille_B]

Si reduce a de fait disparu (et je le regrette), map et filter sont toujours là, alors que c'est justement ces derniers qui sont un peu obsolètes avec les list comprehension.

Je suis à la traîne moi Merci pour l'info !

(ce qui me rappelle qu'il faudrait que je jette plus d'un œil à Python 3)

[spidermario]

Il est vrai que la syntaxe des lambdas et des closures aurait pu être un peu plus légère. Mais c'est le prix pour la programmation OO je crois.

Pourquoi serait-ce le cas ? Objective Caml et Scala s'en sortent très bien.

[Antoine_935]

C'est pas bien de couper les phrases des gens Ma parenthèse s'ouvre avant le point:

Mais c'est le prix pour la programmation OO je crois (bien que Javascript et... PHP s'en sortent mieux sur les closures).

Ce que je voulais dire, cela dit, c'est qu'il n'était pas forcément possible de mieux intégrer les closures à la syntaxe du python.

[Flaburgan]

Adam de Boor (Gmail) a ainsi révélé que le service de mail en ligne de Google était intégralement écrit en Javacript (443.000 lignes de code) et ce, à la main.

Euh... Sûr ?
Je suis développeur Java et j'ai découvert il y a quelques mois Google Web Toolkit, qui est en très résumé un compilateur Java=>Javascript. Et il me semble bien que c'est ce qui a été utilisé pour les appli web de Google. Car il faut l'avouer, développer en Java est bien plus agréable qu'en Javascript...


Concernant la complexité de Java, je connais l'alternative du langage occ qui a été créé en reprenant la syntaxe de Java mais en la simplifiant, je ne connais pas très bien le sujet

[lunatix]

Et il me semble bien que c'est ce qui a été utilisé pour les appli web de Google. Car il faut l'avouer, développer en Java est bien plus agréable qu'en Javascript

sur oui, gmail n'est pas codé en GWT (rumeurs d'un gmail 2 en préparation qui le serait, mais l'actuel non.
par contre google wave l'est lui

[jayfaze]

J'ai jamais testé gwt, ça génère du javascript apparement. Mais dans la news il dise que c'est du javascript code à la main. Donc pas gwt je pense. Sinon quand il dise entièrement code a la main, il parle du côté serveur surement ? donc server side javascript pour gamil ? jsuis surpris !


Pour revenir à la news, il est clair que le gars preche pour son propre langage, c++ trop compliqué, ouais ben en même temps on peut faire plein de chose avec. Simplifie au max, ya toujours un prix à payer (performance etc ...)


edit :

N'empeche, j'ai du mal à croire que des ingenieurs osent parler de la sorte :

Selon eux, un certain nombre de mauvaises habitudes ont été prises par les programmeurs, et les langages les plus utilisés (C, puis C++, Java ou C#) y sont pour quelque chose. Pire, les personnes qui cherchent à échapper à ces langages se mettent à utiliser des langages dynamiques comme PHP, JavaScript, Perl ou Python, qui, s'ils présentent de bonnes idées, sont en revanche conçus et implémentés de façon désastreuse.

Genre j'ai besoin de créer un serveur pour un mmo en c++, mais je me dis "c'est trop compliqué, pour y échapper je vais aller vers PHP" ....

Franchement c'est pas credible.

[oxyde356]

Le vocabulaire de notre langue comporte des milliers de mots, et c'est en bonne partie pour ça que l'on arrive à détailler des choses complexes. Il en va pareil des langages informatiques, il me parait donc normal qu'ils se complexifient avec le temps. En somme ils voudraient que l'on puisse détailler aussi complexement les choses mais avec le vocabulaire d'un enfant de 3 ans quoi Bonne chance

[xelab]

Sinon quand il dise entierement code a la main, il parle du cote serveur surement ? donc server side javascript pour gmail ? jsuis surpris !

Oui très surprenant... Comme rien n'est précisé, je suppose pour ma part qu'il s'agit bien de javascript côté client.

[Aspartame]

Je me demande s'il ne s'agit pas plus ici d'une opération de self marketing pour mettre en avant un produit maison : Go
.

il devrait vendre des lessives qui lavent plus blanc , à l'envers comme à l'endroit

si j'inventais un langage , tous les autres seraient à chier !

[guence]

Moi j'attends de voir ce que sera capable Go. S'il arrive a tenir promesse je suis partant mais pour le moment je suis fan de delphi, C# qui font mon affaire.

[GanYoshi]

Un jour c'est noop, un jour c'est go, demain ça sera autre chose.

Quid du prochain flop ?

[ash.ice.loky]

Je suis d'accords avec lui et au moins on a pas ce problème avec .NET

Google ne sait plus quoi inventer, Marketing quand tu nous tiens

[UrbanBlues]

La complexité d'un programme n'est pas simplement le reflet de la complexité du language mais plutôt de la complexité de la logique du programmeur.

Quel que soit le language, il y a plusieurs façons d'arriver au résultat escompé. De par mon boulot, je suis confronté à la nécessité de modifier des programmes écrits par d'autres développeurs. Et j'observe que, pour un même language et une même fonctionnalité, les programmes vont du plus simple, compris en 5 minutes, au plus complexe, jamais maitrisé complètement, y compris, à mon avis, par le développeur lui-même !!!

Le 'pourquoi faire simple quand on peut faire compliqué' semble être une seconde nature pour certains développeurs dont la complexité des codes semble être une source permanente de fierté...

MTC

[lmontout]

Personnellement, je ne juge pas un langage à sa simplicité, rapidité mais à sa capacité à répondre à mes problématiques pondérée par le temps d'apprentissage nécessaire.

la complexité des codes semble être une source permanente de fierté

la fierté vient plutot du fait de transformer un problème très complexe (comprenez un problème d'utilisateur) en quelques lignes de codes.

C'est souvent là que ce démarquent ces nouveaux langages.