java vs c++

GangsterAutorisé · Le 22/09/2013, à 12:30

Question subsidiaire : Pourquoi java a une sale réputation en termes de sécurité ?
Est ce que c'est à cause de la JVM qui n'est quasi jamais à jour sur les postes clients ?
Est ce que les failles dans une JVM sont plus facilement exploitables ? Pourquoi ?
Est ce que c'est pour une autre raison liée à la structure du langage ?
Est ce que c'est parcequ'Oracle néglige la sécurité au profit d'autres critères ?

En tout les cas les mises à jour de la jvm s'enchainent à une vitesse impressionante (parfois tous les 15j, ça fait peur quand même)

grim7reaper · Le 22/09/2013, à 13:53

GangsterAutorisé a écrit :

Question subsidiaire : Pourquoi java a une sale réputation en termes de sécurité ?

Ce n’était pas le cas avant la reprise par Oracle.
Donc je pense que ça n’y est pas pour rien. Qu’ils soient directement responsable (en se touchant la nouille) ou qu’ils aient été le déclencheur (leur politique aurait froissé certains hackeurs (toutes les failles ne sont pas trouvé par des gens mal intentionnés) qui du coup se seraient soudainement penché sur le sujet histoire de leur faire une sale pub).
Y’a sûrement un peu des deux.

GangsterAutorisé a écrit :

Est ce que c'est à cause de la JVM qui n'est quasi jamais à jour sur les postes clients ?

Ça doit jouer aussi, mais même en étant à jour de nouvelles failles étaient découverte.

GangsterAutorisé a écrit :

Est ce que les failles dans une JVM sont plus facilement exploitables ? Pourquoi ?

Il me semble que la majorité des failles récentes étaient exploitable via les applet Java dans le navigateur. Le truc quasiment disparu que plus personne n’utilise.
Ce qui pourrait d’ailleurs expliquer le manque de maintenance sur cette partie de Java : moins utilisé donc moins d’attention porté dessus donc potentiellement plus de failles dedans.

GangsterAutorisé a écrit :

Est ce que c'est pour une autre raison liée à la structure du langage ?

Pour certaines failles, je me rappelle que ça venait d’un design un peu foireux dans certains bout de l’API standard (mais ils ont corrigé du coup), ouais.
Mais ce n’était pas le cas de toutes les failles.

Après Java se traîne aussi une sale réputation qu’il ne mérite plus (enfin, beaucoup moins) au niveau de ses perf’.
C’est largement moins pourri que ce que les ignorants veulent bien dire (la JVM est un petit bijou d’ingénierie mine de rien, surtout niveau compilation JIT et garbage collection).
Après on est d’accord, c’est plus lourd que du C++, mais chaque langage à ses avantages et inconvénients.
Par contre, bon le JEE c’est complément bloated d’un bout à l’autre… (et c’est de là aussi que vient la répution de Java, mais Java != JEE)

Haleth · Le 22/09/2013, à 14:28

Après Java se traîne aussi une sale réputation qu’il ne mérite plus (enfin, beaucoup moins) au niveau de ses perf’.
C’est largement moins pourri que ce que les ignorants veulent bien dire (la JVM est un petit bijou d’ingénierie mine de rien, surtout niveau compilation JIT et garbage collection).

Mouais
Enfin, y'a la théorie, et la pratique

Dans la pratique, des programmes java qui ne s'identifient pas immédiatement comme tel ("bon sang, il est vachement obèse ce programme, il est pas fait en java par hasard ? Hah bah ouais"), j'en ai de mémoire rencontré un seul (j'te parle de projets assez conséquent, pas du helloworld)

Un piti article fut publié dans le dernier Linux Magazine, écrit par Fabienne Sandoz, dont voici un bref résumé.
L'article décrit assez bien les raisons de la lourdeur de java: c'est un langage batard

1) Les factory
java n'est pas un langage objet, on ne peut redéfinir le code executé lors de l'instanciation
Les dev java font donc des factory à tour de bras: on fait un objet pour faire des objets (oui, c'est abscons)

2) Les interfaces
Les interfaces sont prévus pour detruire l'une des forces de l'objet: polymorphisme, absence de typage etc
Quand je prend un objet et que j'appelle une méthode, qu'importe le type de l'objet: pourvu qu'il possède la méthode, alors c'est ok
Les interfaces détruisent cette possibilité

3) Les aspects (avec en exemple : comment auditer le code)
Toujours du fait de la nature non-objet de java, on ne peut définir ce qui s'execute lorsqu'une méthode qui n'existe pas est appelé (pas question de faire une exception par méthode, et d'enchainer les try catch .. quoique cela match bien la mentalité java, AMHA). Il existe donc des tricks qui permettent de faire cela, au prix d'une complexité et d'un cout en performance important

