Google n’utilisera plus les API Java d’Oracle pour le prochain Android

Raisons techniques ou juridiques, au choix

Publié dans

04/01/2016 5 minutes

Google n'utilisera plus les API Java d'Oracle pour le prochain Android

Google travaille actuellement sur un remplacement de ses API Java. Selon l’éditeur, la prochaine version majeure d’Android, simplement baptisée « N » pour l’instant, se baserait sur l’implémentation OpenJDK pour simplifier le travail des développeurs. Cependant, les retombées juridiques pourraient avoir été un puissant moteur de cette décision.

C’est par un « commit » dans le code d’Android que certains ont remarqué que 8 092 fichiers avaient été modifiés et faisaient clairement référence à OpenJDK, l’implémentation libre de Java proposée par Oracle. Rappelons que ce dernier a racheté Sun en janvier 2010, récupérant du même coup la technologie Java. Or, il y a deux implémentations : OpenJDK, qui constitue le socle open source, et Oracle JDK, son implémentation commerciale, considérée comme plus stable.

Interrogée par Venture Beat, Google a confirmé qu’une transition vers OpenJDK était bien en cours. Pour la société de Mountain View, les développeurs devraient voir leur travail simplifié, puisqu’il n’y aurait alors plus qu’une seule base de code pour l’ensemble des API. Par ailleurs, l’éditeur a affirmé que l’arrivée de la version commerciale Java 8 et de ses multiples améliorations était une grande motivation pour se tourner vers OpenJDK et s’y investir. En clair, le mouvement de Google serait fait pour le confort et le bonheur des développeurs.

Google, Oracle et un long procès autour de la propriété intellectuelle

Seulement voilà, ceux qui connaissent l’histoire de Java savent qu'elle a été marquée par une tension juridique intense entre Google et Oracle. Dès 2010, ce dernier avait déposé une plainte pour violation de copyright sur un lot de 37 API de Java, utilisées directement par Google pour concevoir sa machine virtuelle Dalvik, au cœur d'Android jusqu'à fin 2014. Le géant de la recherche avait nié dans un premier temps cette violation, avant de la reconnaître en partie. Mais un premier juge avait déclaré en 2012 que ces API ne pouvaient en effet pas être protégées par le copyright, car Google n'avait finalement que gardé les noms des méthodes, tout en changeant la quasi-totalité du reste.

Après coup, la course des évènements s’est cependant inversée pour Google. En 2014, une cour fédérale d’appel a déclaré en effet que les API de Java pouvaient être « copyrightées » et qu’Oracle était donc parfaitement en mesure de réclamer des royalties à Google pour les avoir utilisées. Depuis, et alors que la Cour Suprême a refusé de s'occuper de cette affaire, Google essaie de faire valoir que même si Dalvik utilise des technologies reconnues comme protégées, il s’agit d’un cas typique de « fair use ». Autrement dit, ces technologies sont si répandues qu’Oracle ne devrait pas en réclamer autre chose qu’une somme symbolique. Une décision qui pourrait faire jurisprudence sur l’utilisation des API en général.

Dalvik dans un premier temps, les API dans un second

La machine Dalvik avait été faite initialement pour permettre la création rapide d’applications via un langage de haut niveau. Parallèlement, Google l'avait proposée pour disposer d’une machine virtuelle Java qui serait orientée vers l’univers mobile et ses contraintes propres. Après tout, un smartphone n’a pas la puissance d’un PC ou d’un Mac, et les premiers terminaux mobiles sous Android n’avaient clairement pas les performances de ceux d’aujourd’hui.

Avec Android 5.0, Google s'est pourtant débarrassé de Dalvik, pour la remplacer par une nouvelle machine virtuelle, cette fois totalement réalisée en interne : Android Runtime, ou ART. Ce dernier apportait notamment plusieurs avantages techniques, en particulier la compilation ahead-of-time pour améliorer les performances, jugées précédemment médiocres. Elle avait également le mérite de ne plus pouvoir être attaquée sur le terrain de la propriété intellectuelle. Cela étant, ce changement ne réglait pas toute la question.

Le travail continue en attendant la présentation d'Android 7.0

Google travaille donc depuis plusieurs années au remplacement de tous les éléments « incriminés » de Java. Mais si cette bascule progressive pourrait soulager la pression juridique, cela ne résoudra pas tout le problème : seul Android 7.0 et les versions ultérieures bénéficieront de la nouvelle implémentation OpenJDK, laissant toutes les autres moutures avec les anciennes API. Le combat contre Oracle s’appliquerait donc toujours pleinement, surtout quand on connait la vitesse de mise à jour des smartphones Android vers une nouvelle version majeure du système.

Le travail va donc continuer sur les changements de code. Android 7.0 ne devrait de toute façon pas être présenté avant plusieurs mois, pour une arrivée de la version finale à l’automne, comme d’habitude. Il n’est pas dit non plus que les applications actuelles puissent fonctionner correctement sans le moindre changement, mais Google devrait communiquer sur ce point le cas échéant.

logiciel comme un algorithme mais pas sur le code lui même.  Le juge n'a pas statué sur les brevet mais reconnu que les API Java sont soumises au droit d'auteur comme n'importe quel code. Si Google a été condamné c'est qu'il a recopié du code de Java en s'en attribuant la paternité et sans respecter la licence GPL (libre mais qui exige que tous les travaux dérivés soient également sous GPL).

Il est probable qu'il faudra recoder une partie des anciennes applis écrites avec le JDK Oracle pour qu'elles tournent sur droid v7 ou pas ? On parle de quoi là ? De fonctions / classes différentes dans les API des deux JDK ? De traitement différent en interne des mêmes fonctions / classes en interne avec des appels similaires ?

Edit : OK, vu au dessus. Puisque l'OpenJDK est open justement, ce ne serait pas aberrant qu'Oracle en ait implémenté une bonne partie chez lui. Donc risque de pertes de fonctionnalités spécifiques à Oracle.. Ou même implémentation modifiées des méthodes venant d'OpenJDK... Bref à suivre, mais ca me semble chaud comme transition au 1er abord...

Une bonne partie des API de JavaSE est reprise totalement a l'identique dans le SDK Android, à par le nom du package.  Je pense que le nouveaux package seront juste un alias des anciens (ou inversement) ce qui fera que pour les anciennes applications pourraient théoriquement continuer à fonctionner de manière transparente. Après entre théorie et pratique quand on change de VM, il peut toujours y avoir des surprises.

En effet cet article fait une grosse confusion entre brevet et copyright. Mais des article sur le jugement, qui expliquent ça bien, il y en a des milliers. Premier résultat après une recherche sur mon moteur :http://arstechnica.com/tech-policy/2014/05/oracles-java-api-code-protected-by-co...  

 Pour une grande majorité des programmes dont ont besoin les entreprises, l'optimisation a tous les niveaux n'est pas nécessaire. Le plus souvent optimiser les accès à la base de donnée est amplement suffisant. Avoir rapidement quelque chose qui marche bien est bien plus important.   Après si tu code uniquement pour la beauté et la performance du code ok, mais je ne suis pas sur que tu trouve beaucoup de patrons qui acceptent de payer pour ça.  

 Donc tu préconise dans l'apprentissage des science physiques d'apprendre la relativité générale avant de pouvoir introduire la gravité dans la mécanique Newtonienne? Parce que la gravité ne s'explique correctement qu'avec la relativité générale. Mais tu retrouveras les 3/4 de tes étudiants pendus si tu commence par ça.

Pour info, je préconise un apprentissage du bas niveau sérieux pour tous les étudiants car c'est important. Mais il n'est pas nécessaire, de le faire en premier (bien que tout a fait possible).  Les notion d'algorithmes sont bien plus utiles pour apprendre l'assembleur que l'inverse.

Commentaires (97)

pyro-700

Le 04/01/2016 à 16h 57

super bientôt plus de java ni de flash.

Soltek

Le 04/01/2016 à 17h 01

Ça ne changera rien juridiquement puisque OpenJDK se base sur les API de Java 8 et Oracle fait un procès non pas parce que Google aurait copier du code de Java mais parce que Google utilise une de leur API comme tu le dis à la fin de ton premier inter-titre.

Sinon les 2 du dessus vous n’avez pas vraiment compris la news à priori.

nuandafr

Le 04/01/2016 à 17h 10

pyro-700 et maxscript : Déjà vous faites un amalgame entre le plugin JAVA (pour les applets, truc qui  effectivement est dépassé) et le langage JAVA lui même. Et comme dit par Soltek vous n’avez pas bien saisi le contenu du la news.

CryoGen

Le 04/01/2016 à 17h 12

De ce que je comprend de la source, Android ne va plus s’appuyer sur les API commerciales mais seulement celles proposées par openJDK. Google devrait aussi participer d’avantage à openJDK en laissant plus ou moins tomber sa propre implémentation complète.

Google fera sa propre implémentation en intégrant OpenJDK.

Pecky

Le 04/01/2016 à 17h 13

Bon, autant la faire courte : java ≠ javascript

Et Java est l’un des langages, avec le C (C++…), le plus utilisé au monde.

 Merci et au revoir 

EMegamanu Abonné

Le 04/01/2016 à 17h 15

Merci aux INpactiens de ne pas considérer Java uniquement pour les (dépréciés) applets.

Je pense que vous ne vous rendez pas compte de la qualité de matériels et services basés sur ce langage et ce runtime que vous utilisez (sites, téléphones, équipement multimédia…) et qui seraient impossibles ou autrement plus compliqués ou plus chers à mettre en oeuvre dans d’autres technologies.

Mimoza Abonné

Le 04/01/2016 à 17h 17

Me font toujours marré ceux qui veulent la mort de Java, ils ont souvent jamais touché une ligne de code de leur vie et ne savent finalement pas quoi ils revendiquent. " />

Le rachat de Sun par Oracle leur a permis une intégration verticale de leur solution (ils avaient le soft & ils ont acheter le hard). Sun était un «gentil» et pas trop regardant sur l’utilisation de leur technos logiciel, Oracle est tout le contraire." />

Vincent_H Abonné

Le 04/01/2016 à 17h 33

Le troll était évident, il ne fallait pas y répondre ;)

Uther Abonné

Le 04/01/2016 à 17h 47

Soltek a écrit :

Ça ne changera rien juridiquement puisque OpenJDK se base sur les API de Java 8 et Oracle fait un procès non pas parce que Google aurait copier du code de Java mais parce que Google utilise une de leur API comme tu le dis à la fin de ton premier inter-titre.

Sinon les 2 du dessus vous n’avez pas vraiment compris la news à priori.

Si dans le procès Oracle a porté plainte pour diverses choses y compris le plagiat. Même s’il n’ont trouvé qu’un minuscule portion commune de moins d’une dizaine de lignes. Il s’agissait d’un code très quelconque qu’un stagiaire aurait pu écrire en 5 minute.

