Discussion :

[ddoumeche]

Il y a un mec qui a flingué java sur le première page et j'ai envie d'en refoute une couche tout en apportant une nuance.

En fait Java, c'est un langage sympa.
(Il y a longtemps que j'en ai plus fait parce que je suis davantage sur du c++, mais sur le plan langage objet, j'avais trouvé ça pas mal)

Le vrai problème c'est la JVM.

Je rappelle que ce langage a été vendu au départ pour régler les problèmes de portabilité en intercalant la JVM entre l'applicatif et le hardware.
Résultat, c'est la langage le moins portable de tous
Chaque JVM a ses petites particularités. Selon qu'on est en windows ou en unix, en 32 ou 64 bits en little ou big endian, avec la jvm sun,oracle microsoft, open-source, version 5,6,7, headless ou pas. (et ça fait une chiée de combinaisons possibles) y'a JAMAIS un soft qui marche du premier coup ! (et je ne parle même pas du problèmes des libs exotiques compatibles avec une JVM mais pas une autre.)
Les seuls trucs fait en java qui fonctionnent bien et ne posent pas trop de soucis, c'est ceux où le developpeur a tout compilé dans une gros binaire avec une jvm embarquée.

Triste....

Ah si! encore un truc.
La faculté de certain applicatifs a bouffer toutes les ressource de la machine quelque soit le niveau de sollicitation est hallucinante.
(Certains me dirons que ce sont les applicatifs en question qui sont mal branlés mais le langage doit quand même bien s'y prêter, parce qu'il y a quand même une corrélation forte entre "soft en java" et "bouffer toutes les ressources". )