Je pourrais rajouter les getters & setter:
Dans un vrai langage objet (pour info, c'est possible en PHP.. c'est dire), on peut définir ce qui est executé lorsque l'on récupere le contenu d'une variable, ou lorsqu'on le modifie. En java, ben tu peux pas, il est donc commun de créer une armée de fonctions bidons, ce qui complexifie drastiquement le code source, et détruit complétement la notion d'encapsulation objet (boite noire etc)

Pour conclure, ben en fait java c'est du batard, ca prend des notions objets (mais pas toute, ce qui casse tout) et des notions procédurales (pour aller plus vite, mais c'est plus que limité du fait de l'aspect objet)

Bref, langage de merde ..

grim7reaper · Le 22/09/2013, à 15:39

Haleth a écrit :

j'en ai de mémoire rencontré un seul (j'te parle de projets assez conséquent, pas du helloworld)

Et bien sûr, de ton cas personnel (les logiciels que tu connais) tu en tires une généralité. Rigoureux ça :]

Tiens, moi récemment j’ai écrit un code qui doit traiter de gros fichiers textes (~ 2Go étant la taille la plus courante) dans un dossier. Il les découpe en plus petit fichiers (qui peuvent quand même taper à ~200 Mo, pour du texte c’est pas mal), puis il fait des merges quand c’est nécessaire et enfin il fait une analyse de chaque fichier généré.
J’ai écris ce code de manière très basique (j’ai une classe qui ouvre mon gros fichier et qui permet de le parcourir par bloc via un itérateur ce qui me permet d’utiliser mon objet dans un foreach). L’algo de découpe est basiquement :
- j’ouvre le gros fichier
- pour chaque bloc, je créé un nouveau fichier et j’écris le bloc dedans.
Et là, la JVM me parallélise automagiquement l’exécution de cette partie du programme sur tout mes cœurs (8 en l’occurence). Je n’ai rien fait de spécial pour ça.
Pour faire la même en C++, Python ou Ruby par exemple bah j’attends toujours.
Oui c’est faisable, mais va falloir le faire explicitement.

Au passage, la consommation mémoire était tout ce qu’il y a de plus raisonnable (en considérant que les String en Java c’est du 16-bit bien sûr), idem pour le temps de traitement (je n’aurait pas gagner grand-chose à le faire en C++, surtout si je ne prend pas le temps de parallèliser à la main).

Haleth a écrit :

1) Les factory
java n'est pas un langage objet, on ne peut redéfinir le code executé lors de l'instanciation
Les dev java font donc des factory à tour de bras: on fait un objet pour faire des objets (oui, c'est abscons)

Lapin compris ce que tu veux dire par « redéfinir le code executé lors de l'instanciation ».
Sinon, Factory c’est un design pattern que j’ai aussi vu en Python, Ruby, PHP (qui sont bien plus dynamique que Java). Donc je ne comprends pas trop l’argument là
Après, oui c’est vrai qu’en Java il y’a eu un effet de mode merdique qui a été de faire des factory de factory de factory
Mais perso j’ai jamais eu besoin de faire ça dans mon code.
Encore une fois, qu’il y ai beaucoup de développeurs moisi pour un langage ne fait pas du langage un truc de merde.
Regarde le C, beaucoup de gens commencent par ce langage donc il y a un nombre hallucinant de code à vomir un peu partout. Pourtant, le C permet de faire des trucs géniaux (au pif : Linux, Unix, BSD, Python, …)

Haleth a écrit :

Les interfaces sont prévus pour detruire l'une des forces de l'objet: polymorphisme, absence de typage etc
Quand je prend un objet et que j'appelle une méthode, qu'importe le type de l'objet: pourvu qu'il possède la méthode, alors c'est ok
Les interfaces détruisent cette possibilité

La force de l’objet ce n’est pas détruire le typage >_<. Ce qu’il faut pas lire
Et en quoi une interface détruit le polymorphisme ?

Au passage tu mélanges joyeusement duck typing n’est pas une condition pour faire de l’OOP (même si ça aide, ça reste une approche parmi d’autres).
Au passage, le duck typing c’est du typage, comme son nom l’indique (donc pour l’absence de typage, tu repasseras…)

Haleth a écrit :

Toujours du fait de la nature non-objet de java, on ne peut définir ce qui s'execute lorsqu'une méthode qui n'existe pas est appelé (pas question de faire une exception par méthode, et d'enchainer les try catch .. quoique cela match bien la mentalité java, AMHA). Il existe donc des tricks qui permettent de faire cela, au prix d'une complexité et d'un cout en performance important

AOP != OOP
C’est pas un manque spécifique à Java ça. C++ ne le fait pas d’AOP de base aussi (mais on peut l’ajouter via une bibliothèque, comme en Java tient).

Haleth a écrit :

Je pourrais rajouter les getters & setter:

Non, ne rajoute rien. Explique déjà mieux tes exemples précédents, ça sera un bon début…

Haleth a écrit :

Dans un vrai langage objet

Tiens par curiosité, comment tu définis un langage objet ?
Parce que ta définition me semble bien particulière quand même, donc je voudrai voir si c’est une définition un minimum sérieuse ou si c’est juste une définition maison sortie de derrière les fagots.

Haleth a écrit :

il est donc commun de créer une armée de fonctions bidons, ce qui complexifie drastiquement le code source, et détruit complétement la notion d'encapsulation objet (boite noire etc)

Ouais enfin le « tout en private, mais un couple getter/setter pour chaque attribut » c’est une pratique bien pourri au moins aussi courante en C++.

Haleth a écrit :

Bref, langage de merde ..

Huhu, après avoir lu ton message ça se résume assez bien par « trololo Java c’est caca ».
Au final ton post c’est juste du vent : pas d’exemple concret, pas d’arguments technique ou théorique.
Ça sonne creux. Ça veut donner une apparence de je sais de quoi je parle, mais c’est vide derrière

Tu peux approfondir (auquel cas, on peut peut-être avoir un débat intéressant) ?
Ou tu veux juste chier sur Java comme un boutonneux (auquel cas, je te laisse troller ici tout seul) ?

Je suis pas un pro-Java (clairement pas…). Il a un bon paquet de défauts (les génériques de Java ne valent pas les templates de C++ ou D, les types de bases ne sont pas des objets, il est trop orienté classe…) et je ne le nie pas, mais ce n’est pas une raison pour raconter de la merde.
Moi aussi avant j’étais prompt à cracher sur Java. Maintenant j’essayer d’être un peu plus objectif, c’est tout.

Luc Hermitte · Le 23/09/2013, à 12:53

@GangsterAutorisé, Avec sa machine virtuelle, Java est un mini-OS. Là où l'on pouvait cibler des OS, on peut maintenant cibler Java qui est très répandu. Chose qui est très attrayante. De plus, dans les entreprises, ou sur des machines en production, les montées de versions ne se font pas tous les quatre matins. Car sur les machines en production, l'environnement est figé pour des années et des années. Car toute montée de version peut vouloir dire régression, et donc si elle est faite et pas accompagnée par les développeurs du logiciel (qui tourne en Java), pas sûr que les garanties & cie s'appliquent immédiatement. Bref, une montée de version, ça a un coût, et donc ce n'est pas systématisé sur les postes clients -- après cela peut varier d'un projet/client à l'autre.

Après, c'est lié qu'il y a des failles partout, et vu le style du C++ dans JNI, le style du C++ dans le reste ne doit pas être terrible AMA. Et de fait, ben .. il y a bien plus de failles que ce qu'il pourrait y avoir dans un soft écrit en C++ moderne. Et vu qu'il y a beaucoup de lignes de code, j'imagine, ben il y a des failles. Suffit aux spécialistes de les trouver.

@Haleth, On pourrait faire les mêmes reproches au C++ : non interprété, et il faut savoir à qui on envoie les messages -- hormis le duck typing offert par les templates, mais si tu as un peu suivi l'actualité, tu auras vu que la communauté C++ recherche à avoir un équivalent aux interfaces : les concepts, chose que l'on connait (même si non vérifiée automatiquement par les compilateurs) depuis la STL historique. Et ça serait la même chose pour Eiffel : on sait ce que l'on émet et à qui. Personnellement, je préfère 100 fois un typage fort qui oblige les développeurs à réfléchir à ce qu'ils font plutôt que de balancer des messages dans la nature pour les laisser attraper par qui veut bien le faire, et que d'écrire 150 TU qu'un couple compilo+typage renforcé rend obsolètes.
À propos des interfaces, à la Java/COM/CORBA/..., je trouve qu'elles ne vont pas assez loin, car elles n'offrent rien pour faire de la PpC (sans passer par des préprocesseurs ou assimilé). Eiffel a ça en natif. C++ le permet en natif (via le pattern NVI). D, je ne sais plus.

Relativement aux getters & setters, ils sont dans la tradition orientée données et non orientée objets. Au lieu de réfléchir aux services rendus, on continue à réfléchir aux données stockées, et on les manipule directement au lieu de laisser les objets englobant les gérer -- et on viole au passage la Loi de Déméter. C'est comme si on allait à une blanchisserie, et que l'on manipulait soi même les détergents et les machines. Ca s'appelle une laverie automatique (orienté données), pas une blanchisserie (orienté services/objets).
Bref, plein de littérature sur "why setters are evil?". Cette approche un attribut == un getter+un setter est plus endémique en Java à cause des Beans, et d'IDE qui les génèrent automatiquement. Du coup, c'est rentré dans les mœurs, sous prétexte "et si jamais il fallait faire une vérification ou autre?", chose qui contredit instantanément la sémantique du verbe "to set", car nous avons un "set if" (cf l'article d'Emmanuel Deloget sur son blog). En C++, les setters se font tirer à vu sur les forums francophones comme dvpz, sdz/oc.