Et le plus ridicule, c’est qu’après un premier procès ou le juge qui connaissait la programmation c’est bien rendu compte que le plagiat était insignifiant, le juge en appel qui n’y connaissait rien a reconnu que ce plagiat avait permis à Google de gagner énormément.

Et ça change quelque chose parce que Oracle est propriétaire de l’OpenJDK et le fournit sous GPL ce qui garantit une liberté d’usage du code.

 

Le 04/01/2016 à 17h 48

#10

Quand je vois comment çà dérape sur le sujet du viol présumé, et le swordage massif ici alors que juste le premier message était un troll mais le reste était censé…

Le 04/01/2016 à 17h 55

#11

Oui sauf que comme je le dis justement dans le commentaire que tu quote, le 2nd procès ne parle pas du code mais de l’API directement.

LostSoul Abonné

Le 04/01/2016 à 17h 59

#12

Ca saque ferme dans les comments ici " />

Le 04/01/2016 à 18h 03

#13

Comme expliqué mille fois, le commentaire supprimé entraine avec lui tous ceux qui le citent.

Zerdligham

Le 04/01/2016 à 18h 19

#14

Ah bon? Tu veux dire que le “Réponse à un commentaire supprimé” n’est pas une mauvaise excuse du censeur pour les massacres à la machette qu’il a la flemme de justifier? " />

CounterFragger

Le 04/01/2016 à 18h 47

#15

Du coup, je me demande vraiment comment on peut à la fois breveter des API et proposer un JDK open-source qui reprend exactement lesdites API.

Un tel paradoxe met bien en lumière l’aberration, voire la stupidité, de la brevetabilité des API…

Le 04/01/2016 à 18h 50

#16

Vincent_H a écrit :

Comme expliqué mille fois, le commentaire supprimé entraine avec lui tous ceux qui le citent.

Oui ça je le savais… mais je ne savais pas que çà incluait les réponses ou citations des commentaires suivants (donc qui ne répondent ou citent pas forcement au troll), c’est un peu raide " />

Commentaire_supprime

Le 04/01/2016 à 18h 51

#17

Pecky a écrit :

Bon, autant la faire courte : java ≠ javascript

Et Java est l’un des langages, avec le C (C++…), le plus utilisé au monde.

Merci et au revoir

Donc, si je veux apprendre la programmation moderne, je commence par le Java et, quand je suis au point, je passe au C (C++ pour Tux en ce qui me concerne) et je pourrais alors prétendre, modulo le niveau effectif de mes compétences au-delà du “hello world” de base, m’y connaître en programmation ?

Vincent_H a écrit :

Comme expliqué mille fois, le commentaire supprimé entraine avec lui tous ceux qui le citent.

J’y suis pour rien les gars, c’est pas moi qui ai codé la fonction “massacre à la tronçonneuse” des admins (en Java, C++ ou php, peu importe)

" />" />" />" />" />

Le 04/01/2016 à 18h 53

#18

CounterFragger a écrit :

Du coup, je me demande vraiment comment on peut à la fois breveter des API et proposer un JDK open-source qui reprend exactement lesdites API.

Un tel paradoxe met bien en lumière l’aberration, voire la stupidité, de la brevetabilité des API…

Toutes les API de OpenJDK sont dans Java 8, mais l’inverse n’est pas vrai. Si j’ai bien pigé, Android utilise/implémente des API qui ne sont normalement disponible que dans Java commercial.

Anonyme_f7d8f7f164fgnbw67p

Le 04/01/2016 à 19h 00

#19

Si il y a un dev qui passe par là, concrètement les API changent beaucoup entre celles d’Oracle et celles d’OpenJDK ? Je suis pas dev mais je vois comment ca marche dans d’autres langages, mais le java je n’ai jamais touché…. (seulement .Net - oui je sais c’est mal - et C++ en dilettante sur du Qt, ou les vieilles saletés qu’on apprend à l’école, Delphi Windev TPascal et compagnie)…

Il est probable qu’il faudra recoder une partie des anciennes applis écrites avec le JDK Oracle pour qu’elles tournent sur droid v7 ou pas ? On parle de quoi là ? De fonctions / classes différentes dans les API des deux JDK ? De traitement différent en interne des mêmes fonctions / classes en interne avec des appels similaires ?

Edit : OK, vu au dessus. Puisque l’OpenJDK est open justement, ce ne serait pas aberrant qu’Oracle en ait implémenté une bonne partie chez lui.

Donc risque de pertes de fonctionnalités spécifiques à Oracle.. Ou même implémentation modifiées des méthodes venant d’OpenJDK…

Bref à suivre, mais ca me semble chaud comme transition au 1er abord…

Le 04/01/2016 à 19h 50

#20

CounterFragger a écrit :

Du coup, je me demande vraiment comment on peut à la fois breveter des API et proposer un JDK open-source qui reprend exactement lesdites API.
 Un tel paradoxe met bien en lumière l'aberration, voire la stupidité, de la brevetabilité des API...
 Un brevet logiciel porte sur un processus technique mis en œuvre par un
 logiciel comme un algorithme mais pas sur le code lui même.      


&nbsp;Le juge n'a pas statué sur les brevet mais reconnu que les API Java sont soumises au droit d'auteur comme n'importe quel code. Si Google a été condamné c'est qu'il a recopié du code de Java en s'en attribuant la paternité et sans respecter la licence GPL (libre mais qui exige que tous les travaux dérivés soient également sous GPL).      
CryoGen a écrit :

Toutes les API de OpenJDK sont dans Java 8, mais l’inverse n’est pas vrai. Si j’ai bien pigé, Android utilise/implémente des API qui ne sont normalement disponible que dans Java commercial.

Non les API publiques sont les mêmes, si le juge a considéré que Google enfreignait les droits d’auteur c’est parce qu’il enfreignait la GPL (et peut être même aussi la licence précédente car il me semble que Android est sortit avant la mise de Java sous GPL)

 

Drepanocytose a écrit :

Si il y a un dev qui passe par là, concrètement les API changent beaucoup entre celles d’Oracle et celles d’OpenJDK ? Je suis pas dev mais je vois comment ca marche dans d’autres langages, mais le java je n’ai jamais touché…. (seulement .Net - oui je sais c’est mal - et C++ en dilettante sur du Qt, ou les vieilles saletés qu’on apprend à l’école, Delphi Windev TPascal et compagnie)…
 Il est probable qu'il faudra recoder une partie des anciennes applis écrites avec le JDK Oracle pour qu'elles tournent sur droid v7 ou pas ? On parle de quoi là ? De fonctions / classes différentes dans les API des deux JDK ? De traitement différent en interne des mêmes fonctions / classes en interne  avec des appels similaires ?       
 Edit : OK, vu au dessus. Puisque l'OpenJDK est open justement, ce ne serait pas aberrant qu'Oracle en ait implémenté une bonne partie chez lui.       


 Donc risque de pertes de fonctionnalités spécifiques à Oracle.. Ou même implémentation modifiées des méthodes venant d'OpenJDK...       


 Bref à suivre, mais ca me semble chaud comme transition au 1er abord...
 Une bonne partie des API de JavaSE est reprise totalement a l'identique dans le SDK Android, à par le nom du package.       


&nbsp;Je pense que le nouveaux package seront juste un alias des anciens (ou inversement) ce qui fera que pour les anciennes applications pourraient théoriquement continuer à fonctionner de manière transparente. Après entre théorie et pratique quand on change de VM, il peut toujours y avoir des surprises.     
L’Open JDK est un Java complet et certifié conforme. Donc il ne devrait théoriquement rien manquer. Les différence entre le JDK Oracle et OpenJDK, sont sur certains points techniques en interne mais ils ont la même API.

kgersen

Le 04/01/2016 à 19h 58

#21

est-ce un signe que Google va bientôt reléguer Java au second plan pour Android ?

En //, leur projet Flutter (voir flutter.io) avance vite. On se demande ce qui se prépare la.

lossendae

Le 04/01/2016 à 20h 18

#22

Java par Jetbrains, c’est au top !

usky

Le 04/01/2016 à 20h 29

#23

“surtout quand on connait la vitesse de mise à jour des smartphones Android vers une nouvelle version majeure du système”

 mdr

sirius35

Le 04/01/2016 à 20h 34

#24

Android 7… alors qu’une majorité de terminaux seront encore à la version 4….

Lorsque le montre la version 6 de mon Nexus6 Moto les gens écarquillent les yeux comme face au Saint-Graal " />

Funigtor Abonné

Le 04/01/2016 à 21h 07

#25

Moi y a plein de gens qui ne sont même pas au courant qu’elle existe. " />

XMalek

Le 04/01/2016 à 22h 37

#26

Bon j’ai failli poster mais après j’ai lu la source :p

A voir ce que donne réellment openjdk en terme de performance et de stabilité sur android, les retours ont quand même pas l’air top…

Ewil

Le 04/01/2016 à 22h 46

#27

XMalek a écrit :

Bon j’ai failli poster mais après j’ai lu la source :p

A voir ce que donne réellment openjdk en terme de performance et de stabilité sur android, les retours ont quand même pas l’air top…

Sur ordi, openJDK a fait un sacré bon en avant ces 3-4 dernières années, espérons la même chose sur android :)

sr17

Le 04/01/2016 à 22h 47

#28

EMegamanu a écrit :

Merci aux INpactiens de ne pas considérer Java uniquement pour les (dépréciés) applets.

Je pense que vous ne vous rendez pas compte de la qualité de matériels et services basés sur ce langage et ce runtime que vous utilisez (sites, téléphones, équipement multimédia…) et qui seraient impossibles ou autrement plus compliqués ou plus chers à mettre en oeuvre dans d’autres technologies.

Traduction : Si on avait fait coder ça en C, ça aurait été plus rapide et mieux optimisé, mais ça aurait coûté un peu plus cher…

Commentaire_supprime a écrit :

Donc, si je veux apprendre la programmation moderne, je commence par le Java et, quand je suis au point, je passe au C (C++ pour Tux en ce qui me concerne) et je pourrais alors prétendre, modulo le niveau effectif de mes compétences au-delà du “hello world” de base, m’y connaître en programmation ?

Non, si tu veux VRAIMENT apprendre à programmer correctement, tu fait d’abord de l’assembleur, ensuite du C/C++, éventuellement un peu de langage fonctionnel. Et le tout en étudiant les effets à bas niveau de ce que tu écrit.

Et ensuite tu pourra éventuellement pisser du code dans n’importe quel langage sans écrire n’importe quoi…

Le 04/01/2016 à 22h 53

#29

" /> C’est quoi l’intérêt de commencer par l’assembleur??

Je veux dire à part frimer devant les filles en leur racontant comment on est un vrai, un dur.

Obidoub

Le 04/01/2016 à 22h 55

#30

Mouais enfin bon…. avec les brevets logiciels Oracle a moyen d’attaquer à nouveau Google parce qu’il utilise OpenJDK qui utilise des trucs Oracle. Ce serait pas mieux de juste utiliser autre chose ?