C'est de la naïveté de croire que le code est portable entre JVMs, on a l'exemple avec tout les autres langages à bytecode ou interprétés tournant sur des machines différentes.
Donc il faut prendre le standard et là, OH MIRACLE, le code tourne du premier coup notamment sur les processeurs X86 ! (normal, il n'y a plus que ca pour les desktop...)
D'ailleurs je ne comprend pas que tu cites la VM microsoft qui est abandonnée depuis 13 ans et que Microsoft n'a plus le droit de distribuer.

Sinon oui, la JVM peut-être très gourmande en mémoire car ce qu'on gagne en simplification de codage (allocation mémoire) est reporté sur l'administration. Et d'ailleurs c'est le but

[ddoumeche]

Voilà, voilà. Donc ce n'est pas le langage qui t'ennuie (vu que tu ne le connais pas ) mais bien certains prosélytes (dont je ne suis pas, chacun vit sa vie). Java est quand même le langage de loin le plus décrié sans arguments ou pour certains "évangélismes" plutôt qu'en tant que tel.

Il est décrié par les afficionados des langages concurrents vu qu'ils sont minoritaires, ce qui est de bonne guerre.
Sauf dans le cas des afficionados d'une pâle copie faite par un éditeur bien connu suite à un procès perdu en 2001

[zecreator]

Mais ton code n'est pas toujours conforme à ce que tu as voulu faire.

Lol, fait m'expliquer là ! Comment tu peux coder et obtenir quelque chose de différent ? Y a un loup là...

Beaucoup trop de commentaires mettent en avant le code "infâme" créé avec tel ou tel langage. Mais en fait, si on y réfléchit un peu, ce n'est pas le langage qui fait le code crado, c'est le développeur. Un développeur qui n'a pas de méthode, qui ne commente pas son code et qui va juste faire un copier-coller d'un bout de source trouver sur le net, quelque soit le langage, il fera du code salopé, indigeste pour ceux qui reprennent le boulot derrière. Rien à voir avec le langage lui-même. Cessons de remettre en cause les langages (les pauvres), ceux sont justes les développeurs qui ne sont pas bons...

[Traroth2]

Il y a un mec qui a flingué java sur le première page et j'ai envie d'en refoute une couche tout en apportant une nuance.

En fait Java, c'est un langage sympa.
(Il y a longtemps que j'en ai plus fait parce que je suis davantage sur du c++, mais sur le plan langage objet, j'avais trouvé ça pas mal)

Le vrai problème c'est la JVM.

Je rappelle que ce langage a été vendu au départ pour régler les problèmes de portabilité en intercalant la JVM entre l'applicatif et le hardware.
Résultat, c'est la langage le moins portable de tous
Chaque JVM a ses petites particularités. Selon qu'on est en windows ou en unix, en 32 ou 64 bits en little ou big endian, avec la jvm sun,oracle microsoft, open-source, version 5,6,7, headless ou pas. (et ça fait une chiée de combinaisons possibles) y'a JAMAIS un soft qui marche du premier coup ! (et je ne parle même pas du problèmes des libs exotiques compatibles avec une JVM mais pas une autre.)
Les seuls trucs fait en java qui fonctionnent bien et ne posent pas trop de soucis, c'est ceux où le developpeur a tout compilé dans une gros binaire avec une jvm embarquée.

C'est juste n'importe quoi. D'ailleurs, il y a énormément de développeurs qui développent sur Windows ou Mac et déploient sur un serveur Linux. Et ça marche sans aucun problème. Prétendre que la JVM ne sait pas gérer les différences de processeurs en big endian ou little endian, c'est de la pure foutaise. Parler de la JVM Microsoft non-conforme aux specs et retirée du marché depuis plus d'une décennie, c'est pas très honnête.

La seule différence, minime, c'est entre JVM 32 bits et 64 bits, dans la gestion mémoire. Une JVM 64 bits, bien sûr, peut gérer plus de mémoire. Mais en plus, son paramétrage par défaut fonctionne un peu différemment. Mais de toutes façons, qui utilise encore une JVM 32 bits ?

Triste....

Ah si! encore un truc.
La faculté de certain applicatifs a bouffer toutes les ressource de la machine quelque soit le niveau de sollicitation est halucinante.
(Certains me dirons que ce sont les applicatifs en question qui sont mal branlés mais le langage doit quand même bien s'y prêter, parce qu'il y a quand même une corrélation forte entre "soft en java" et "bouffer toutes les ressources". )

Les gens croient toujours que le Garbage Collector va tout gérer à leur place, mais ça n'est pas le cas. Il faut un minimum savoir ce qu'on fait, sinon il y a des fuites mémoires. Mais c'est facile à éviter. Bien plus qu'en C ou en C++, par exemple. Après, une appli Java ne peut bouffer toutes les ressources mémoire que si tu laisses la JVM devenir envahissante. Parce que ça se paramètre, figure-toi...

[Traroth2]

Donc on en revient encore au langage jouet... C'est bien pour developer le WE ça, mais en milieu pro c'est contre-productif. Le débuggeur sert à te faire gagner du temps. Oui tu comprends ce que TU codes, mais il faut pas oublier que, parfois, tu travailles en équipe...

Tous les navigateurs modernes ont un debugger Javascript, de nos jours. En tout cas Edge, Firefox et Chrome.

[foetus]

Rien à voir avec le langage lui-même. Cessons de remettre en cause les langages (les pauvres), ceux sont justes les développeurs qui ne sont pas bons...

Si justement

Prend un langage comme le C: il n'a pas de gestion de l'Unicode ni de chaînes de caractères (juste des fonctions basiques). Bien le code devient vite dégeu;
En C, on peut faire des void*. Certains disent que c'est de la m*rd*, qu'il ne faut pas. Bien oui c'est dangereux, mais dans certains cas, c'est la seule solution.
Toujours en C, il faut tester tous les retours, mêmes les malloc

Prend le C++, et son fameux cout . Tu t'est déjà intéressé à comment formater la sortie: héxa - décimal - octal, bourrage à gauche, ...
Et en C++, il y aussi les templates, les conversions implicites, ...

[VivienD]

[...]

Beaucoup trop de commentaires mettent en avant le code "infâme" créé avec tel ou tel langage. Mais en fait, si on y réfléchit un peu, ce n'est pas le langage qui fait le code crado, c'est le développeur. Un développeur qui n'a pas de méthode, qui ne commente pas son code et qui va juste faire un copier-coller d'un bout de source trouver sur le net, quelque soit le langage, il fera du code salopé, indigeste pour ceux qui reprennent le boulot derrière. Rien à voir avec le langage lui-même. Cessons de remettre en cause les langages (les pauvres), ceux sont justes les développeurs qui ne sont pas bons...

Je rejoins zecreator sur ce point mais me permets de mettre un bémol. Un nommage clair des types, classes, variables, objets, fonctions et autres, sans pour autant tomber dans l'excès verbal et verbeux, permet généralement de s'exempter de moult commentaires, mais pas de tous: un bel algorithme optimisé est souvent abstrus pour le profane qui aura peut-être la malchance de devoir le maintenir ou l'étudier. D'autre part, mieux vaut écrire les commentaires en anglais ou, ne serait-ce que, dans une langue franche: j'ai déjà eu à étudier un code retors en C embarqué et les commentaires ne m'ont pas aidé, du fait qu'ils étaient écrits en portugais (la terminaison -ção est très caractéristique).

[zecreator]

En fait, je pense que si tu sais développer et que tu aimes ça, qu'importe le langage, qu'importe ses faiblesses ou ses avantages, à partir du moment où tu y prends du plaisir. J'ai l'impression que les râleurs sont souvent des développeurs qui n'auraient peut-être pas choisi ce métier par passion, et qui n'ont pas l'envie de s'embêter avec des langages qu'ils ne connaissent pas, ou ne maîtrisent pas.

Pour ma part, quelque soit le contexte, le sujet et la techno à utiliser, je trouve toujours un moyen de prendre du plaisir dans ce que je fais. Chaque techno ou langage à ces contraintes, faut faire avec.

[Aqualys]

Il est inutile de s'attacher à un langage, ils ont pour vocation à être remplacé dans le temps.

Seuls restent les langages liés aux systèmes d'exploitation actifs ( par exemple le C ) et ceux dont le parc logiciels est toujours exploité ( par exemple Cobol ).

Et à moins de chercher à se satisfaire avant de satisfaire le client, détester un langage ne veut pas dire grand chose. Savoir argumenter pour présenter un projet basé sur un langage plutôt qu'un autre est capital mais il s'agit de montrer sa connaissance des langages pas de nier les capacités de l'un ou de l'autre.

A titre personnel, je n'ai jamais été fan de pascal ( et de ses dérivés ), simplement parceque pour ce que j'ai développé dans ma carrière il n'était pas adapté.

[tomlev]

Pour faire original le XML, le cousin du HTML.

Je pinaille, mais XML n'est pas un langage de programmation... c'est juste un langage de représentation de données.

Et ensuite c'est le deuxième effet Kiss Cool. Si tu crois tu vas faire un XMLOpen et XMLFind tu te trompes [lourdement].
Il faut coder des callbacks, il faut choisir son parser (DOM vs SAX), et très vite les exemples passent de 5 lignes de code à 50-60 lignes (pour rien faire), très vite on te casse les noix avec les DTD/ XPath/ ...

Il est temps de changer de langage alors ^^
En C#, tu fais ça et c'est fini

Code C# :

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

1
2
3
4
var doc = XDocument.Load("books.xml");
var books = doc.Root.Elements("book");
var lotr = books.Where(b => b.Attribute("title").Value == "The Lord of the Rings");
string author = lotr.Attribute("author").Value;

J'ai l'impression qu'en fait ce n'est pas tant à XML que tu en veux, mais aux libs qui permettent de le manipuler en C++...

Aux dernières nouvelles, Swift n'est utilisable qu'avec du matériel Apple, matériel que j’abhorre (clavier, design, connectique, OS...) alors...
Faire Mieux qu"Objectif-C, ce n'est pas franchement difficile ; intégrer les bonnes idées d'ici et là, c'est le minimum que peut faire un langage ex nihilo sinon, à quoi bon. La seule vraie force de Swift c'est sa jeunesse qui procure le sentiment de ne pas prendre le train en marche façon C++17, c'est la seule chose que j'ai remarqué quand j'en ai lu les éloges/critiques d'une communauté d'Appleboys qui n'avait de toute façon par d'autre choix que de se convertir. D'après ce que je sais des manières d'Apple, cela pourrait ne pas durer. D'ailleurs, Apple semble avoir du mal à ne pas casser la rétrocompatibilité de Swift d'une version à l'autre et il reste beaucoup de choses à améliorer. Je ne serais pas étonné que Swift finisse par être l'usine à gaz que tend à devenir tout langage de programmation au fil de son processus d'amélioration syntaxique.

OK, là au moins tu donnes des arguments, c'est déjà plus constructif
Par contre, Swift fonctionne aussi sous Linux, pas seulement sur Mac; sous Windows, rien pour l'instant.
(et je m'arrêterai là à propos de Swift, parce que ça me faisait quand même un peu mal au coeur de prendre la défense Apple )

[ArchiTech]

J'ai constaté au cours de mon expérience en info (plus de 15 ans), que (en général) ceux qui développent avec des langages objet n'aiment plus trop les langages non objet (pas assez rigoureux, sources de plus de de failles et de bugs, moins rapide pour le développement, ...), même s'ils les ont utilisés à une époque. Par contre, ceux qui ne développent pas couramment avec des langages objet n'aiment pas trop ces langages (trop lents à l'exécution, complexes, ...).

Bref, souvent, on aime ce que l'on connait ou utilise couramment, et on n'aime moins ce que l'on ne connait pas bien (parfois on déteste aussi ce qu'on connait, car on l'a réellement utilisé, et on a pu se rendre compte de ses défauts )

Ce qui serait intéressant, c'est d'avoir ce sondage en fonction du profil / domaine d'expérience de celui qui répond (développeur temps plein ou non, infos embarquée ou système d'information, ...).

[Florian_PB]

Bref, souvent, on aime ce que l'on connait ou utilise couramment, et on n'aime moins ce que l'on ne connait pas bien (parfois on déteste aussi ce qu'on connait, car on l'a réellement utilisé, et on a pu se rendre compte de ses défauts )

J'approuve, surtout la partie où on déteste ce que l'on connait (j'en peux plus du VBScript, achevez moi, même le Javascript a un typage plus fort que ça !!!)

[foetus]

Je pinaille, mais XML n'est pas un langage de programmation... c'est juste un langage de représentation de données.

Tu as raison ... alors je pinaille aussi

Tu peux compiler de l'Objective-C sous Linux et Windows : voir mon message, 71

[tomlev]

Tu as raison ... alors je pinaille aussi

Tu peux compiler de l'Objective-C sous Linux et Windows : voir mon message, 71

Si tu veux... mais ce n'est pas moi qui ait dit qu'on ne pouvait pas compiler de l'Objective-C sous Linux et Windows

[LSMetag]

Je te dirais que si t'arrive pas à te faire au prototype, tu peux passer par TypeScript. Je bosse sur un projet en Typescript depuis 2 mois et c'est pas mal du tout. Après comme c'est juste une surcouche « objet » à Javascript... Ce qui arrivera en fait en vrai ES6/7 (Class, Collection, Annotation, etc.)

Et oui, pour PHP, c'était pour répondre à ce que j'avais lu avant.

Personnellement pour le langage qui m'a le plus rebuté c'est le langage de templating de EzPublish... et pas loin dernière les Macro Tex. J'ai jamais pu m'y faire, c'est comme les langages basé sur les tabulations, je trouve ça absurde, du coup ça m'énerve. Y'en a qui trouve ça génial, bha pas moi. Pourtant j'essaie, avec Godot Script.

Depuis que j'ai un PC j'ai eu l’occasion de touché quelques trucs, dont j'en ai oublié pas mal : Pascal, Assembleur, JS, AS2, AS3, Haxe, PHP4, PHP5, Java, C#, Groovy, Batch, Bash, VBA (Excel), Basic (Calc). Dire qu'à la base j'étais plus graphiste. C'est peut-être pour ça que j'adore le CSS.

J'ai jamais testé Dart, en même temps, c'est supporté uniquement par Chrome, donc je ne trouve pas de vraie raison de l'utiliser.

Attention ! Au niveau Web, Dart passe maintenant exclusivement par la compilation vers du Javascript via "Dart2JS". Il est donc compatible tous navigateurs. Sa VM est désormais dédiée à la programmation serveur et au débuggage (client et serveur). Elle a même été abandonnée pour Chrome. Le code compilé en Javascript est de bonne facture, c'est ça qui est intéressant. Il peut être même plus performant que du code idiomatique dans certains cas.

Je suis actuellement sur TypeScript. Je me dis que Microsoft doit avoir pallié aux problèmes de contrôle du code inhérents à Javascript. Mais je n'en suis encore qu'au tout début. Je mène de front le passage à TypeScript et de PolymerDart à PolymerJS, avec un fichier de description pour le langage TypeScript.

Quand je maîtriserai TypeScript, je resongerai à l'approfondissement de JS. TypeScript est ma solution tutorial pour le moment, en parallèle avec Dart.

[dfiad77pro]

10,2% d'avis négatifs sur C# et aucun argument contre dans la discussion, ça serait cool que les gens qui aient votés contre argumentent aussi !

[Shepard]

10,2% d'avis négatifs sur C# et aucun argument contre dans la discussion, ça serait cool que les gens qui aient votés contre argumentent aussi !

J'ai voté C#, principalement à cause de l'éditeur Visual Studio, ainsi qu'à cause du nombre de technologies à maîtriser pour pouvoir l'utiliser correctement (à l'époque : LINQ, "reports", Microsoft SQL Server, WPF, et plusieurs autres dont je ne me souviens plus).

Par ailleurs, google m'a souvent amené à tomber sur des "Code Snippets" plutôt que sur la doc ...

Et pour finir, certains de mes collègues utilisaient VS d'une manière qui m'horripilait ... En gros la souris était utilisée environ 50% du temps.

Envoyez les pouces rouges !

[dfiad77pro]

J'ai voté C#, principalement à cause de l'éditeur Visual Studio, ainsi qu'à cause du nombre de technologies à maîtriser pour pouvoir l'utiliser correctement (à l'époque : LINQ, "reports", Microsoft SQL Server, WPF, et plusieurs autres dont je ne me souviens plus).

Par ailleurs, google m'a souvent amené à tomber sur des "Code Snippets" plutôt que sur la doc ...

Et pour finir, certains de mes collègues utilisaient VS d'une manière qui m'horripilait ... En gros la souris était utilisée environ 50% du temps.

Envoyez les pouces rouges !

J'avous je ne comprends pas l'argument SQL server, WPF.
En Java, Php, etc. tu doit bien aussi maitriser d'autres bases/Framework (JavaFx, GWT et coté base : MySQL, oracle etc., qui sont aussi pleinement disponibles sur .net).

Autant en Winforms je comprends l'utilisation de la souris , mais en WPF non. Du coté de Linq ça me manque énormément en Java. . Je trouve que le code produit est vraiment lisible et puissant.

Bref .Net et C# demandent pas mal de connaissances pour être utilisés correctement , mais c'est aussi ( et encore plus) le cas de Java qui dispose de nombreux Frameworks, implémentations et configurations.

Coté Visual Studio, à part la lourdeur , je ne vois pas trop les reproches qu'on peut lui faire ( comparé à Eclipse [ lourds aussi ormis l'installation], Qt notamment).

[tomlev]

J'ai voté C#, principalement à cause de l'éditeur Visual Studio

A part le côté usine à gaz, qu'est-ce que tu lui reproches exactement ? Je l'utilise depuis 15 ans, et j'ai toujours trouvé que c'était un très bon outil, et même un atout majeur pour le développement .NET.

ainsi qu'à cause du nombre de technologies à maîtriser pour pouvoir l'utiliser correctement (à l'époque : LINQ, "reports", Microsoft SQL Server, WPF, et plusieurs autres dont je ne me souviens plus).

Je trouve ça un peu bizarre comme argument. Comme l'a souligné dfiad77pro, c'est pareil dans d'autres technos... Si tu as besoin d'une UI, tu dois maîtriser le framework UI utilisé, quel que soit le langage. Si tu dois faire des reports, à moins de te les taper à la main, il faut maîtriser la lib de reporting utilisée. Si tu dois accéder à une DB, il faut comprendre comment elle fonctionne... Quant à Linq, c'est juste une façon plus simple de manipuler les données ; tu pourrais faire la même chose à la main avec des boucles (pour des données en mémoire) ou en te tapant le SQL à la main (pour des données en DB).

Par ailleurs, google m'a souvent amené à tomber sur des "Code Snippets" plutôt que sur la doc ...

Je ne sais pas comment tu cherches, mais je n'ai jamais eu de problèmes à trouver de la doc (sauf pour certaines libs notoirement mal documentées, genre NHibernate). Perso je tape "msdn <nom de la classe ou méthode>" et je tombe directement sur ce que je cherche.

Du coté de Linq ça me manque énormément en Java.

En Java 8 tu as les streams, qui sont à peu près l'équivalent de Linq to Objects. Ce n'est pas tout à fait aussi puissant, il n'y a pas de types anonymes ni d'inférence de type (var) par exemple, mais c'est déjà pas mal pour tout ce qui est filtrage/projection/tri etc.

[LiTiL_DiViL]

Arguments imparables... ^^. Mais encore?

Qu'est-ce qui est illisible? Le code produit? -> responsabilité du développeur. Les fonctions natives? Quelques exemples seraient bienvenus...
Qu'est-ce qui est bugué? J'ai pondu des milliers et des milliers de lignes en code en VBA, je n'ai que très rarement rencontré des bugs du langage. Là aussi, des exemples seraient les bienvenus.
En quoi l'IDE est-il pourri? L'autocomplétion est assez fonctionnelle, l'arborscence du projet, pour minimaliste qu'elle soit, est claire et fonctionnelle par rapport aux projets développés.
Le modèle objet de Word n'est pas très convivial, mais ce n'est pas tant lié à VBA qu'au modèle objet en lui-même. Le modèle objet Excel est quant à lui exceptionnellement bien développé.

Mais hélas, le VBA souffre du fait d'être malaimé par les développeurs. Je suppose que ça ne fait pas "pro" de développer en VBA. Pourtant, comme avec beaucoup d'autres langages, on peut faire de la merde ou de la belle ouvrage.

Désolé c'est juste mon ressenti personnel et je ne suis pas un pro. Des quelques truc que j'ai eu à faire il y a quelques années et avec Office 2007.
D'ailleur au passage je me moque de faire pro ou pas (j'ai passé l'age), c'est juste que quand tu as envie de faire un truc simple et que tu as l'impression de faire des tours et des détours, voir de recommecer à zéro pour un langage qui est censé de simplifié la vie, ben pour moi l'objectif n'est pas rempli.

Il y a surement plein d'inexactitude dans ce que je vais écrire, mais cela remonte et je n'ai pas pratiqué assez pour être précis et cela a peut être changé :

- Lisibilité : j'aime le code compact qui se lit naturellement, en vba désolé j'y arrive pas. j'ai des souvenirs de déclarations de variable fastidieuses. A cela j'ajoute la lourdeur de certaines API (j'ai un peu bossé avec outlook et le ruban office...). au vu des difficultés , des centaines de methodes de propriétés, pour te rendre compte que cela ne couvrira pas ton besoin, il faut passer par d'autre API. Le pire c'est qu'elles peuvent se ressembler en terme de syntaxe et être parfaitement incompatible.

- Alors c'est un langage objet, sauf que de mémoire t'as pas d'héritage... Cool !

- J'ai de vague souvenir de message d'erreur absolument imbuvable. Ou alors de blocage du genre tu peux pas parcourir ton code, lorsque le programme est interrompu.

- L'explorateur des API ne m'a pas convenu du tout, si ma mémoire est bonne il n'y a pas de fonction de refactoring, la complétion n'affiche pas la doc de mémoire et dans certain cas pas les méthodes (mais je ne me souviens plus pourquoi...)

Au final je dois dire que je suis toujours arrivé aux objectifs, mais bon jamais sans douleur...

Après c'est un avis personnel et je ne suis pas un "dev" pro