Haleth · Le 23/09/2013, à 13:30

Et bien sûr, de ton cas personnel (les logiciels que tu connais) tu en tires une généralité. Rigoureux ça :]

Ben, c'est des softs commun, et globalement oui, on peut extrapoler une vérité générale à partir d'un échantillon représentatif de la population

Tiens, moi récemment j’ai écrit un code qui doit traiter de gros fichiers textes (~ 2Go étant la taille la plus courante) dans un dossier. Il les découpe en plus petit fichiers (qui peuvent quand même taper à ~200 Mo, pour du texte c’est pas mal), puis il fait des merges quand c’est nécessaire et enfin il fait une analyse de chaque fichier généré.
J’ai écris ce code de manière très basique (j’ai une classe qui ouvre mon gros fichier et qui permet de le parcourir par bloc via un itérateur ce qui me permet d’utiliser mon objet dans un foreach). L’algo de découpe est basiquement :
- j’ouvre le gros fichier
- pour chaque bloc, je créé un nouveau fichier et j’écris le bloc dedans.
Et là, la JVM me parallélise automagiquement l’exécution de cette partie du programme sur tout mes cœurs (8 en l’occurence). Je n’ai rien fait de spécial pour ça.
Pour faire la même en C++, Python ou Ruby par exemple bah j’attends toujours.
Oui c’est faisable, mais va falloir le faire explicitement.

Ouais, moi j'utilise split, ca fait une ligne de bash

Après, oui c’est vrai qu’en Java il y’a eu un effet de mode merdique qui a été de faire des factory de factory de factory roll

Ce qui, intrinséquement, influe le langage : ces gens "expert en machin" produisent des libs et des softs, lesquels deviennent indispensables pour programmer. Ils deviennent des modèles pour les piti nouveaux -> la boucle est bouclé.
Exemple: eclispe, merveille d'obésité et de monstruosité.
Qui dev en java sans eclipse actuellement ? Si ce n'est lui, c'est donc son frère netbeans ..

Non, ne rajoute rien. Explique déjà mieux tes exemples précédents, ça sera un bon début…

Sans faire de la pub, procure toi le mag, j'ai la flegme de recopier la demi-douzaine de pages ..

Tiens par curiosité, comment tu définis un langage objet ?
Parce que ta définition me semble bien particulière quand même, donc je voudrai voir si c’est une définition un minimum sérieuse ou si c’est juste une définition maison sortie de derrière les fagots.