Je me retiens fortement de troller sur Java mais c’est un truc loin d’être indispensable un, la preuve y’en a pas sur les Windows Phone.

Le 04/01/2016 à 23h 12

#31

Zerdligham a écrit :

" /> C’est quoi l’intérêt de commencer par l’assembleur??

Je veux dire à part frimer devant les filles en leur racontant comment on est un vrai, un dur.

En apprenant le langage machine, tu acquiers la compréhension de la façon dont fonctionne réellement un ordinateur. Sans cela, de nombreuses notions resteront incomprises.

Ensuite, ça permet de comprendre comment un langage de haut niveau est traduit en langage machine et comment fonctionnent les mécanismes des langages de programmation. Ici aussi, cela permet de comprendre beaucoup de choses, d’appréhender beaucoup de phénomènes et surtout au final, d’améliorer radicalement sa qualité de code.

Un programmeur qui ne maîtrise pas le fonctionnement d’une machine à bas niveau écrit souvent n’importe quoi sans s’en rendre compte car il ignore ce que le compilateur génère en fonction de ce qu’il écrit.

Le langage machine peut nous sembler inutile car nous ne le voyons pas souvent. Sauf que le microprocesseur ne sait exécuter que cela. Et tout ce que nous écrivons doit être traduit d’une façon ou d’une autre dans ce langage…

hurd Abonné

Le 04/01/2016 à 23h 24

#32

Zerdligham a écrit :

" /> C’est quoi l’intérêt de commencer par l’assembleur??

Je veux dire à part frimer devant les filles en leur racontant comment on est un vrai, un dur.

C’est vrai que c’est curieux, perso, j’ai fait plus ou moins le chemin inverse : Java -> C -> Assembleur.

Et si l’assembleur et surtout toute la connaissance des processeur qui va avec est quelque-chose de super intéressant qui peut devenir utile pour tout programmeurs, j’ai un peu peur que de commencer par cela soit

d’une part très décourageant pour la personne et d’autres part susceptible d’amener des mauvaises pratiques.

Ça me paraît plus simple de faire comprendre à quelqu’un qu’il doit penser à quelque-chose de plus dans un nouveau langage, que l’inverse.

De plus, l’assembleur est vraiment un langage à part. C’est un langage qui t’apprend à peut près tout ce que tu ne dois pas faire dans les autres, mais ici c’est autoriser.

Le 04/01/2016 à 23h 40

#33

Uther a écrit :

 Un brevet logiciel porte sur un processus technique mis en œuvre par un
  logiciel comme un algorithme mais pas sur le code lui même.       
 &nbsp;Le juge n'a pas statué sur les brevet mais reconnu que les API Java   
sont soumises au droit d’auteur comme n’importe quel code. Si Google a

été condamné c’est qu’il a recopié du code de Java en s’en attribuant la

paternité et sans respecter la licence GPL (libre mais qui exige que

tous les travaux dérivés soient également sous GPL).

Ce n’est pas du tout ce que dit l’article, donc… source ?

#34

hurd a écrit :

C’est vrai que c’est curieux, perso, j’ai fait plus ou moins le chemin inverse : Java -> C -> Assembleur.

Et si l’assembleur et surtout toute la connaissance des processeur qui va avec est quelque-chose de super intéressant qui peut devenir utile pour tout programmeurs, j’ai un peu peur que de commencer par cela soit

d’une part très décourageant

Pas si on commence avec un truc qui permet de faire facilement des trucs très vraiment sympa et concrets en assembleur…

C’est sûr que si tu demande à un débutant d’écrire un programme courant en assembleur x86, faut pas oublier de lui donner une corde avec…

pour la personne et d’autres part susceptible d’amener des mauvaises pratiques.

Oui, si l’on se contentait de n’apprendre que cela, mais ce n’est bien sûr pas le but.

En réalité, ce qui amène à de mauvaises pratique, c’est une connaissance incomplète.

Ça me paraît plus simple de faire comprendre à quelqu’un qu’il doit penser à quelque-chose de plus dans un nouveau langage, que l’inverse.

Sauf que dans un langage évolué, il y a mine de rien beaucoup de choses qu’un débutant ne comprends pas.

Cela dit, je ne voulais pas dire que commencer absolument par l’assembleur serait primordial. Mais dans l’idéal, ce langage ne doit pas être non plus abordé trop tard.

En pratique, un bon enseignement ça ne sera pas de passer beaucoup de temps sur un langage avant de passer à un autre, mais plutôt des aller-retour entre différents langages et paradigmes.

De plus, l’assembleur est vraiment un langage à part. C’est un langage qui t’apprend à peut près tout ce que tu ne dois pas faire dans les autres, mais ici c’est autoriser.

Oui, c’est amusant de réaliser en quoi est traduit tout le beau code structuré qu’on écrit " />

Faut pas utiliser de Goto qu’ils disaient " />

Le 04/01/2016 à 23h 49

#35

Personnellement, j’ai réellement commencé la programmation avec le C (avec un peu de Pascal quelques années auparavant). C’est parfait pour apprendre la gestion de la mémoire et largement assez bas niveau pour débuter. Plonger les mains directement dans de l’assembleur n’aura pour seul résultat que d’embrouiller un débutant.

Le 05/01/2016 à 00h 00

#36

hurd a écrit :

C’est vrai que c’est curieux, perso, j’ai fait plus ou moins le chemin inverse : Java -> C -> Assembleur.

Tu notera qu’a l’école, on t’apprends d’abord à compter et à faire les opérations manuellement avant de te laisser te servir d’une calculatrice. Et ce n’est pas un hasard…

Programmer en Java sans comprendre ce qu’est une référence ou un objet, c’est apprendre tel quel des façons de procéder sans rien comprendre à ce qui se passe ni a leur raison d’être. Et pour beaucoup, c’est une difficulté plus qu’autre chose.

Mais bon, je ne prétends pas qu’on doive absolument éviter tout langage évolué et commencer absolument par de l’assembleur. Je pense qu’il faut plutôt procéder à des aller retour entre les langages.

Isshun

Le 05/01/2016 à 00h 04

#37

Sur Windows Phone il y à l’environnement .NET qui est soumis au même contraintes que Java, je ne vois pas pourquoi Google souhaiterait cesser les hostilités avec Oracle pour les recommencer avec Microsoft.

Le problème ici n’est pas avec Java SE ni avec .NET, le problème ce sont les brevets logiciels.

En développement il n’existe pas forcement 36 implémentations différentes de la même chose, surtout lorsque l’on doit respecter des spécifications bien précises.

Google à fait dans Dalvik ce que Sun avait fait dans HotSpot parce qu’il n’existe pas d’autres moyens efficaces de le faire, leur demander de faire autrement aurait été aussi con que de leur demander de trouver une nouvelle implémentation au quicksort. Sauf que dans le cas du quicksort un algo n’est pas brevetable, alors que dans le cas du code “ça dépend”, cette situation n’est pas tenable et tant mieux si le procès Google/Oracle peut faire jurisprudence une bonne fois pour toute car l’exception Américaine sur la légalité des brevets logiciels est étouffante pour tout le secteur.

Le 05/01/2016 à 00h 05

#38

CounterFragger a écrit :

Personnellement, j’ai réellement commencé la programmation avec le C (avec un peu de Pascal quelques années auparavant). C’est parfait pour apprendre la gestion de la mémoire et largement assez bas niveau pour débuter. Plonger les mains directement dans de l’assembleur n’aura pour seul résultat que d’embrouiller un débutant.

Embrouiller ?

Un petit microprocesseur, c’est quand même autrement plus simple qu’un compilateur C/C++…

Et la notion de pointeur qui pose tant de difficultés aux débutants en C/C++ est tellement plus simple et évidente à comprendre dans le cadre de l’assembleur…

127.0.0.1

Le 05/01/2016 à 00h 15

#39

CounterFragger a écrit :

Ce n’est pas du tout ce que dit l’article, donc… source ?

wikipediaqui lui même cite les décisions de justice.

Pour faire simple:

les SSO (Structure, sequence and organization) sont soumises au droit d’auteur mais ne sont pas brevetables. C’est l’équivalent d’un texte (discours, poème,… ).

les algorithmes sont brevetables mais pas soumis au droit d’auteur. C’est l’équivalent d’un procédé (recette de cuisine, formule chimique, calculs mathématiques, …)

Exception

Le 05/01/2016 à 00h 22

#40

Java c’est le diable.

Vivement sa disparition.

Dommage qu’Android se soit basé dessus, ses performances seraient 2x meilleures en C++ plutôt que cette ignominie de Java qui disparaîtra bientôt aux fonds des chiottes de l’histoire informatique.

the_frogkiller Abonné

Le 05/01/2016 à 00h 33

#41

try {

Exception a écrit :

Java c’est le diable.

Vivement sa disparition.

Dommage qu’Android se soit basé dessus, ses performances seraient 2x meilleures en C++ plutôt que cette ignominie de Java qui disparaîtra bientôt aux fonds des chiottes de l’histoire informatique.

} catch (StupidErrorException se) {

     flushMemory();

     stopBrainProcess();

     System.exit(1);

}

Olbatar

Le 05/01/2016 à 02h 07

#42

Hahahahaha!!! Les gens trollent vraiment sur n’importe quoi! Si au moins il le faisait avec subtilité…même pas!

collinm

Le 05/01/2016 à 02h 21

#43

sr17 a écrit :

Traduction : Si on avait fait coder ça en C, ça aurait été plus rapide et mieux optimisé, mais ça aurait coûté un peu plus cher…

Non, si tu veux VRAIMENT apprendre à programmer correctement, tu fait d’abord de l’assembleur, ensuite du C/C++, éventuellement un peu de langage fonctionnel. Et le tout en étudiant les effets à bas niveau de ce que tu écrit.

Et ensuite tu pourra éventuellement pisser du code dans n’importe quel langage sans écrire n’importe quoi…

lol la bonne vieille mentalité des années 90… vaudrait sortir de ta grotte, réinventer la roue, ne sert pu à grand chose…

Le 05/01/2016 à 02h 22

#44

sr17 a écrit :

Traduction : Si on avait fait coder ça en C, ça aurait été plus rapide et mieux optimisé, mais ça aurait coûté un peu plus cher…

Non, si tu veux VRAIMENT apprendre à programmer correctement, tu fait d’abord de l’assembleur, ensuite du C/C++, éventuellement un peu de langage fonctionnel. Et le tout en étudiant les effets à bas niveau de ce que tu écrit.

Et ensuite tu pourra éventuellement pisser du code dans n’importe quel langage sans écrire n’importe quoi…

Obidoub a écrit :

Mouais enfin bon…. avec les brevets logiciels Oracle a moyen d’attaquer à nouveau Google parce qu’il utilise OpenJDK qui utilise des trucs Oracle. Ce serait pas mieux de juste utiliser autre chose ?

Je me retiens fortement de troller sur Java mais c’est un truc loin d’être indispensable un, la preuve y’en a pas sur les Windows Phone.

en même temps, windows phone c’est des miettes de pain en part de marché et elle diminue..

Meewan Abonné

Le 05/01/2016 à 02h 40

#45

Toi tu n’as jamais travaillé avec des débutants en informatique.

Quand un développeur fait une erreur car il ne comprend pas ce qu’est une reference a cause d’une école qui n’enseigne que JAVA (et en aucun cas le fonctionnement de la machine en dessous) tu comprend que la vision des années 1990 était la bonne.

J’ai appris java mais ensuite (enfin en même temps) j’ai appris le et et l’assembleur pour comprendre ce qu’il se passe. Je serais incapable de coder dans ces langages mais les notions que j’ai me permettent de pas faire trop de conneries avec les langages de haut niveau (et ça permet des optimisation plutôt sympa que tu ne peux pas faire sans comprendre comment ça marche)

Le 05/01/2016 à 02h 45

#46

Olbatar a écrit :

Hahahahaha!!! Les gens trollent vraiment sur n’importe quoi! Si au moins il le faisait avec subtilité…même pas!

Et si les adorateurs de Java (qui ne sont autres que des développeurs pour qui les langages comme C++, qui nécessitent par exemple de libérer des pointeurs, sont trop compliqués pour eux) avaient le moindre argument pour répondre autre que “trooool”…

maxscript

Le 05/01/2016 à 07h 10

#47

  désolé pour mes camarades… je ne souhaitais pas troller et emporter une cordée de comm avec moi ;)

java c’est bien java c’est bien java c’est bien.. (bon ok même comme ça, ça passe pas), mais chacun ses outils de prédilection on va dire….

Sajicen Abonné

Le 05/01/2016 à 07h 36

#48

Exception a écrit :

Et si les adorateurs de Java (qui ne sont autres que des développeurs pour qui les langages comme C++, qui nécessitent par exemple de libérer des pointeurs, sont trop compliqués pour eux) avaient le moindre argument pour répondre autre que “trooool”…

maxscript a écrit :

  désolé pour mes camarades… je ne souhaitais pas troller et emporter une cordée de comm avec moi ;)

java c’est bien java c’est bien java c’est bien.. (bon ok même comme ça, ça passe pas), mais chacun ses outils de prédilection on va dire….

Faudrait songer à faire preuve d’ouverture d’esprit les gens hein… On croirait entendre des enfants pensant que parcequ’ils n’aiment pas une chose tout le monde devrait la détester. Je ne pense pas que vous ayez conscience du nombre de périphériques qui tourne en Java et qu’on se sert quotidiennement. Je ne dis pas que ce langage est le meilleur ou le plus beau ou je ne sais quoi d’autre. Juste qu’il faut lui reconnaître des qualités comme des défauts et se rappeler que si Google a choisi la technologie Java pour son OS ce n’est pas pour rien.

Le 05/01/2016 à 07h 39

#49

Exception a écrit :

Et si les adorateurs de Java (qui ne sont autres que des développeurs pour qui les langages comme C++, qui nécessitent par exemple de libérer des pointeurs, sont trop compliqués pour eux) avaient le moindre argument pour répondre autre que “trooool”…

pourquoi argumenter avec des trolls? c’est comme vouloir expliquer la génétique des population a un raciste. c’est une perte de temps vu qu’il ne cherche même pas à comprendre quoi que se soit. ils me font rire les personnes qui sont vent debout un langage et qui se disent des cadors du développement.  le bon développeur est celui qui prend en compte les avantage et inconvénients de chaque langage et de chaque contexte pour le projet considéré. pas besoin d’être capable de fabriquer son propre proc ou de faire du langage machine les doigts dans le nez.

Le 05/01/2016 à 07h 52

#50

Isshun a écrit :

Sur Windows Phone il y à l’environnement .NET qui est soumis au même contraintes que Java, je ne vois pas pourquoi Google souhaiterait cesser les hostilités avec Oracle pour les recommencer avec Microsoft.  

 Non mais Windows Phone c’etait un exemple, y’a des tas d’autres langages …

Le 05/01/2016 à 07h 54

#51

collinm a écrit :

en même temps, windows phone c’est des miettes de pain en part de marché et elle diminue..

Nan mais Windows Phone c’etait l’exemple qui montre qu’on peut utiliser autre chose que Java…

Google pourrait s’orienter vers un autre truc, y’a du choix.

Tiens et l’iPhone je suis moins familier avec mais il me semble qu’ils n’utilisent pas Java non plus ?

Je réafirme donc que c’est pas obligatoire d’utiliser java quand on fait de l’embarqué.

anonyme_95bde7ad91b4483068f10094cf1c28ca

Le 05/01/2016 à 08h 16

#52

sr17 a écrit :

Traduction : Si on avait fait coder ça en C, ça aurait été plus rapide et mieux optimisé, mais ça aurait coûté un peu plus cher…

Non, si tu veux VRAIMENT apprendre à programmer correctement, tu fait d’abord de l’assembleur, ensuite du C/C++, éventuellement un peu de langage fonctionnel. Et le tout en étudiant les effets à bas niveau de ce que tu écrit.

Et ensuite tu pourra éventuellement pisser du code dans n’importe quel langage sans écrire n’importe quoi…

jamais lu autant de bêtises en si peu de mots.

MuadJC

Le 05/01/2016 à 08h 19

#53