Ben, j'peux te reprendre la définition de wikipedia.
Un langage objet utilise :
- des objets. Un objet est une structure de données valuées et cachées qui répond à un ensemble de messages. (ce que fait java)
Certains attributs et/ou méthodes (ou plus exactement leur représentation informatique) sont cachés : c'est le principe d'encapsulation. Ainsi, le programme peut modifier la structure interne des objets ou leurs méthodes associées sans avoir d'impact sur les utilisateurs de l'objet. (ce que ne fait pas java, enfin ce qu'il fait d'une manière détournée et contraignante, via les getter/setter, dont l'utilisation détruit de facto le principe d'encapsulation)
- les objets sont typés : (« Comment l'appeler ? ») et la sémantique (« Qu'est ce qu'il fait ? ») (ce qui pour moi est plutôt en rapport avec la documentation du projet, m'enfin)
Y'a deux typages, le typage dynamique et le typage statique (qu'utilise java, qui requiert des interfaces ou la présence d'héritage, et est à mes yeux mauvais)
- la rédéfinition: |i]La programmation objet permet à un objet de raffiner la mise en œuvre d'un message défini pour des objets d'un type parent, autrement dit de redéfinir la méthode associée au message : c'est le principe de redéfinition des messages (ou overriding en anglais).|/i] : chaque méthode d'un objet peut redéfini (on peut redéfinir une méthode d'un objet en java, sans créer une autre classe ?)
- Notion de classe : on définit des modèles d'objet pour faciliter l'utilisation a posteriori

Pour le coup, je trouve que la page wikipedia résume assez bien les choses (PS: je ne suis pas l'auteur de cette page ..)

Ouais enfin le « tout en private, mais un couple getter/setter pour chaque attribut » c’est une pratique bien pourri au moins aussi courante en C++.

Et c'est tout aussi méprisable, je te rassure.

Au final ton post c’est juste du vent : pas d’exemple concret, pas d’arguments technique ou théorique.
Ça sonne creux. Ça veut donner une apparence de je sais de quoi je parle, mais c’est vide derrière sad
Tu peux approfondir (auquel cas, on peut peut-être avoir un débat intéressant) ?

Beh c'est post résumé d'un article, ca reste un résumé mal torché d'un papier;
Si le speech de wikipedia ne précise pas assez les choses, n'hésite pas à poser des questions ou mettre en valeur des points louches; N'hésite pas à me corriger si je faute;

Relativement aux getters & setters, ils sont dans la tradition orientée données et non orientée objets. Au lieu de réfléchir aux services rendus, on continue à réfléchir aux données stockées, et on les manipule directement au lieu de laisser les objets englobant les gérer -- et on viole au passage la Loi de Déméter. C'est comme si on allait à une blanchisserie, et que l'on manipulait soi même les détergents et les machines. Ca s'appelle une laverie automatique (orienté données), pas une blanchisserie (orienté services/objets).
Bref, plein de littérature sur "why setters are evil?". Cette approche un attribut == un getter+un setter est plus endémique en Java à cause des Beans, et d'IDE qui les génèrent automatiquement. Du coup, c'est rentré dans les mœurs, sous prétexte "et si jamais il fallait faire une vérification ou autre?", chose qui contredit instantanément la sémantique du verbe "to set", car nous avons un "set if" (cf l'article d'Emmanuel Deloget sur son blog). En C++, les setters se font tirer à vu sur les forums francophones comme dvpz, sdz/oc.

En gros, c'est le fond de ma pensée;

grim7reaper · Le 23/09/2013, à 14:41

Luc Hermitte a écrit :

Après, c'est lié qu'il y a des failles partout, et vu le style du C++ dans JNI, le style du C++ dans le reste ne doit pas être terrible AMA. Et de fait, ben .. il y a bien plus de failles que ce qu'il pourrait y avoir dans un soft écrit en C++ moderne. Et vu qu'il y a beaucoup de lignes de code, j'imagine, ben il y a des failles. Suffit aux spécialistes de les trouver.

Il me semble que la plupart des dernières failles de Java venait de la partie implémenté en Java, pas en C++.
En tout cas, il y en avait au moins deux qui venait de l’API Reflector + une où on pouvait chopper des droits (de manière réglo hein) permettant de désactiver le SecurityManager.

Luc Hermitte a écrit :

(cf l'article d'Emmanuel Deloget sur son blog).

Très bon blog au passage

Haleth a écrit :

Et bien sûr, de ton cas personnel (les logiciels que tu connais) tu en tires une généralité. Rigoureux ça :]
Ben, c'est des softs commun, et globalement oui, on peut extrapoler une vérité générale à partir d'un échantillon représentatif de la population

Reste à savoir si tu en as vu suffisamment pour que ça soit représentatif
Mais oui, en général les soft’ Java sont bloated, mais c’est pas totalement la faute du langage (forcément, de base il est plus lourd que le C++, ça je ne le nie pas mais ce n’est pas non plus le veau que l’on pense).

Je vois 2 problèmes à Java :
1) c’est un langage assez facilement abordable, donc forcément il y a plus de mauvais développeurs (surtout si le développeur ne connaît que Java, et n’a aucune idée de comment fonctionne un ordinateur, l’allocation mémoire, …) et fatalement plus de logiciels mal pensé et codé avec les pieds (et donc un gouffre un ressources => Java c’est lent).
2) Java a été très vendu aux entreprises, et là pas mal y ont vu l’occasion de se faire des joyeuses en or (suffit de mater les SSII pour le cas français). Le truc est simple : il suffit de faire des trucs over-engineered, un bon gros framework tentaculaire et bloated qui se configure via trouzmille fichier XML et qui va générer une chiée d’objet à la moindre action. Le truc est tellement complexe pour rien que tu vas pouvoir louer tes consultants et autres experts à prix d’or. C’est un truc omniprésent en JEE, mais ça a aussi déteint sur le Java de base

Haleth a écrit :

Ouais, moi j'utilise split, ca fait une ligne de bash

Bien essayé mais :
- le logiciel devait tourner sous Windows XP (je bosse sous Linux, mais le mec qui en avait besoin était sous Windows XP), donc bon le bash ça s’annonçait mal.
- les blocs n’était pas de taille fixe (c'eût été trop simple ^^).

Haleth a écrit :

Après, oui c’est vrai qu’en Java il y’a eu un effet de mode merdique qui a été de faire des factory de factory de factory roll
Ce qui, intrinséquement, influe le langage : ces gens "expert en machin" produisent des libs et des softs, lesquels deviennent indispensables pour programmer. Ils deviennent des modèles pour les piti nouveaux -> la boucle est bouclé.

Je suis d’accord avec toi.
Ça ne rend pas le langage mauvais en lui-même (ce n’est qu’un outil), mais ouais l’environnement autour est pas reluisant.
C’est pour ça que j’évite pas mal certaines bibliothèques Java car trop bloated à mon goût (quitte à me coder un petit truc léger si besoin).

Haleth a écrit :

Qui dev en java sans eclipse actuellement ? Si ce n'est lui, c'est donc son frère netbeans ..

Oui, ça c’est un des gros points négatifs de Java (cette fois c’est bien la faute du langage).
C’est quasiment inutilisable en dehors d’un IDE
J’ai bien fait du Java via Vim (même Emacs à une époque). Pour certains trucs ça va, et puis pour d’autres tu te rends compte que c’est extrêmement chiant et laborieux sans IDE.
Ça c’est vraiment un défaut de Java pour le coup, oui.

Haleth a écrit :

Ben, j'peux te reprendre la définition de wikipedia.

Tu as un truc bizarre dans ton URL : "?lulz=strike+conceal+Manhattan", je sais pas ce que ça fiche là oO

Haleth a écrit :

Un langage objet utilise :
- des objets. Un objet est une structure de données valuées et cachées qui répond à un ensemble de messages. (ce que fait java)
Certains attributs et/ou méthodes (ou plus exactement leur représentation informatique) sont cachés : c'est le principe d'encapsulation. Ainsi, le programme peut modifier la structure interne des objets ou leurs méthodes associées sans avoir d'impact sur les utilisateurs de l'objet. (ce que ne fait pas java, enfin ce qu'il fait d'une manière détournée et contraignante, via les getter/setter, dont l'utilisation détruit de facto le principe d'encapsulation)

Si, Java peut le faire.
Tant que c’est privée (donc structure interne et méthodes internes), tu peut modifier autant que tu veux.
Alors oui, forcément si tu mets des get/set partout, c’est comme si tout était en publique et donc tu ne peux plus.
Mais de base, tu peux le faire en Java.
Après forcément, Java c’est statique donc on est loin de ce que l’on peut faire niveau modification par rapport au Ruby (ou tu peux presque tout redéfinir lors de l’exécution).
Mais le contrat de base me semble rempli.

Haleth a écrit :

- les objets sont typés : (« Comment l'appeler ? ») et la sémantique (« Qu'est ce qu'il fait ? ») (ce qui pour moi est plutôt en rapport avec la documentation du projet, m'enfin)
Y'a deux typages, le typage dynamique et le typage statique (qu'utilise java, qui requiert des interfaces ou la présence d'héritage, et est à mes yeux mauvais)

Qu’est ce que tu reproches aux interfaces et à l’héritage (si ce n’est que ce dernier est souvent utilisé à tort et à travers, violant souvent le principe de substitution de Liskov au passage) ?
Héritage que l’on retrouve aussi dans les langages dynamique d’ailleurs.

Haleth a écrit :

- la rédéfinition: La programmation objet permet à un objet de raffiner la mise en œuvre d'un message défini pour des objets d'un type parent, autrement dit de redéfinir la méthode associée au message : c'est le principe de redéfinition des messages (ou overriding en anglais). : chaque méthode d'un objet peut redéfini (on peut redéfinir une méthode d'un objet en java, sans créer une autre classe ?)

Tu as un petit exemple ?
Je ne suis pas sûr de savoir si tu parles d’overloading ou d’overriding (bien que l’article Wikipédia mentionne overriding).
Par définition, il me semble que l’overriding nécessite une sous-classe.
Par contre l’overloading se fait au sein de la même classe.

Haleth a écrit :

Ouais enfin le « tout en private, mais un couple getter/setter pour chaque attribut » c’est une pratique bien pourri au moins aussi courante en C++.
Et c'est tout aussi méprisable, je te rassure.

On est d’accord.
Je voulais juste signaler que ce fléau n’était pas propre à Java.
Même si, comme le signale bien Luc Hermitte, c’est plus courant en Java (rentré dans les mœurs de beaucoup de gens + des frameworks codé avec les pieds qui ont besoin de ça) qu’en C++ (car le dev’ C++ moyen est souvent plus « cultivé » que le dev’ Java moyen).

Haleth · Le 23/09/2013, à 15:46

Je vois 2 problèmes à Java :
1) c’est un langage assez facilement abordable, donc forcément il y a plus de mauvais développeurs (surtout si le développeur ne connaît que Java, et n’a aucune idée de comment fonctionne un ordinateur, l’allocation mémoire, …) et fatalement plus de logiciels mal pensé et codé avec les pieds (et donc un gouffre un ressources => Java c’est lent).
2) Java a été très vendu aux entreprises, et là pas mal y ont vu l’occasion de se faire des joyeuses en or (suffit de mater les SSII pour le cas français). Le truc est simple : il suffit de faire des trucs over-engineered, un bon gros framework tentaculaire et bloated qui se configure via trouzmille fichier XML et qui va générer une chiée d’objet à la moindre action. Le truc est tellement complexe pour rien que tu vas pouvoir louer tes consultants et autres experts à prix d’or. C’est un truc omniprésent en JEE, mais ça a aussi déteint sur le Java de base sad