Ah, Android va migrer vers Bada! (oui, " /> honteux, mais j’assume avoir apprécié l’utilisation de cet OS)

Le 05/01/2016 à 08h 22

#54

CounterFragger a écrit :

Ce n’est pas du tout ce que dit l’article, donc… source ?

En effet cet article fait une grosse confusion entre brevet et copyright. Mais des article sur le jugement, qui expliquent ça bien, il y en a des milliers.      


Premier résultat après une recherche sur mon moteur :http://arstechnica.com/tech-policy/2014/05/oracles-java-api-code-protected-by-co...  


 &nbsp;

sr17 a écrit :

Traduction : Si on avait fait coder ça en C, ça aurait été plus rapide et mieux optimisé, mais ça aurait coûté un peu plus cher…

&nbsp;Bien évidement! L'optimisation inutile et le débogage évitable, ça coûte cher.

 &nbsp;Pour une grande majorité des programmes dont ont besoin les entreprises, l'optimisation a tous les niveaux n'est pas nécessaire. Le plus souvent optimiser les accès à la base de donnée est amplement suffisant. Avoir rapidement quelque chose qui marche bien est bien plus important.        


 &nbsp;       


 Après si tu code uniquement pour la beauté et la performance du code ok, mais je ne suis pas sur que tu trouve beaucoup de patrons qui acceptent de payer pour ça.       


 &nbsp;

sr17 a écrit :

Non, si tu veux VRAIMENT apprendre à programmer correctement, tu fait d’abord de l’assembleur, ensuite du C/C++, éventuellement un peu de langage fonctionnel. Et le tout en étudiant les effets à bas niveau de ce que tu écrit.

  Et ensuite tu pourra éventuellement pisser du code dans n'importe quel langage sans écrire n'importe quoi...

&nbsp;Donc tu préconise dans l'apprentissage des science physiques d'apprendre la relativité générale avant de pouvoir introduire la gravité dans la mécanique Newtonienne? Parce que la gravité ne s'explique correctement qu'avec la relativité générale. Mais tu retrouveras les 3/4 de tes étudiants pendus si tu commence par ça.

  Pour info, je préconise un apprentissage du bas niveau sérieux pour tous les étudiants car c'est important. Mais il n'est pas nécessaire, de le faire en premier (bien que tout a fait possible).&nbsp; Les notion d'algorithmes sont bien plus utiles pour apprendre l'assembleur que l'inverse.

SrBelial

Le 05/01/2016 à 08h 24

#55

Zerdligham a écrit :

" /> C’est quoi l’intérêt de commencer par l’assembleur??

Je veux dire à part frimer devant les filles en leur racontant comment on est un vrai, un dur.

sr17 a écrit :

En apprenant le langage machine, tu acquiers la compréhension de la façon dont fonctionne réellement un ordinateur. Sans cela, de nombreuses notions resteront incomprises.

Ensuite, ça permet de comprendre comment un langage de haut niveau est traduit en langage machine et comment fonctionnent les mécanismes des langages de programmation. Ici aussi, cela permet de comprendre beaucoup de choses, d’appréhender beaucoup de phénomènes et surtout au final, d’améliorer radicalement sa qualité de code.

Un programmeur qui ne maîtrise pas le fonctionnement d’une machine à bas niveau écrit souvent n’importe quoi sans s’en rendre compte car il ignore ce que le compilateur génère en fonction de ce qu’il écrit.

Le langage machine peut nous sembler inutile car nous ne le voyons pas souvent. Sauf que le microprocesseur ne sait exécuter que cela. Et tout ce que nous écrivons doit être traduit d’une façon ou d’une autre dans ce langage…

hurd a écrit :

C’est vrai que c’est curieux, perso, j’ai fait plus ou moins le chemin inverse : Java -> C -> Assembleur.

Et si l’assembleur et surtout toute la connaissance des processeur qui va avec est quelque-chose de super intéressant qui peut devenir utile pour tout programmeurs, j’ai un peu peur que de commencer par cela soit

d’une part très décourageant pour la personne et d’autres part susceptible d’amener des mauvaises pratiques.

Ça me paraît plus simple de faire comprendre à quelqu’un qu’il doit penser à quelque-chose de plus dans un nouveau langage, que l’inverse.

De plus, l’assembleur est vraiment un langage à part. C’est un langage qui t’apprend à peut près tout ce que tu ne dois pas faire dans les autres, mais ici c’est autoriser.

Assembleur > C > langages plus haut niveau c’est bien dans certains cas seulement, et à condition d’avoir des années et des années devant soi … si tu veux vraiment apprendre à programmer tu commence par le langage le plus adapté en fonction de tes contraintes.

Un développeur frontend par exemple se moquera bien de savoir comment le code machine fonctionne, de même qu’un développeur .Net ou Java, dont le code sera exécuté par la machine virtuelle .Net ou par la JVM … 

la hiérarchie “code écrit -> ASM -> proc” devient dans certains cas bien trop simple pour être vraie.

Le 05/01/2016 à 08h 46

#56

Pecky a écrit :

Reste que le C, même si déjà ancien, ne risque pas d’être remis en cause rapidement et un développeur finissant ses études maintenant pourra l’utiliser toute sa carrière sur du développement (logiciel de base surtout, ou il reste incontournable: démarrage/noyau/modules noyau). Java et toutes ces VM à bytecode, j’en suis moins sûr!

Ce qui est ahurissant, c’est de voir Java aussi utilisé dans certains domaines comme la SSI… Pas étonnant que cela soit un tel échec si ceux qui y travaillent ne savent pas descendre plus bas.

Le 05/01/2016 à 08h 57

#57

SrBelial a écrit :

Un développeur frontend par exemple se moquera bien de savoir comment le code machine fonctionne

Penser cela est la source de bien des problèmes! Etudiant, c’est simple, on commençait par assembler ses opcodes à la main avant d’avoir le droit d’utiliser un assembleur. Au moins cela fixait les idées et derrière, pour programmer proprement au quotidien, donc avec la conscience des limites du matos… ou parfois trouver les bugs du compilo voire du processeur… disons que ces réflexes alors acquis d’aller au plus bas m’ont souvent évité de perdre des jours voir semaines.

Le 05/01/2016 à 09h 01

#58

sr17 a écrit :

Tu notera qu’a l’école, on t’apprends d’abord à compter et à faire les opérations manuellement avant de te laisser te servir d’une calculatrice. Et ce n’est pas un hasard…

Tu noteras qu’on apprend à compter en maternelle et à faire les opérations arithmétiques simples au primaire. Par contre qui ici est sait précisément et rigoureusement qu’est-ce que l’ensemble des nombres entiers ? la définition de l’addition ? Probablement pas grand monde, puisque ça s’apprend seulement dans les filières post-bac un peu matheuses. Et que comme c’est pas un truc qu’on utilise tous les jours, même ceux qui l’ont appris l’ont probablement assez vite oublié.

sr17 a écrit :

Programmer en Java sans comprendre ce qu’est une référence ou un objet, c’est apprendre tel quel des façons de procéder sans rien comprendre à ce qui se passe ni a leur raison d’être. Et pour beaucoup, c’est une difficulté plus qu’autre chose.

Pour une utilisation basique, je ne suis pas certain que ce soit nécessaire. On peut bricoler pas mal de chose avec des connaissances approximatives. Pour une utilisation plus avancée (par exemple si on prétend en faire son métier), il faut effectivement plus rentrer dans les détails.

De la même façon, un boulanger n’a pas besoin de connaitre en détail les fondements des maths pour calculer combien coûtent 12 petits pains, mais quelqu’un qui prétend faire des maths professionnellement devra se pencher un peu plus sur le sujet.

Dans le cadre d’un apprentissage approfondit, je suis assez d’accord avec toi quand tu dis qu’il faut pas commencer très haut niveau. Personnellement, je pense qu’avoir une bonne compréhension du C est une bonne base pour passer aux langages de plus haut niveau.

Ça me semble aussi utile que lors de cet apprentissage du C, on parle un peu de comment marche l’ordinateur à bas niveau (c’est quoi le multi-threading, comment ça marche, comment on alloue de la mémoire…), donc forcement qu’on parle de l’assembleur et qu’on illustre comment sont traduits en assembleur certains concepts (pointeurs, fonctions…).

Mais apprendre l’assembleur dans le sens savoir programmer des choses en assembleur, ça me semble complètement inutile pour l’écrasante majorité des développeurs.

sr17 a écrit :

Je pense qu’il faut plutôt procéder à des aller retour entre les langages.

La par contre je pense que tout le monde sera d’accord. Plus on connait de langages, a fortiori s’ils ont des paradigmes très différents, plus on a de chances de réfléchir utiliser chacun d’entre eux.

flagos_

Le 05/01/2016 à 09h 11

#59

Obidoub a écrit :

Nan mais Windows Phone c’etait l’exemple qui montre qu’on peut utiliser autre chose que Java…

Google pourrait s’orienter vers un autre truc, y’a du choix.

Tiens et l’iPhone je suis moins familier avec mais il me semble qu’ils n’utilisent pas Java non plus ?

Je réafirme donc que c’est pas obligatoire d’utiliser java quand on fait de l’embarqué.

Oui tu pourrais utiliser autre chose. Le souci, c’est de faire du code multiplateforme est vraiment pénible en C/C++ tandis qu’en java ca se fait plutot bien.

 De toute manière, ca ne change rien au problème initial: il faut se debarasser d’Oracle et demander à tous les devs de recoder leurs applis pour Android N n’est pas une solution réaliste. De plus, autant les performances sur Android étaient un problème avant Dalvik (7 ans déjà !), autant aujourd’hui le système tourne très bien et avec ART, Google dispose déjà de la solution ultime.

Et a vrai dire, si Google doit migrer vers autre chose, ce sera plutot vers du HTML5+javascript.

vloz

Le 05/01/2016 à 09h 32

#60

flagos_ a écrit :

Oui tu pourrais utiliser autre chose. Le souci, c’est de faire du code multiplateforme est vraiment pénible en C/C++ tandis qu’en java ca se fait plutot bien. 

Pas avec une LLVM (ce que fait apple pour iOS,  et google le fait deja avec pnacl)…

A l’epoque où android a été lancé, java etait peut etre un choix intéressant (parce que tres repandu, et que le systeme visée, de base, de pouvoir s’installer sur n’importe quoi).

Mais depuis, java (et donc sa declinaison employé par google) a pris tellement de retard sur tous les autres langages existants (ntm Oracle), c’est lourdingue… Et coté perf, ok, c’est loin d’etre à la ramasse pour les applications de base, mais pour les jeux ca reste toujours aussi lourdingue de devoir naviguer entre deux langages… et ça reste beaucoup plus gourmand…

Et y’a pourtant tellement de bonnes alternative qui pourrait le remplacer… Mais je pense que la team android s’en bat littéralement les couilles d’avoir 10ans de retard par rapport à MS ou Apple sur le plan du langage officiel…

Le 05/01/2016 à 09h 38

#61

Uther a écrit :

En effet cet article fait une grosse confusion entre brevet et copyright. Mais des article sur le jugement, qui expliquent ça bien, il y en a des milliers.
 Premier résultat après une recherche sur mon moteur :http://arstechnica.com/tech-policy/2014/05/oracles-java-api-code-protected-by-co...  


  &nbsp;
C’est plus compréhensible, mais je ne vois rien concernant une violation de la licence GPL par Google et son auto-attribution de la paternité de portions de code Java. C’est de l’extrapolation.

Il n’en reste pas moins que rendre copyrightable des API, donc des noms de classes, méthodes, signatures et structures de packages est complètement stupide et absurde. Le premier jugement, avec un juge qui connaissait réellement son affaire sans se laisser embobiner par Oracle, était beaucoup plus logique. Un dangereux précédent pour l’interopérabilité.

Le 05/01/2016 à 09h 43

#62

vloz a écrit :

Pas avec une LLVM (ce que fait apple pour iOS,  et google le fait deja avec pnacl)…

LLVM malgré son nom n’a rien d’un VM. C’est juste une infrastructure de compilation, donc ça aide a fabriquer un compilateur qui vise diverses architectures mais ça ne suffit pas a rendre pas un langage comme le C++ vraiment plus portable.

 De par sa spécification le C/C++ laisse volontairement des dizaines (voire centaines) de comportements indéterminés qui peuvent être traités complètement différemment en fonction des compilateurs et des l’architectures.

Le 05/01/2016 à 09h 44

#63

vloz a écrit :

Pas avec une LLVM (ce que fait apple pour iOS,  et google le fait deja avec pnacl)…

A l’epoque où android a été lancé, java etait peut etre un choix intéressant (parce que tres repandu, et que le systeme visée, de base, de pouvoir s’installer sur n’importe quoi).

Mais depuis, java (et donc sa declinaison employé par google) a pris tellement de retard sur tous les autres langages existants (ntm Oracle), c’est lourdingue… Et coté perf, ok, c’est loin d’etre à la ramasse pour les applications de base, mais pour les jeux ca reste toujours aussi lourdingue de devoir naviguer entre deux langages… et ça reste beaucoup plus gourmand…

Et y’a pourtant tellement de bonnes alternative qui pourrait le remplacer… Mais je pense que la team android s’en bat littéralement les couilles d’avoir 10ans de retard par rapport à MS ou Apple sur le plan du langage officiel…

Je ne suis pas vraiment d’accord avec toi. Clairement il y a de quoi faire pour améliorer java, mais non manifestement Google ne s’en bat pas les couilles. ART est un exemple de sacré dev sur cette techno, je ne suis pas spécialiste mais il me semble que c’est la première fois qu’une VM aussi utilisée intègre du AOT. Et puis pareil, la décision de passer sur OpenJDK montre qu’ils veulent s’investir sur ce sujet.

anonyme_92fcfbdd6cc3f0397af3a985adab6b1b

Le 05/01/2016 à 09h 50

#64

Apprendre l’assembleur n’est pas utile. La théorie suffit.

J’ai l’impression que ceux qui disent qu’il faut apprendre l’assembleur veulent seulement se venger d’avoir été forcé de l’apprendre. Un peu comme un bizutage, en fait.

Le 05/01/2016 à 09h 56

#65

CounterFragger a écrit :

C’est plus compréhensible, mais je ne vois rien concernant une violation de la licence GPL par Google et son auto-attribution de la paternité de portions de code Java. C’est de l’extrapolation.

Il a été reconnu violation du copyright c’est donc bien qu’il a été reconnu que Google a repris la structure des API de Java qui sont sous copyright d’Oracle, bien que disponibles sous licence GPL. Une infraction a la GPL etant une infraction au copyright comme une autre.

OpenJDK étant sous licence GPL si Google avait attribué la paternité du code à Oracle et mis son SDK sous licence GPL, il n’aurait pas été inquiété.

 

Le 05/01/2016 à 10h 00

#66

Hé bien je ne suis pas d’accord avec toi.

J’ai travaillé sur tout type d’application, du DVD-Interactif codé en Javascript + Assembleur au simulateur 3D temps réel en passant par de la GMAO, de l’application web et de l’application desktop. Et un soupçon de développement mobile.

au gré de ces expériences, je te rejoins sur le fait que savoir comment ça marche dans les basses couches peut être dans certains cas utile, mais c’est loin d’être systématiquement vrai.

Conseiller de commencer la programmation par l’assembleur : non.

Conseiller de commencer par apprendre de bonnes méthodes de travail : oui.

Si aujourd’hui je fais une application web en PHP/Angular.js, l’assembleur je m’en contrefout par contre

savoir  déboguer mon code client dans un navigateur : indispensable

comprendre comment le navigateur interprète mon code .js : indispensable

comprendre les spécificités de l’exécution asynchrone : indispensable

savoir brancher un débuggeur sur mon code PHP pour voir ce qui se passe lorsque le code serveur est exécuté : indispensable

Tout le code que l’on écrit n’est pas directement converti en langage machine comme dans le cas C,C++/assembleur.

Et l’intérêt de savoir comment mon serveur PHP lit mon code, le transforme en langage machine puis comment ce langage machine s’exécute, même si j’en comprends l’intérêt, je ne le donnerai pas en prérequis à l’apprentissage de la programmation mais plutôt comme un approfondissement de cette compétence, quelque chose qui permet de faire la différence entre un débutant et un lead technique par exemple.

Disons pour faire simple que les connaissances théoriques ne servent à rien sans les bonnes méthodes et les bons outils de travail.

Le 05/01/2016 à 10h 03

#67

gokudomatic a écrit :

Apprendre l’assembleur n’est pas utile. La théorie suffit.
J'ai l'impression que ceux qui disent qu'il faut apprendre l'assembleur veulent seulement se venger d'avoir été forcé de l'apprendre. Un peu comme un bizutage, en fait.
 C’est utile, pas toujours indispensable, mais clairement utile.

 Ce n’est jamais une mauvaise idée de savoir comment les choses se passent a bas niveau. Tout comme avoir des notions de mécanique aide a savoir gérer sa voiture même si ça n’est théoriquement pas indispensable pour conduire.

Le 05/01/2016 à 10h 04

#68

Sajicen a écrit :

Faudrait songer à faire preuve d’ouverture d’esprit les gens hein… On croirait entendre des enfants pensant que parcequ’ils n’aiment pas une chose tout le monde devrait la détester. Je ne pense pas que vous ayez conscience du nombre de périphériques qui tourne en Java et qu’on se sert quotidiennement. Je ne dis pas que ce langage est le meilleur ou le plus beau ou je ne sais quoi d’autre. Juste qu’il faut lui reconnaître des qualités comme des défauts et se rappeler que si Google a choisi la technologie Java pour son OS ce n’est pas pour rien.

sisi j’en parlais dans feu mes comm swordés…

mais ça s’applique aussi dans l’autre sens, à tous les dev qui ne jurent que par Java parce qu’ils ont eu la flemme d’apprendre autre chose…

 ce qui est sûr, c’est qu’on ne s’en débarrassera pas de si tôt

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Le 05/01/2016 à 10h 12

#69

Exception a écrit :

Et si les adorateurs de Java (qui ne sont autres que des développeurs pour qui les langages comme C++, qui nécessitent par exemple de libérer des pointeurs, sont trop compliqués pour eux) avaient le moindre argument pour répondre autre que “trooool”…

C++, c’est pas ce langage où on a dû permettre d’overloader operator -> afin de pouvoir simuler des smart pointers parce que les programmeurs étaient pas cap’ de faire des free() au bon moment ? " />

Le 05/01/2016 à 10h 14

#70

C’est justement le mot-clé : la théorie.

Si tu sais comment un processeur gère la mémoire de manière théorique, l’assembleur ne ferait que confirmer par la pratique ce que tu sais déjà. Mais tu peux aussi le faire avec C, Ada ou Pascal. L’assembleur en particulier n’est pas plus utile que ces autres langages un peu plus haut niveau. Ce qui est utile est la théorie. Et ce n’est pas parce que certains apprennent par la pratique, auquel cas l’asm est effectivement le plus efficace, que ça en devient une généralité.

Le 05/01/2016 à 10h 28

#71

Traduction foireuse. Un projet en C ne répondra pas aux même besoins qu’un projet en Java, et inversement.

Je t’invite par exemple à réaliser en C une application distribuée sur des serveurs d’applications, avec interfaces web et/ou mobiles, gestion de la généricité et sans ce que le développeur n’ait à s’occuper de la mémoire ni de recompiler le projet selon la plateforme.

Tu vas vite te rendre compte que .Net et Java sont les environnements les plus adaptés.

Pour ma part j’irai plutôt prendre du C pour de l’embarqué, pour un développement rapide avec utilisation d’API systèmes, etc.

Après tu voulais peut être parler du C++ qui même des avantages des deux (POO et accès système), mais toujours pas adapté pour l’exemple que je viens de donner.

Tu peux donc ranger ton troll. " />

P.S. J’en profite pour corriger une erreur de typo dans mon 1er message, où j’ai écris “qualité” au lieu de “quantité.

Et troll-poof : la qualité du code n’est pas inhérente au langage mais aux développeurs. ;)

tazvld Abonné

Le 05/01/2016 à 12h 55

#72

C est un très beau langage compilé.

C++ c’est un langage dégueulasse mais avec une notion d’objet, permet de faire tout et n’importe quoi, mais surtout n’importe quoi n’importe comment, massivement utilisé. Mais c’est toujours du compilé.

Ces précédents 2 langages sont effectivement plutôt efficace du fait de leur compilation et optimisation, mais la vitesse de programmation est très lente. Du coup, ils ont une utilité lorsque le besoin de performance se fait ressentir.

De ce fait, à coté, il y a des généralement codes universelles offrant des possibilité diverse et varier, simple d’accès (sans prise de tête avec la mémoire) avec une bibliothèque de base généralement assez bien fourni.

Python, est un langage pratique pour faire des petits truc rapide sans prise de tête. L’écriture est efficace mais l’écrit peut être dégueulasse. Code normalement portable sur la plupart des plateforme.

Javascript, du peu que j’ai utilisé, j’ai un ressenti assez négatif, assez bordélique et possède aussi le même problème que python. Cependant, théoriquement code universel dès lors qu’il existe un navigateur (qui l’interprète bien)

Et Java qui contrairement au 2 précédents à choisi de garder le coté très strict des langages compilés sans la prise de tête de la gestion de la mémoire. Java à fait aussi le choix d’un objet assez fort, du coup forçant à faire de l’objet pur.

Du coup, je trouve que java fait un très bon compromis pour faire des gros projets (garder un code acceptable) mais de l’autre arriver à cracher du code qui tourne assez rapidement.

Sinon, pour le problème de performance, La différence reste généralement à peut prêt proportionnelle entre les différents langage quelque soit le programme or la loi de Moore est exponentielle, du coup, c’est pas forcément intéressant de faire quelque chose de performant car de toute façon dans 1ans, les terminaux seront capable de le faire tourner dans le langage “moins bon”. En conclusions, utiliser des langages compilés n’a d’intérêt que lorsque que l’on est dans la recherche de performance (système, bibliothèque graphique, calcule intensif…). Pour le reste, un langage “haut niveau” est largement suffisant.

J’entends quelqu’un parler de langage fonctionnel ? aucun intérêt… si faire des preuves… mais personne ne prouve.

Le 05/01/2016 à 13h 59

#73

tazvld a écrit :

C’est un très beau langage compilé.

" />

" />

Le 05/01/2016 à 14h 08

#74

Je peux compléter sur js et python (que j’utilise tout les jours)

-Js seul est inadapté pour des gros projets, c’est vite le bazar mais il existe des outils pour remédier a ce problème. Son principal defaut est qu’il ne contraigne pas le dev et donc si ces derniers manquent de rigueur le code sera impossible a maintenir.

-Python marche aussi pour des projets de taille moyenne (quelques dizaines de milliers de lignes) il permet d’écrire bien plus vite que java et en beaucoup moins de ligne (au bureau en 10 000 ligne j’ai un SI qui en fait bine plus que 30 000 ligne en java) mais est (beaucoup) moins performant et comme le JS il fait confiance au développeur pour pas faire n’importe quoi. Encore une fois c’est pas adapté au monde des SSII ou on considère que chaque développeur est interchangeable avec un autre moins cher

Le 05/01/2016 à 15h 00

#75

Uther a écrit :

…
 Bien évidement! L'optimisation inutile et le débogage évitable, ça coûte cher.
Quand il s’agit de choses vendues à des millions d’exemplaire, l’optimisation n’est pas inutile et le surcoût pas significatif.

D’ailleurs, un Os comme Linux et la majorité de sa logithèque sont codés en C/C++…

Il suffit de se servir…

Pour une grande majorité des programmes dont ont besoin les entreprises, l’optimisation a tous les niveaux n’est pas nécessaire. Le plus souvent optimiser les accès à la base de donnée est amplement suffisant. Avoir rapidement quelque chose qui marche bien est bien plus important.

Qu’une application de gestion d’entreprise faite sur mesure soit codée en Java ne me choque pas. Par contre, sur un device vendu à des millions d’exemplaires…
         
Après si tu code uniquement pour la beauté et la performance du code ok, mais je ne suis pas sur que tu trouve beaucoup de patrons qui acceptent de payer pour ça.

Après, si tu codes uniquement pour pondre des programmes low cost…

Je rencontre au quotidien un bon paquet de “devices” et de programmes qui auraient bien besoin d’optimisation. Et cela sans parler des smartphones et de leurs applications.

Parfois, je me marre en constatant qu’on faisait des trucs plus fluides sur des 8 bits à 1Mhz il y a plus de 30 ans…

Le plus souvent optimiser les accès à la base de donnée est amplement suffisant.

Toutes les problématiques en informatique ne tournent pas autour de cela.
         
Donc tu préconise dans l’apprentissage des science physiques d’apprendre la relativité générale avant de pouvoir introduire la gravité dans la mécanique Newtonienne? Parce que la gravité ne s’explique correctement qu’avec la relativité générale. Mais tu retrouveras les ³⁄₄ de tes étudiants pendus si tu commence par ça.

Sauf que la relativité générale demande d’apprendre une palanquée de notions avant de pouvoir être comprise.

A l’inverse, faire de l’assembleur ne demande que de maîtriser l’addition et la soustraction.

Dans la pratique, un élève de niveau 6eme s’en sors très bien.

Pour info, je préconise un apprentissage du bas niveau sérieux pour tous les étudiants car c’est important. Mais il n’est pas nécessaire, de le faire en premier (bien que tout a fait possible). Les notion d’algorithmes sont bien plus utiles pour apprendre l’assembleur que l’inverse.

Je n’ai pas prétendu qu’il serait forcément nécessaire de le faire en premier. Juste que cela ne doit pas être abordé trop tard.

Je ne fais pas de hiérarchie par rapport à l’algorithmique, pour moi ces deux notions sont nécessaires.

Le 05/01/2016 à 15h 16

#76

Et tout cela reste encore à relativiser par les accès base de données. C’est bien joli d’avoir un langage super-optimisé-de-la-mort-qui-tue, mais dans une majorité d’applications “business” ça reste bien les accès base de données qui sont le facteur limitant. Même si on arrivait à optimiser la boucle de chargement des données à un unique REP STOSW en assembleur, on ne gagnera pas grand chose vu que le serveur a dû consulter les index, rechercher dans les caches, lire des blocs, assembler les données, etc. L’impact en performances d’utiliser un langage “moins efficace” pour parcourir les records une BDD s’efface par rapport à la simplicité d’écriture.

Par ailleurs, les langages fonctionnels sont très pratiques pour décrire des bases de règles et des validations de données (si la facture contient au moins trois produits du rayon brico, alors le taux de TVA est de 6%), beaucoup moins pour faire du transactionnel. Le grand avantage est que l’absence d’effets de bord fait que … hé bien un calcul ne peut pas avoir d’effet de bord, justement, et donc compromettre l’intégrité d’autres données. Très pratique quand c’est l’utilisateur final qui peut spécifier ses règles.

Le 05/01/2016 à 15h 28

#77

EMegamanu a écrit :

Traduction foireuse. Un projet en C ne répondra pas aux même besoins qu’un projet en Java, et inversement.

Je n’ai jamais prétendu le contraire. Si tu relis mes premiers commentaires, c’est bien précisé.

L’informatique, ce n’est pas un langage unique et merveilleux, mais le bon langage pour le bon usage.