http://ploum.net/ploum-en-j2ee/?lulz=conceal+LAX+Syria
Tout est dit

Qu’est ce que tu reproches aux interfaces et à l’héritage (si ce n’est que ce dernier est souvent utilisé à tort et à travers, violant souvent le principe de substitution de Liskov au passage) ?
Héritage que l’on retrouve aussi dans les langages dynamique d’ailleurs.

L'héritage c'est cool, parfois
Les interfaces, idem

Prenons un exemple.
J'ai une fonction qui prend un objet, et utilise la méthode rouler() de cet objet. Tu est obligé de faire une interface ou un héritage en java pour faire ceci (ou alors y'a une méthode inconnue ?).
L'héritage et les interfaces sont bien, mais quand tu en as besoin pour ton algorithme, et pas parcque le langage te l'impose.

Tu as un petit exemple ?
Je ne suis pas sûr de savoir si tu parles d’overloading ou d’overriding (bien que l’article Wikipédia mentionne overriding).
Par définition, il me semble que l’overriding nécessite une sous-classe.
Par contre l’overloading se fait au sein de la même classe.

Heum, je ne connais pas vraiment les termes, mais voici un exemple en Python:

#!/usr/bin/python

class carrosse:
        def rouler(self):
                print "Je roule !"


item = carrosse()
item.rouler()

def voler():
        print "Je vole !"

item.rouler = voler
item.rouler()

M'enfin, je suis globalement d'accord avec toi;

Tu as un truc bizarre dans ton URL : "?lulz=strike+conceal+Manhattan", je sais pas ce que ça fiche là oO

Un addon marrant pour montrer à tous que je suis un terroriste extremiste anti-américain: http://flagger.io/?lulz=China+chemical+MSP

Dernière modification par Haleth (Le 23/09/2013, à 15:48)

pires57 · Le 23/09/2013, à 20:04

moi je suis allergique a l'objet donc comme cela c'est réglé ^^
Ceci dit, a choisir entre les deux je prendrais c++.

grim7reaper · Le 23/09/2013, à 20:24

Haleth a écrit :

http://ploum.net/ploum-en-j2ee/?lulz=conceal+LAX+Syria
Tout est dit

Je connaissais déjà, et c’est génial oui ^^

Haleth a écrit :

Qu’est ce que tu reproches aux interfaces et à l’héritage (si ce n’est que ce dernier est souvent utilisé à tort et à travers, violant souvent le principe de substitution de Liskov au passage) ?
Héritage que l’on retrouve aussi dans les langages dynamique d’ailleurs.
L'héritage c'est cool, parfois
Les interfaces, idem
Prenons un exemple.
J'ai une fonction qui prend un objet, et utilise la méthode rouler() de cet objet. Tu est obligé de faire une interface ou un héritage en java pour faire ceci (ou alors y'a une méthode inconnue ?).
L'héritage et les interfaces sont bien, mais quand tu en as besoin pour ton algorithme, et pas parcque le langage te l'impose.

Non, il n’y a pas de méthode inconnue, et oui tu es obligé de passer par héritage ou interface (encore que là, interface me semble plus approprié).
Mais ça, ça vient du fait que Java est statiquement typé, donc il veut vérifier à la compilation si ce que tu lui demandes est possible.
C++ fera de même (d’où les épiques messages d’erreurs de GCC quand il ne trouve pas une fonction kivabien dans un template, bon ça c’est amélioré depuis grâce à la compétition avec clang).

Parce qu’en Python (par exemple), ok tu n’as pas besoin d’interface ou héritage pour faire ça (et ça ne servirait à rien, étant donné qu’il n’y a pas de vérification de faite avant l’exécution car typage dynamique).
Donc tu peux écrire :

#!/usr/bin/env python3

class A:
    def rouler(self):
       print('A roule')

class B:
    pass

def avancer(obj):
    obj.rouler()

if __name__ == '__main__':
    a = A()
    b = B()
    avancer(a)
    avancer(b)

Sauf qu’à l’exécution tu vas crasher (AttributeError).
Java te garanti que ce genre d’erreur n’arrivera pas, donc il besoin d’un moyen de vérifier et ça passe par héritage ou interface.

Au final, c’est l’éternel dilemme entre typage statique (on veut de la vérification à la compilation, si ça compile ça signifie que l’on a pas à soucier de toute une classe d’erreurs, mais en contrepartie on perd en souplesse (plus ou moins selon le langage)) et le typage dynamique (très souple, par contre garantie minime à l’exécution).
Après c’est un choix à faire selon tes préférences et/ou les contraintes de ton projet. Rien n’est parfait.

Haleth a écrit :