Je t’invite par exemple à réaliser en C une application distribuée sur des serveurs d’applications, avec interfaces web et/ou mobiles, gestion de la généricité

Pour avoir créé quantité d’applications multiplateformes en C/C++, je ne vois pas le problème.

Il suffit de regarder comment une distribution Linux gère cette problématique avec des fermes de compilation.

et sans ce que le développeur n’ait à s’occuper de la mémoire ni de recompiler le projet selon la plateforme.

La gestion de la mémoire, il y a du pour et du contre. Et le pour, c’est qu’une gestion personnalisée de la mémoire est un élément essentiel dans l’optimisation.

Quand à recompiler un projet pour différentes plateformes, en pratique, ça n’a jamais été un vrai problème.

Tu vas vite te rendre compte que .Net et Java sont les environnements les plus adaptés.

Oui, ce sont bien les environnements les plus adaptés au développement rapide et low cost qui correspond au logiciel personnalisé courant en entreprise.

La qualité de ces logiciels est logiquement basse. Les couts et la rapidité de développement sont les élément essentiels.

La ou je suis plus choqué , c’est de voir ces langages sur des logiciels de grande diffusion, voire dans un Os partagé par des millions de personnes.

Pour ma part j’irai plutôt prendre du C pour de l’embarqué, pour un développement rapide avec utilisation d’API systèmes, etc.

Globalement, le C/C++ est utilisé partout ou l’on désire un programme optimisé et de qualité.

Mais cela ne signifie pas pour autant que tout doit être programmé dans ce langage qui est plus adapté aux progiciels à longue durée de vie qu’a de la programmation rapide et pas chère.

Après tu voulais peut être parler du C++ qui même des avantages des deux (POO et accès système), mais toujours pas adapté pour l’exemple que je viens de donner.

Euh, si on parle des possibilités, il y a tellement de choses que C/C++ peut faire et que Java ne peut pas que la comparaison ne tient pas un instant.

Tu peux donc ranger ton troll. " />

Le fait qu’un langage comme java impose le bound checking, ne propose même pas de type entier non signés et ne permet même pas la surcharge des opérateurs, ce n’est pas un troll…

Et je ne parle même pas de certaines inepties d’écriture.

Même pour faire du développement rapide, Java est à jeter. C# est bien meilleur…

Et troll-poof : la qualité du code n’est pas inhérente au langage mais aux développeurs. ;)

Sauf que le meilleur développeur du monde ne pourra jamais compenser certaines limites de certains langages. Certaines limites sont réellement irrémédiables…

Le 05/01/2016 à 16h 06

#78

sr17 a écrit :

Quand il s’agit de choses vendues à des millions d’exemplaire, l’optimisation n’est pas inutile et le surcoût pas significatif.

 On est d’accord mais c’est très loin d’être le cas de la majorité des logiciels produits.

 

sr17 a écrit :

Après, si tu codes uniquement pour pondre des programmes low cost…

 Je code pour répondre au besoin, on optimise là ou c’est nécessaire. Les performance de Java sont plus que suffisantes pour que la différence avec du natif ne soit pas sensible sur les applications Web ou de bureau qui ne demandant pas une réactivité de l’ordre d’un OS / Jeu / Browser / …

 En général ce qui ralentit ces applications c’est surtout l’accès aux données.

 

sr17 a écrit :

Toutes les problématiques en informatique ne tournent pas autour de cela.

 Toutes non, mais dans beaucoup d’application, le goulot d’étranglement des performances n’est pas la vitesse intrinsèque du langage mais les entrées-sorties et dans l’écrasante majorité des applications d’entreprise c’est le réseau et la bases de données.

 

  sr17 a écrit :

A l’inverse, faire de l’assembleur ne demande que de maîtriser l’addition et la soustraction.

Dans la pratique, un élève de niveau 6eme s’en sors très bien.

  Mais là tu fais toi aussi abstraction de l’électronique qui au au final aussi instructive pour celui qui fait de l’assembleur, que l’assembleur a celui qui fait de la programmation de haut niveau.