Tu as un petit exemple ?
Je ne suis pas sûr de savoir si tu parles d’overloading ou d’overriding (bien que l’article Wikipédia mentionne overriding).
Par définition, il me semble que l’overriding nécessite une sous-classe.
Par contre l’overloading se fait au sein de la même classe.
Heum, je ne connais pas vraiment les termes, mais voici un exemple en Python:
#!/usr/bin/python

class carrosse:
        def rouler(self):
                print "Je roule !"


item = carrosse()
item.rouler()

def voler():
        print "Je vole !"

item.rouler = voler
item.rouler()
M'enfin, je suis globalement d'accord avec toi;

Oui, ça ce n’est pas possible en Java.
En Python ça fonctionne car les fonctions sont des objets comme les autres.
En Java une fonction n’est pas un objet ou une variable donc ça ne passe pas (ce qui est assez dommage il est vrai, mais pour d’autres raisons).
Cela dit, ton exemple ce n’est pas vraiment de l’overloading ou de l’overriding, mais bon la comparaison devient vite difficile quand déjà le système de typage est totalement différent.

Haleth a écrit :

Tu as un truc bizarre dans ton URL : "?lulz=strike+conceal+Manhattan", je sais pas ce que ça fiche là oO
Un addon marrant pour montrer à tous que je suis un terroriste extremiste anti-américain: http://flagger.io/?lulz=China+chemical+MSP

Ok.

GangsterAutorisé · Le 02/03/2014, à 18:53

Ah je crois tenir une bonne raison pour l'info de gestion : hibernate.

C'est une bib en java d'accès aux bdd qui permet l'historisation de toutes les modifs, ainsi qu'une gestion objet des données (ce qui permet de modifier la structure des données sans être obligé de reprendre tout le code source, pour les grands programmes c'est confortable).
Y a-t-il un équivalent en c++ ? Ou une bib en projet ?

Haleth · Le 02/03/2014, à 20:04

Que veux-tu dire par "historisation des données" ? Tu veux dire "garder un historique" ? Genre les 10 dernières versions de l'enregistrement ?

Bon, je connais pas ce programme, mais a priori, c'est typiquement le genre de job pour lequel une base de donnée n'est pas conçu, concrérement à des trucs comme couchdb, mongodb etc

Histoire de troller un peu :

ainsi qu'une gestion objet des données (ce qui permet de modifier la structure des données sans être obligé de reprendre tout le code source, pour les grands programmes c'est confortable).

En fait, ce n'est confortable que pour les projets mal pensés;

Dernière modification par Haleth (Le 02/03/2014, à 20:04)

grim7reaper · Le 03/03/2014, à 02:36

Pour l’historisation des données je ne sais pas (je ne sais pas trop ce que tu veux dire par là d’ailleurs), mais ça :

GangsterAutorisé a écrit :

une gestion objet des données

C’est ce que l’on appelle un ORM et ça existe aussi en C++ (Cf. ici)

GangsterAutorisé · Le 09/03/2014, à 20:52

Alors je me base sur un article de linux magazine hors séries admin et dev de sept oct 2011.

C'est un hors série sur java. L'article qui m'intéresse a été écrir par Fabienne Sandoz sur le framework hibernate. Mais je pense avoir inventé une différence avec d'autres ORM.

Pour l'historisation des données, j'avais cru qu'hibernate pouvait reconstituer un contexte de données à un moment T, mais en fait je n'en suis plus si sûr.
Prenons un logiciel RH, où les carrières les salaires les règlementations évoluent. Et bien je me disais qu"en stockant toutes les modifs faites dans la bdd, une couche intermédiaire entre la bdd et le code, pourrait reconstituer la bdd telle qu'elle était à un moment T. C'est ce qui pour moi constituerait l'historisation des données.

Mais bon laissez tomber et encore merci pour vos explications.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 22/09/2013, à 12:30

Re : java vs c++

#27 Le 22/09/2013, à 13:53

Re : java vs c++

#28 Le 22/09/2013, à 14:28

Re : java vs c++

#29 Le 22/09/2013, à 15:39

Re : java vs c++

#30 Le 23/09/2013, à 12:53

Re : java vs c++

#31 Le 23/09/2013, à 13:30

Re : java vs c++

#32 Le 23/09/2013, à 14:41

Re : java vs c++

#33 Le 23/09/2013, à 15:46

Re : java vs c++

#34 Le 23/09/2013, à 20:04

Re : java vs c++

#35 Le 23/09/2013, à 20:24

Re : java vs c++

#36 Le 02/03/2014, à 18:53

Re : java vs c++

#37 Le 02/03/2014, à 20:04

Re : java vs c++

#38 Le 03/03/2014, à 02:36

Re : java vs c++

#39 Le 09/03/2014, à 20:52

Re : java vs c++

Pied de page des forums