( Semi " /> ) 

  

Le 05/01/2016 à 16h 22

#79

33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :

Et tout cela reste encore à relativiser par les accès base de données. C’est bien joli d’avoir un langage super-optimisé-de-la-mort-qui-tue, mais dans une majorité d’applications “business” ça reste bien les accès base de données qui sont le facteur limitant. Même si on arrivait à optimiser la boucle de chargement des données à un unique REP STOSW en assembleur, on ne gagnera pas grand chose vu que le serveur a dû consulter les index, rechercher dans les caches, lire des blocs, assembler les données, etc. L’impact en performances d’utiliser un langage “moins efficace” pour parcourir les records une BDD s’efface par rapport à la simplicité d’écriture.

Dans la majorité des cas de logiciels personnalisés de gestion d’entreprise traitées par les SS2I, c’est effectivement la base de données qui est le facteur limitant.

A l’inverse, dans les logiciels et les système d’exploitation, ce cas est plutôt rare.

Il y a donc bien deux philosophies différentes.

Le problème, c’est quand l’une déborde sur l’autre…

Cela étant dit, il y a parfois des interfaces qui rament et ce n’est pas de la faute de la base de données.

Par ailleurs, les langages fonctionnels sont très pratiques pour décrire des bases de règles et des validations de données (si la facture contient au moins trois produits du rayon brico, alors le taux de TVA est de 6%), beaucoup moins pour faire du transactionnel. Le grand avantage est que l’absence d’effets de bord fait que … hé bien un calcul ne peut pas avoir d’effet de bord, justement, et donc compromettre l’intégrité d’autres données. Très pratique quand c’est l’utilisateur final qui peut spécifier ses règles.

Les langages fonctionnels sont un objet d’étude intéressant, voire indispensable. Comme l’assembleur qui vous apprendra le “bas niveau”, c’est un objet d’étude qui vous apprendra des choses sur la programmation de haut niveau. Mais comme l’assembleur, ce n’est pas un outil pratique au quotidien.

Ne vous laissez pas bluffer par ceux qui annoncent l’éternelle révolution des langages fonctionnels, ça fait plus de 50 ans qu’ils font la révolution…

Le 05/01/2016 à 16h 50

#80

Uther a écrit :

On est d’accord mais c’est très loin d’être le cas de la majorité des logiciels produits.

Oh que si.

La très grande majorité des grands logiciels sont écrit en C/C++ ainsi que les Os et leurs diverses couches.

Et quand un logiciel est écrit en Java, par exemple Eclipse, cela se sent tout de suite…

Je code pour répondre au besoin, on optimise là ou c’est nécessaire. Les performance de Java sont plus que suffisantes pour que la différence avec du natif ne soit pas sensible sur les applications Web ou de bureau qui ne demandant pas une réactivité de l’ordre d’un OS / Jeu / Browser / …

C’est une idée reçue fortement répandue, mais elle est malheureusement fausse.

Il suffit pour le comprendre de voir l’inconfort que l’on ressent sur tous ces sites web qui rament et ces logiciels trop lents.

L’idée reçue viens du fait que le gros d’une application a rarment besoin d’optimisation. Ce que certains interprètent à tort comme le fait que l’optimisation serait inutile.

Sauf que tout le confort d’un logiciel peut reposer parfois sur quelques lignes de code…

Pour info, dans certains logiciels, on utilise encore l’assembleur pour certaines parties critiques.

En général ce qui ralentit ces applications c’est surtout l’accès aux données.

Sauf que cela n’est vrai que dans un seul type de logiciels.

Toutes non, mais dans beaucoup d’application, le goulot d’étranglement des performances n’est pas la vitesse intrinsèque du langage mais les entrées-sorties et dans l’écrasante majorité des applications d’entreprise c’est le réseau et la bases de données.

Rectifions : Dans la majorité des aplications d’entreprise que le pisseur de code en SS2I est amené à écrire.

Parce qu’heureusement que la base de données et l’Os sont écrites en C/C++ et pas en Java.

Ajoutons que ce qui est vrai dans ce type d’application particulière est un cas rare dans les applications desktop en général : Exemple logiciel comme photoshop.

Mais là tu fais toi aussi abstraction de l’électronique qui au au final aussi instructive pour celui qui fait de l’assembleur, que l’assembleur a celui qui fait de la programmation de haut niveau.

( Semi " /> )

La dessus, tu as parfaitement raison. Faire de l’électronique me semble également indispensable.

Le 05/01/2016 à 17h 31

#81

sr17 a écrit :

Oh que si.
La très grande majorité des grands logiciels sont écrit en C/C++ ainsi que les Os et leurs diverses couches.     
Et quand un logiciel est écrit en Java, par exemple Eclipse, cela se sent tout de suite…

 La majorité des logiciel nécessitant un contrôle des performance oui. Mais ces logiciels ne sont pas la majorité des logiciels produits, loin de là.

 Et Visual Studio a beau être en C++, je le trouve pas plus réactif qu’Eclipse.

sr17 a écrit :

C’est une idée reçue fortement répandue, mais elle est malheureusement fausse.

Il suffit pour le comprendre de voir l’inconfort que l’on ressent sur tous ces sites web qui rament et ces logiciels trop lents.

  Sauf que le temps que le langage passe réellement à générer une page web est en général bien inférieur au temps consommé dans les IO et les accès à base de données.

 

sr17 a écrit :

Sauf que tout le confort d’un logiciel peut reposer parfois sur quelques lignes de code…

Pour info, dans certains logiciels, on utilise encore l’assembleur pour certaines parties critiques.

 Tout comme en Java on peut utiliser d’autres langages pour les parties critiques. Bref ni le C ni le Java ne sont parfait et peuvent être complémenté, on est d’accord.

sr17 a écrit :

Sauf que cela n’est vrai que dans un seul type de logiciels.

 Non, loin de là. Optimiser les temps d’IO c’est très important, et c’est très souvent le premier goulet d’étranglement y compris en bas niveau.

sr17 a écrit :

Rectifions : Dans la majorité des aplications d’entreprise que le pisseur de code en SS2I est amené à écrire.

Oui tu as raison les gens qui font du C++ sont peuvent travailler sur des applications noble et peuvent bien heureusement se permettre de chier sur les gens des SSII (qui pour ta gouverne peuvent aussi faire C++). 

 Je pense que je vais arrêter la discution là.  J’ai à peu près cerné le niveau d’ouverture de ton point de vue.

Le 05/01/2016 à 19h 06

#82

Uther a écrit :

  Je pense que je vais arrêter la discution là.  J’ai à peu près cerné le niveau d’ouverture de ton point de vue. 

" />

Je pense qu’on aurait pu continuer de jouer longtemps avec lui… mais j’ai du travail de “pisseur de code”* devant moi. 

* Ben oui pisser du MVC, des Factory, des Observers, des Modules, etc. ce n’est absolument pas réfléchir ou chercher à optimiser quoi que ce soit. " />

psikobare

Le 06/01/2016 à 06h 40

#83

et personne pour défendre rust et go dans vos débats  :(

Le 06/01/2016 à 07h 33

#84

Je veux bien défendre Rust (J’aime bien ce langage), et Go( un bon langage pour “pisseur de code en SS2I”) mais personne n’en a encore dit du mal.

Le 06/01/2016 à 08h 49

#85

personne n’en a rien dit :)

en fait, j’ai cru voir certains dire que le C/C++ serait l’éternel champion, mais j’émets de gros doute là dessus

non pas que je pense qu’il disparaisse, mais sa popularité pourrait baisser plus vite qu’on ne le pense, et, selon moi, rust et go sont les langages qui vont lui prendre le plus de part (dans des catégories différentes)

Le 06/01/2016 à 16h 14

#86

psikobare a écrit :

personne n’en a rien dit :)

en fait, j’ai cru voir certains dire que le C/C++ serait l’éternel champion, mais j’émets de gros doute là dessus

non pas que je pense qu’il disparaisse, mais sa popularité pourrait baisser plus vite qu’on ne le pense, et, selon moi, rust et go sont les langages qui vont lui prendre le plus de part (dans des catégories différentes)

Personne n’a jamais dit que le C/C++ restera éternellement le champion de sa catégorie.

Mais pour l’instant, force est de constater que ce langage est bien parti pour le rester.

Ce qui fait l’inouïe longévité de C, c’est qu’il n’a jamais existé de vrai concurrent qui cherche à améliorer ce qui fait sa force.

Le problème, c’est que les concurrents n’ont (hélas) pas compris ce qui fait le succès de C/C++. Ils cherchent à le concurrencer en apportant plus de features et en apportant des solutions déterminées à des problèmes donnés ou à rendre la programmation plus simple.

Or, c’est tout ce qu’un programmeur C/C++… ne recherche pas.

Ce qui fait le succès de C/C++ dans la programmation avancée, c’est le fait que ce langage permet une énorme souplesse et de faire quasiment ce qu’on veut avec un maximum de contrôle à bas niveau pour implémenter SES propres solutions comme on le désire.

Pour détrôner C/C++, il faut arriver à faire mieux sur ses points forts. En d’autre terme, faire mieux en terme de contrôle à bas niveau et de souplesse du langage.

C’est possible (et nous en rêvons) de voir un jour un concurrent. La partie C++ pourrait être améliorée sur le plan du contrôle à bas niveau. Mais à conditions que les créateurs de langage ne se trompent pas direction.

Le 06/01/2016 à 17h 09

#87

Uther a écrit :

La majorité des logiciel nécessitant un contrôle des performance oui. Mais ces logiciels ne sont pas la majorité des logiciels produits, loin de là.

La majorité des progiciels de qualité ont un besoin de performance à un niveau ou à un autre.

Et toutes les entreprises qui font de bons progiciels ont des programmeurs qui savent optimiser.

J’ajouterais que dans notre société, l’impact des logiciels mal optimisés sur le confort de vie des gens est sous estimé.

Je me souviens parfaitement de l’époque entre les années 80 et 90 ou les vieux distributeurs de billet automatique ont été remplacés par des nouveaux beaucoup plus lent et des temps d’attentes que cela générait avec des énormes files d’attente.

Pas plus tard qu’hier j’était dans un magasin : leur système informatique ramait, ce qui fait que les clients attendaient plus d’une demi heure.

A tous les niveaux de la société, ces programmes mal optimisés nous pourrissent la vie et coûtent de l’argent à ceux qui pensaient économiser sur la qualité…

Et Visual Studio a beau être en C++, je le trouve pas plus réactif qu’Eclipse.

Je ne pourrais pas te certifier que les versions récentes de Visual Studio sont encore codées en C/C++.

Mais il n’y a pas que ces deux IDE pour comparer…

Sauf que le temps que le langage passe réellement à générer une page web est en général bien inférieur au temps consommé dans les IO et les accès à base de données.

Sauf qu’il y a des solutions techniques à cela. Y compris dans certains cas pour se passer complètement ou partiellement de la base de données.

Un programmeur qui sait optimiser te trouvera les solutions adaptées à chaque cas de figure.

Et sans aller jusque la, simplement déjà de savoir bien optimiser les requêtes, éviter de les multiplier quand c’est inutile, bien configurer sa base de données et les index de ses tables, etc….

Tout comme en Java on peut utiliser d’autres langages pour les parties critiques. Bref ni le C ni le Java ne sont parfait et peuvent être complémenté, on est d’accord.

Sauf que les bons compilateurs C/C++ permettent d’intégrer de l’assembleur directement dans le flux du code et non pas comme un module.

Cela dit, le fait de mixer les langages peut être une excellente solution dans certains cas de figure.

Non, loin de là. Optimiser les temps d’IO c’est très important, et c’est très souvent le premier goulet d’étranglement y compris en bas niveau.

Si je suis d’accord que l’optimisation des temps d’accès est extrêmement important, il faut réaliser que cela ne se limite pas à la mémoire de masse.

Parce que quand un bon programmeur arrive à se débarrasser du problème des accès disque, par exemple en implémentant un cache en RAM, le goulet d’étranglement suivant, c’est la vitesse d’accès aux données en RAM.

Et un langage comme Java, avec son “Bound Checking” imposera toujours des limitations la dessus.

D’ailleurs, le problème, c’est que le programmeur de SS2I courant a une vision complètement fausse et biaisée du problème pour la simple raison que la très grande majorité des programmes qu’il écrit utilisent des bases de données.

Dans d’autres domaines de l’informatique qu’il méconnaît, c’est exactement l’inverse. Pour de nombreuses catégories de logicielles, c’est plutôt l’accès à la mémoire vive qui est le goulet d’étranglement principal.

Oui tu as raison les gens qui font du C++ sont peuvent travailler sur des applications noble et peuvent bien heureusement se permettre de chier sur les gens des SSII (qui pour ta gouverne peuvent aussi faire C++).

Je pense que je vais arrêter la discution là. J’ai à peu près cerné le niveau d’ouverture de ton point de vue.

L’erreur, c’est de prendre une critique sur un langage comme un affront personnel pour les programmeurs qui les utilisent.

Pour ma part, je n’ai jamais pensé qu’il existerait une noblesse particulière à utiliser un outil plutôt qu’un autre ou à réaliser un type d’application plutôt qu’un autre.

J’aurais d’ailleurs tendance à penser que ce n’est pas les bons outils qui demandent le plus de talent.

Comme tous les programmeurs, dans ma vie, j’ai fait de tout. Et surtout, je ne programme pas qu’en C/C++…

anonyme_17187f2fe30034ef77b37a104608a3ce

Le 08/01/2016 à 16h 46

#88

Encore plus court :

 C != C++

artragis Abonné

Le 09/01/2016 à 12h 11

#89

Python, est un langage pratique pour faire des petits truc rapide

sans prise de tête. L’écriture est efficace mais l’écrit peut être

dégueulasse. Code normalement portable sur la plupart des plateforme.

quand

tu codes dans un langage depuis plus d’unb an, peu importe son nom, ce

que tu dit est vrai : tu codes vite, tu es efficace mais tu peux

rapidement faire du code crade.

Et a priori, le code python étant

100 fois plus expressif que les autres, j’ai tendance à penser qu’il

est bien plus propre qu’un code java farci d’antipattern.

Et Java qui contrairement au 2 précédents à choisi de garder le

coté très strict des langages compilés sans la prise de tête de la

gestion de la mémoire. Java à fait aussi le choix d’un objet assez fort,

du coup forçant à faire de l’objet pur.

le concept “objet” est plus fort et mieux intégré en python (ou mieux en C#) qu’en java tu sais.

J’entends

quelqu’un parler de langage fonctionnel ? aucun intérêt… si faire des

preuves… mais personne ne prouve.

un des plus gros

utilitaires de conversion de format, pandoc, est en haskell, et utilise à

mort les concept du langage, Monade y compris… Donc raté.

PS :

par honnêteté, je suis issu du monde PHP, et j’ai évolué vers .NET

(C#et un peu F#) et python pour lequel je fais autant du scripting que

du web (django, pour Ce projet (site web))

Google n’utilisera plus les API Java d’Oracle pour le prochain Android

Raisons techniques ou juridiques, au choix

Google, Oracle et un long procès autour de la propriété intellectuelle

Dalvik dans un premier temps, les API dans un second

Le travail continue en attendant la présentation d'Android 7.0

Tiens, en parlant de ça :

Qualcomm dévoile son Snapdragon X Plus et trois variantes du modèle Elite

Plus moins bien

Transhumanisme, long-termisme… des idéologies aux racines eugénistes ?

Science artificielle

Corrigée depuis deux ans, une faille Windows activement exploitée par des pirates russes

Faille 1460-days

Sommaire de l'article

Introduction

Google, Oracle et un long procès autour de la propriété intellectuelle

Dalvik dans un premier temps, les API dans un second

Le travail continue en attendant la présentation d'Android 7.0

Qualcomm dévoile son Snapdragon X Plus et trois variantes du modèle Elite

Transhumanisme, long-termisme… des idéologies aux racines eugénistes ?

Corrigée depuis deux ans, une faille Windows activement exploitée par des pirates russes

La CNIL fait le bilan de son année 2023, cinquième année après RGPD

#LeBrief : TikTok suspend sa version Lite, Ariane 6 debout, enquête sur Pegasus, l’Europe et la violence numérique aux femmes

Terrorgram, la fabrique de terroristes d’extrême-droite, à coups de mèmes et de shitposts

Fiabilité des disques durs HAMR de 30 To et plus : Seagate donne des chiffres

[Màj] Le Congrès des États-Unis vote la loi obligeant ByteDance à vendre TikTok

#LeBrief : Fedora 40, anniversaire Hubble, vidéosurveillance algorithmique à Cannes, Voyager 1, Android 15 bêta 1.1

Sur GitHub et GitLab, des commentaires détournés pour stocker des malwares

[FAQ] Notre antisèche sur l’informatique quantique

L’Université d’Oxford ferme le Future of Humanity Institute dirigé par Nick Bostrom

#LeBrief : Apple rachète le français Datakalab (IA), propagande de la Russie, fin de partie pour Roccat, Proton Mail vs dark web

Europol milite pour un chiffrement de bout en bout « flexible »

Inclusion dans la tech : critiqué, le CEO de Qovery menace une internaute de poursuites

L’extension des prestataires américains devant collaborer avec la NSA fait polémique

#LeBrief : fuite chez Speedy, Rust pour Thunderbird, Saint Exupéry et PhiFire AI pour le satellite Φsat-2

Des institutions internationales s’engagent pour l’ouverture des données sur la recherche

#Flock craque le slip et explose les quotas

[Édito] Au pays des VPN menteurs…

Les clients LastPass victimes d’une attaque par phishing orchestrée grâce à un kit clé en main

Les recommandations de la NSA pour « déployer des systèmes d’IA en toute sécurité »

#LeBrief : Windows Store amélioré, 28 licenciements chez Google, sécurité des données des français, compétition 404CTF

Commentaires (97)