Google travaille sur la conversion du code Java en Objective-C

Jeter un pont entre Android et iOS

Le 17 septembre 2012 à 14h51

4 min

Logiciel

Google vient d’annoncer un projet visant à produire un convertisseur pour Java. La porte de sortie ? L’Objective-C, le langage d’Apple pour créer des applications sous OS X et iOS. Une manœuvre qui a plusieurs significations.

Réexploiter les connaissances

Aujourd’hui, le succès d’une plateforme repose plus que jamais sur l’attrait pour les développeurs tiers. Ils sont à la racine du cercle vertueux qui engendre à son tour la notion d’écosystème : un éditeur propose une plateforme équipée d’API, les développeurs sont séduits, des applications apparaissent, augmentent le capital d’attractivité de ladite plateforme aux yeux des clients.

L’iPhone a presque été dans ce domaine une image d’Épinal tant le système d’exploitation, iOS, a joué un rôle de plus en plus important dans son succès. Aujourd’hui, acheter un iPhone, un iPod Touch ou un iPad, c’est la garantie pour le client de disposer de dizaines voire de centaines de milliers d’applications. Cette réserve crée un centre de gravité très important pour l’acheteur, et le cas s’est répété de la même manière avec Android.

Traduire le Java en Objective-C

Google a donc publié la première préversion d’un tel convertisseur. Estampillé « J2ObjC », il signifie littéralement « Java vers Objective-C ». À terme, il permettra de traduire des pans entiers de code Java pour en écrire l’équivalent dans le langage d’Apple. L’intérêt ? Récupérer les compétences des développeurs Java pour leur permettre de travailler sur OS X ou iOS sans être nécessairement des experts en Objective-C.

Seulement voilà, il existe des différences fondamentales entre Java et l’Objective-C, et les développeurs seront dans tous les cas mis à contribution. Par exemple, Java est un langage possédant un ramasse-miettes (ou Garbage Collector) mais travaillant différemment de celui d'Objective-C. Google recommande du coup aux développeurs d'utiliser la méthode ARC (automatic ressource counting).

Google se focalise sur la mécanique interne

Autre élément important à savoir : la conversion ne pourra s’effectuer que sur le code ne touchant pas l’interface. Hors de question pour Google de produire un type d’interface valable pour plusieurs plateformes. Seuls l’intéressent les mécanismes internes de l’application. En outre, le projet débute et la qualité est estimée à mi-chemin entre alpha et bêta, ce qui signifie que de nombreux points sont encore à améliorer.

Le processus de conversion traite les éléments du code Java pour en trouver les équivalents Objective-C. Il existe des cas simples, comme boolean vers BOOL ou encore java.lang.Object vers NSObject, mais d’autres sont moins précis, comme les tests JUnit. Google utilise d’ailleurs l’exemple suivant en Java :

int getLength(List list, int index) { return list.get(index).length(); }

Traduit en Objective-C par J2ObjC, le code devient :

-(int)getLengthWIthJavaUtilList:(JavaUtilList *)list withInt:index { return [(NSString *) [list getWithInt:index] length]; }

Et pour ceux qui se demanderaient pourquoi Google travaille sur un tel projet, la réponse est très simple : accélérer le travail des développeurs qui voudraient créer des applications à la fois pour Android et pour iOS. L’éditeur pourrait ainsi court-circuiter l’obligation de devoir choisir entre l’un et l’autre.

Ceux qui souhaitent en savoir davantage pourront se rendre sur le page officielle du projet sur Google Code.

Commentaires (58)

jinge

Le 17/09/2012 à 16h04

Hum… Vive le .Net

En fait il faut développer en .Net, transformer ça en java, puis en ObjC? ^^

xillibit Abonné

Le 17/09/2012 à 17h07

jinge a écrit :

Hum… Vive le .Net

En fait il faut développer en .Net, transformer ça en java, puis en ObjC? ^^

Pourquoi se compliquer la vie ?

Anonyme

Le 17/09/2012 à 17h28

xillibit a écrit :

Pourquoi se compliquer la vie ?

Ca va encore, on pourrait faire un ricochet sur Python translaté en Brainfuck aussi pour l’occasion :shadock:

Sebdraluorg

Le 17/09/2012 à 17h46

Quand je lis ça je me rend compte qu’il manque clairement un editeur d’appli pour smartphone qui aurait son propre language et qui ‘compilerait’ soit en .Net soit en java soit en ObjC suivant la plateforme cible choisie.

Bref un peu comme en C/C++.

Hormis un acteur tiers je pense que le seul qui aurait un réel intéret à le faire c’est Microsoft, ainsi si WP8 ne cartonne pas ils se retrapperont sur VS.

atomusk

Le 17/09/2012 à 18h00

pafLaXe a écrit :

Ca va encore, on pourrait faire un ricochet sur Python translaté en Brainfuck aussi pour l’occasion :shadock:

" />

jinge

Le 17/09/2012 à 18h45

Sebdraluorg a écrit :

Quand je lis ça je me rend compte qu’il manque clairement un editeur d’appli pour smartphone qui aurait son propre language et qui ‘compilerait’ soit en .Net soit en java soit en ObjC suivant la plateforme cible choisie.

Bref un peu comme en C/C++.

Hormis un acteur tiers je pense que le seul qui aurait un réel intéret à le faire c’est Microsoft, ainsi si WP8 ne cartonne pas ils se retrapperont sur VS.

Ca existe, par exemple premier résultat ggle:http://phonegap.com/

Cependant comme tout framework, c’est bien pour les applications qui ne servent à rien, mais dès qu’il faut faire quelque chose d’un peu compliqué mieux vaut être réellement sur la plateforme (voir les déclarations de facebook….)

C’est utile pour toutes les plateformes à faible potentiel éventuellement pour avoir une visibilité, mais après pour Android/WP/iOS je ne pense pas que ce soit une bonne chose… (pour RIM si on est pas certain de son avenir?, symbian, all linux, bada, WebOS, … à la limite…)

jinge

Le 17/09/2012 à 18h48

Sebdraluorg a écrit :

Quand je lis ça je me rend compte qu’il manque clairement un editeur d’appli pour smartphone qui aurait son propre language et qui ‘compilerait’ soit en .Net soit en java soit en ObjC suivant la plateforme cible choisie.

Bref un peu comme en C/C++.

Hormis un acteur tiers je pense que le seul qui aurait un réel intéret à le faire c’est Microsoft, ainsi si WP8 ne cartonne pas ils se retrapperont sur VS.

Si MS développait VS pour Android et iOS ça risquerait de leur faire perdre leur avantage! VS avec le .Net est un des gros atouts de MS, c’est probablement en grande partie pour ça qu’ils arrivent à avoir autant d’applis sur leur store.

Oungawak

Le 17/09/2012 à 18h56

jinge a écrit :

Hum… Vive le .Net

En fait il faut développer en .Net, transformer ça en java, puis en ObjC? ^^

C’est quoi pour convertir du .NET en Java ? Je connais IKVM mais il ne fait que Java->.NET à ma connaissance. Si ça existe vraiment, en effet .NET deviendrait le roi de la “porkabilité”. " />

Quelqu’un pour coder un petit programme tout simple en .NET, le traduire automatiquement une première fois en Java puis une seconde fois en Objective-C et nous montrer la petite merveille d’optimisation et d’élégance qui en résultera ? " />

Genre (approximativement, je pratique pas beaucoup Java et encore moins Objective-C " />) :

.NET :

var compte = 5;

compte += 1;

Java :

int var_a = 0;

var_a = 5;

var_a = var_a + 1;

Objective-C :

void f1(int int1, int int2) { return int1 + int2; }

…

int int3;

int int4;

int3 = 0;

int3 = 5;

int4 = 0;

int4 = f1(int3, 1);

int3 = int4;

(Bonus Ultra combo pour .Net->Java->Objective-C->Java->Objective-C->Java->.Net)

" />

Clapitti

Le 17/09/2012 à 18h58

Oui ça se voit que tu n’utilises pas l’Obj-C, car le nom de ta fonction f1 est beaucoup trop court " />

Sebdraluorg

Le 17/09/2012 à 19h05

Oungawak a écrit :

void f1(int int1, int int2) { return int1 + int2; }

" />

Oungawak

Le 17/09/2012 à 19h22

Sebdraluorg a écrit :

" />

Oups, rentre du boulot, crevé, pardon aux familles, toussa… " />

Et puis ça pourrait très bien être une faute de la traduction automatique si elle est suffisament médiocre. " />

pecos

Le 17/09/2012 à 19h27

C’est intéressant.

Le contraire m’aurait plus intéressé en fait… " />

Cependant je ne me fais pas la moindre illusion sur le résultat : quand on veut niveler, c’est par le bas que ça se passe.

Java et objective-C ont chacun des qualités que l’autre n’a pas, sans parler des APIs.

Donc, je ne crois pas un instant à la faisabilité d’une telle entreprise pour des apps performantes, complexes et ergonomiques.

En tous cas, de mon côté, je me casse tellement les dents à essayer de comprendre comment porter sous android certaines de mes apps que j’imagine que

ça doit être la même chose dans l’autre sens

il se pourrait que ça ne soit pas possible, à moins de faire de la merde.

dieudivin

Le 17/09/2012 à 20h04

Codeur… " />

Un métier polyglotte où chacun y va de son dialecte " />

" />

Glouk

Le 17/09/2012 à 20h22

Sebdraluorg a écrit :

Quand je lis ça je me rend compte qu’il manque clairement un editeur d’appli pour smartphone qui aurait son propre language et qui ‘compilerait’ soit en .Net soit en java soit en ObjC suivant la plateforme cible choisie.

Beeeerk !

Glouk

Le 17/09/2012 à 20h31

Quand on voit le résultat donné dans l’exemple, ça ne fait vraiment pas rêver, notamment avec tous ces get qui traînent partout dans les noms de méthodes.

Mais comme première passe pour adapter le plus gros du code d’une bibliothèque indépendante de la plateforme avant de nettoyer le résultat à la main à grands coups de refactoring, ça peut être intéressant.

Ce qui est triste, en revanche, c’est que comme toujours il y aura des flemmards incompétents pour utiliser ça directement pour pondre la version finale de leur code, qui plus est en l’appliquant à des parties de plus haut niveau de leurs applis au lieu d’en développer une version spécifique à chaque plateforme.

rFlex

Le 17/09/2012 à 23h27

Pour ceux qui ne connaîtraient pas, il y a MonoTouch et Mono for Android. Ce sont des implémentations propriétaires de Mono et .NET (fait par les développeurs eux-mêmes de Mono) sur respectivement iOS et Android. Cela permet de faire du code 100% portable entre les deux plateformes (seul l’interface ne l’est pas, puisqu’elles utilisent directement des bindings vers les langages natifs des plateformes respectives).

Je travaille sur ça au boulot, ça marche très bien et c’est très performant. Tu développes en C# (quand même plus agréable que le Java et encore plus que l’Objective-C) et 80% du code est crossplateform.

http://xamarin.com

Glouk

Le 18/09/2012 à 16h26

rFlex a écrit :

Malheureusement, ce n’est plus vraiment quelque chose de difficile à prouver

Bien sûr que si.

et ce n’est pas ton argumentaire impressionnant qui changera quelque chose.

Tu auras peut-être noté que mon argumentaire essayait de se mettre à la hauteur du vide du tien. Ou peut-être pas.

Glouk

Le 18/09/2012 à 16h33

Sebdraluorg a écrit :

Euh si, perso j’ai jamais croisé une personne ayant pratiqué (réellement) le C# et le trouver moins confortable qu’un autre ! Pourtant j’ai des barbus dans mes collègues !

Ne pas confondre « ne pas trouver que C# est [bien] plus agréable que l’Objective C » et « trouver que C# est moins agréable que l’Objective C ».

Euh dis ça à la communauté C, dis leurs que ce sont de fainéants et qu’ils n’ont qu’à se taper de l’asm pour chaque machine cible !

J’espère que tu n’es pas réellement convaincu qu’il y a un rapport entre ça et ce dont on parlait.

Puis j’ai pas dis que l’éditeur devait être fait avec les pieds hein ! Si c’est fait proprement ça marchera nickel, et si tu pars d’un de tes langages pour le porter vers un autre il faut être vachement tarte pour faire ça de travers :s

Tu n’as manifestement compris que le problème ne vient tellement pas des langages utilisés, mais bien des différences d’API entre les plateformes. Et je parle des vraies différences, celles qui font qu’on n’organise ni son code, ni son interface, ni même la logique de fonctionnement d’une partie de son application, de la même manière.

Le framework de haut niveau, dit « multiplateforme », qui gère réellement ces différences de façon magique, sans laisser de côté la moindre fonction spécifique à chacune des plateformes couvertes, on l’attend toujours… et on risque de l’attendre encore longtemps.

-Gui-

Le 18/09/2012 à 16h48

Glouk a écrit :

Ne pas confondre « ne pas trouver que C# est [bien] plus agréable que l’Objective C » et « trouver que C# est moins agréable que l’Objective C ».

J’espère que tu n’es pas réellement convaincu qu’il y a un rapport entre ça et ce dont on parlait.

Tu n’as manifestement compris que le problème ne vient tellement pas des langages utilisés, mais bien des différences d’API entre les plateformes. Et je parle des vraies différences, celles qui font qu’on n’organise ni son code, ni son interface, ni même la logique de fonctionnement d’une partie de son application, de la même manière.

Le framework de haut niveau, dit « multiplateforme », qui gère réellement ces différences de façon magique, sans laisser de côté la moindre fonction spécifique à chacune des plateformes couvertes, on l’attend toujours… et on risque de l’attendre encore longtemps.

Bien sur que c’est impossible de faire du général et du spécifique en même temps, mais à un moment il faut choisir entre productivité et optimisation au poil.

Je ne jugerai pas les outils vu que je n’en ai pas testé mais si je devais faire du multi plateformes, pour une appli ‘classique’ (pas du jeu 3D), je regarderai surement du coté de Mono Touch/Mono For Android/(et en bonus on a la compat Windows Mobile) vu que le C#/.NET est bcp plus agréable à utiliser que Java/ObjC amha.

rFlex

Le 18/09/2012 à 16h56

Glouk a écrit :

Bien sûr que si.

Tu auras peut-être noté que mon argumentaire essayait de se mettre à la hauteur du vide du tien. Ou peut-être pas.

Dommage, j’aurais été curieux de voir ton point de vue, malheureusement ton aggressivité m’indique dors et déjà que tu sembles être quelqu’un de non prêt à une discussion ouverte (je peux néanmoins me tromper).

Sebdraluorg

Le 18/09/2012 à 22h36

Glouk a écrit :

Ne pas confondre « ne pas trouver que C# est [bien] plus agréable que l’Objective C » et « trouver que C# est moins agréable que l’Objective C ».

Je voulais dire que le C# fait l’unanimité dans chez ceux qui ont réellement bossé avec et avec d’autres ;-)

Glouk a écrit :

J’espère que tu n’es pas réellement convaincu qu’il y a un rapport entre ça et ce dont on parlait.

Bah en fait si " />

Glouk a écrit :

Tu n’as manifestement compris que le problème ne vient tellement pas des langages utilisés, mais bien des différences d’API entre les plateformes. Et je parle des vraies différences, celles qui font qu’on n’organise ni son code, ni son interface, ni même la logique de fonctionnement d’une partie de son application, de la même manière.

Le framework de haut niveau, dit « multiplateforme », qui gère réellement ces différences de façon magique, sans laisser de côté la moindre fonction spécifique à chacune des plateformes couvertes, on l’attend toujours… et on risque de l’attendre encore longtemps.

Et en C, la lib standard elle sert à quoi ? Ce serait pas une implémentation générique concue pour développer en C de la meme facon quelque soit les APIs de l’OS pour la gestion mémoire, file etc ?

Et je pense qu’un compilo C dépasse de loin la complexité de ce que je propose qui ressemble plus à reproduire le principe de la lib standard que le compilo.

On parle ici de code, la couche buisness comme on dit peut etre écrite une seule fois pour les 3 plate-formes sans problemes, ainsi que la couche data, seule la présentation pose probléme, mais entre recoder la couche de présentation et tout recoder il y a un monde quand meme.

Puis avec le HTML5 il doit bien y a moyen de proposer des solutions génériques sympa ^^

brazomyna

Le 19/09/2012 à 08h16

Sebdraluorg a écrit :

L’argument classique, mais naif !

A force de ‘là pas besoin de perf on fait du haut niveau, avec un max de xml’ on fini par avoir des environements qui sur-consomment pour rien !

Le “naïf ” (pour ne pas dire plus), c’est celui qui vit dans un monde où les ressources sont infinies (temps de développement, temps d’apprentissage, temps de test, temps de maintenance) et donc où la notion de coût n’a plus vraiment lieu d’être.

Le naïf c’est également celui qui confond vertu d’une solution technique en tant que telle et pertinence de ladite solution appliquée à tel ou tel exemple concret.

Après, je ne vais pas redire ce que j’ai déjà dit dans les comms il y a quelques jours ; mais sache qu’un couteau n’est pas mauvais en soi parce que potentiellement quelques uns peuvent être amenés à s’en servir pour tuer, et que ça ne constitue pas une raison suffisante pour les bannir de la surface du globe.

Sebdraluorg

Le 19/09/2012 à 09h37

brazomyna a écrit :

Le “naïf ” (pour ne pas dire plus), c’est celui qui vit dans un monde où les ressources sont infinies (temps de développement, temps d’apprentissage, temps de test, temps de maintenance) et donc où la notion de coût n’a plus vraiment lieu d’être.

Le naïf c’est également celui qui confond vertu d’une solution technique en tant que telle et pertinence de ladite solution appliquée à tel ou tel exemple concret.

Après, je ne vais pas redire ce que j’ai déjà dit dans les comms il y a quelques jours ; mais sache qu’un couteau n’est pas mauvais en soi parce que potentiellement quelques uns peuvent être amenés à s’en servir pour tuer, et que ça ne constitue pas une raison suffisante pour les bannir de la surface du globe.

Sauf que dans la pratique on constate plutôt une tendance à sortir le canon pour tuer la mouche… " />

brazomyna

Le 19/09/2012 à 10h26

Sebdraluorg a écrit :

Sauf que dans la pratique on constate plutôt une tendance à sortir le canon pour tuer la mouche… " />

Et ? le canon n’est pas mauvais pour autant, même si certains ont décidé de l’utiliser pour tuer une mouche.

D’autant qu’utiliser ledit canon peut parfaitement se justifier quand on prend l’ensemble du contexte en compte. Si tu es déjà équipé d’un canon, que même en ajoutant le coût du casque anti-bruit, le canonnier te coûte trois fois moins cher qu’un spécialiste en tapette à mouche, utiliser la tapette à mouche peut finir par ne plus être rentable.

Et dans ce cas là, utiliser le canon reste mieux que de laisser la mouche vivante.

Le vrai pragmatisme il est là: un projet et les choix technologiques qui y sont faits sont la résultante d’un ensemble de compromis divers et variés parmi lesquels l’influence du contexte est souvent prépondérante. Vouloir baser son choix sur l’unique approche technologique est réducteur et insuffisant.

Sebdraluorg

Le 19/09/2012 à 10h45

brazomyna a écrit :

Et ? le canon n’est pas mauvais pour autant, même si certains ont décidé de l’utiliser pour tuer une mouche.

D’autant qu’utiliser ledit canon peut parfaitement se justifier quand on prend l’ensemble du contexte en compte. Si tu es déjà équipé d’un canon, que même en ajoutant le coût du casque anti-bruit, le canonnier te coûte trois fois moins cher qu’un spécialiste en tapette à mouche, utiliser la tapette à mouche peut finir par ne plus être rentable.

Et dans ce cas là, utiliser le canon reste mieux que de laisser la mouche vivante.

Le vrai pragmatisme il est là: un projet et les choix technologiques qui y sont faits sont la résultante d’un ensemble de compromis divers et variés parmi lesquels l’influence du contexte est souvent prépondérante. Vouloir baser son choix sur l’unique approche technologique est réducteur et insuffisant.

Sauf que les mauvais choix sont les plus fréquents !

Et il n’y a pas que le cout de dev qui compte, le gaspillage c’est jamais bon, même si c’est le client qui va le subir !

Logiquement un dev doit faire ce qu’il y a de mieux pour son client, pas pour lui !

Utiliser du XML à la place du binaire juste parce qu’on a une classe qui va bien c’est juste de la connerie pure.

brazomyna

Le 19/09/2012 à 11h01

Sebdraluorg a écrit :

Sauf que les mauvais choix sont les plus fréquents !

Une belle stat sortie du chapeau, tendance “j’ai la Vérité, les autres sont majoritairement des incompétents, le monde (de l’IT) irait mieux si j’étais aux commandes”

" />

Logiquement un dev doit faire ce qu’il y a de mieux pour son client, pas pour lui ! Utiliser du XML à la place du binaire juste parce qu’on a une classe qui va bien c’est juste de la connerie pure.

Faire le mieux pour son client c’est AUSSI (mais pas seulement) lui proposer un produit à un prix acceptable tout en restant rentable.

Sinon pourquoi les gens achètent des Laguna alors qu’une A4 ou une BMW serie 3 est en tous points mieux finie et plus efficiente ?

Toi tu n’as toujours pas intégré la notion de compromis, alors je le refais:

au delà de la performance brute, le choix aura des conséquences sur nombre d’autres aspects: maintenabilité, coût de développement, interopérabilité, stabilité, facilité de déboguage, réutilisation de l’existant, etc…

Dire de façon arbitraire et universelle que le binaire est mieux que le XML parce que tu vas éviter de perdre x millisecondes de parsing et z% de conso CPU c’est encore et toujours d’une totale absurdité si tu ne prends pas TOUT LE RESTE en compte.

Sebdraluorg

Le 19/09/2012 à 11h34

brazomyna a écrit :

Une belle stat sortie du chapeau, tendance “j’ai la Vérité, les autres sont majoritairement des incompétents, le monde (de l’IT) irait mieux si j’étais aux commandes”

" />

Faire le mieux pour son client c’est AUSSI (mais pas seulement) lui proposer un produit à un prix acceptable tout en restant rentable.

Sinon pourquoi les gens achètent des Laguna alors qu’une A4 ou une BMW serie 3 est en tous points mieux finie et plus efficiente ?

Toi tu n’as toujours pas intégré la notion de compromis, alors je le refais:

au delà de la performance brute, le choix aura des conséquences sur nombre d’autres aspects: maintenabilité, coût de développement, interopérabilité, stabilité, facilité de déboguage, réutilisation de l’existant, etc…

Dire de façon arbitraire et universelle que le binaire est mieux que le XML parce que tu vas éviter de perdre x millisecondes de parsing et z% de conso CPU c’est encore et toujours d’une totale absurdité si tu ne prends pas TOUT LE RESTE en compte.

MDR, je vois assez d’usines à gaz et à des prix exorbitants pour pouvoir dire que clairement le monde du dev est de pire en pire niveau qualité/productivité/cout et ce malgré les languages haut-niveau sensés augmenter la productivité.

Alors tires-en les conclusions que tu veux, on est dans le siècle de l’incompétence et c’est dans l’informatique qu’on le constate le mieux !

Si tu n’as pas cette impression, change de métier ;-)

J’ai dit ‘il faut utiliser le binaire partout’ ? M’en rappel pas, par contre je me souviens avoir dit que dans beaucoup de cas on utilisais du XML sans vraies raisons !

Ta réaction me fait penser que c’est également ton cas " />

brazomyna

Le 19/09/2012 à 12h05

Sebdraluorg a écrit :

tires-en les conclusions que tu veux, on est dans le siècle de l’incompétence et c’est dans l’informatique qu’on le constate le mieux !

Si tu n’as pas cette impression, change de métier ;-)

brazomyna a écrit :

“j’ai la Vérité, les autres sont majoritairement des incompétents, le monde (de l’IT) irait mieux si j’étais aux commandes”

CQFD " />

Sebdraluorg

Le 19/09/2012 à 12h37

brazomyna a écrit :

CQFD " />

Ok donc pour toi, tous les chefs de projets sont des as et font toujours les choix les plus judicieux ?

Ca me fait marrer, on critique des boites comme Microsoft sur leurs choix, mais le petit chef de projet d’une simple petite boite de dev lui, tout ce qu’il fait c’est parfait !

Dire que tout le monde fait de la merde serait exagérer, mais nier qu’on voit de plus en plus du gros n’importe quoi montre que tu fais partie de ces devs qui ne pensent qu’à leur petit confort et au profit !

En partant de la meilleur volonté il est déjà difficile de faire les choix les plus judicieux ou les meilleurs compromis si tu préfères, mais quand la seule chose qui pèse dans la balance est le cout de développement le résultat a peu de chance d’être optimal !

brazomyna

Le 19/09/2012 à 12h47

" />

Glouk

Le 19/09/2012 à 13h16

rFlex a écrit :

Dommage, j’aurais été curieux de voir ton point de vue, malheureusement ton aggressivité m’indique dors et déjà que tu sembles être quelqu’un de non prêt à une discussion ouverte (je peux néanmoins me tromper).

Je n’ai en rien été agressif — sauf si tu considères comme aggressif de te faire remarquer que tu n’as toi non plus absolument pas argumenté, ce que je considère pourtant comme un minimum avant de demander aux autres de le faire.

J’aurais été également curieux de voir ton point de vue, plutôt que de lire que « ce n’est pas difficile à prouver ».

Glouk

Le 19/09/2012 à 14h00

-Gui- a écrit :

Bien sur que c’est impossible de faire du général et du spécifique en même temps, mais à un moment il faut choisir entre productivité et optimisation au poil.

Oui.

Cependant, ce dont je parlais ne concernait pas l’optimisation en termes de performances, mais bien la réalisation d’une interface utilisateur respectant chaque plateforme et donc ses utilisateurs. C’est pour cette partie du développement que je trouve regrettable de faire le choix de la productivité au détriment de l’utilisateur.

Minikea

Le 17/09/2012 à 14h57

Minecraft portable sous iOS? " />" />

maxxyme

Le 17/09/2012 à 15h05

2 remarques : sous Chrome 21 il semble y avoir un effet de bord du surlignage du code, i.e. des balises {code} {/code} en trop.

de 2, c’est pas plutôt getLengthWithJavaUtilList ? ^^

anonyme_2f3903e95215529534670e36d84faaa5

Le 17/09/2012 à 15h10

geekounet85 a écrit :

Minecraft portable sous iOS? " />" />

Apple" />

Teovald

Le 17/09/2012 à 15h11

C’est une très bonne chose que cet outil ne touche pas à l’interface. Il y a déjà trop de devs feignants qui ont une seule interface pour toutes les plateformes " />

Minikea

Le 17/09/2012 à 15h12

StackHeap a écrit :

Apple" />

ha ça existe déjà? ils ont du bien se faire chier à la réaliser celle là. y’a que des indé suédois pour faire ça! :P

anonyme_2f3903e95215529534670e36d84faaa5

Le 17/09/2012 à 15h15

geekounet85 a écrit :

ha ça existe déjà? ils ont du bien se faire chier à la réaliser celle là. y’a que des indé suédois pour faire ça! :P

Je pense oui vu qu’ils ont dû tout réécrire en C++, le portage sur Android a surement été moins douloureux " />

Mimoza Abonné

Le 17/09/2012 à 15h18

Au départ je me daisait “Pourquoi ne pas avoir fait l’inverse” afin de profiter de l’écosystème et des développeurs IOS. Mais en fait leur tactique est bien mieux, ils font en sorte que les dev ne s’embête plus a faire leur dev en Objective-C. Tout en Java (et donc Android) puis avec leur moulinette en Objective-C. Du coup les dev Java sont avantagé puisque leurs applis peuvent aussi bien tourner sur Android que IOS, donc un marché bien plus large et rentable pour eux. Au final le dev uniquement Objective-C devrait réduire " />

CryoGen

Le 17/09/2012 à 15h20

Teovald a écrit :

C’est une très bonne chose que cet outil ne touche pas à l’interface. Il y a déjà trop de devs feignants qui ont une seule interface pour toutes les plateformes " />

Tu parles de microsoft et Windows 8 ? " />

Teovald

Le 17/09/2012 à 15h32

CryoGen a écrit :

Tu parles de microsoft et Windows 8 ? " />

non, quoi que…. :-)

sérieusement non, je ne pense pas que Microsoft ait fait le choix de l’interface unique (ou en tout cas très proche) par simple fainéantise, mais pour créer une gamme cohérente. Après je n’ai pas dis que Metro était exempt de défauts, loin de là.

Non, je voulais parler des devs qui sont incapables de s’adapter aux différentes plateformes & qui ont un design pour toutes.

Si on regarde une app bien désignée pour Android & iOS, leurs interfaces ont de très grosses différences.

On va bien sûr retrouver le même squelette d’app entre les 2 plateformes & globalement la même architecture des vues quand on porte d’un OS à l’autre; mais avec aussi de grosses différences.

Cette page illustre bien cela.

fullsun

Le 17/09/2012 à 15h32

Sous Java, pour des soucis de performance, le ramasse-miette est quasiment désactivé…

Glouk

Le 19/09/2012 à 14h09

Sebdraluorg a écrit :

Je voulais dire que le C# fait l’unanimité dans chez ceux qui ont réellement bossé avec et avec d’autres ;-)

Il fait l’unanimité en tant que langage (et framework associé) agréable à utiliser.

Pas nécessairement en tant que langage plus agréable à utiliser que tous les autres. La nuance est de taille.

Bah en fait si " />

Triste.

On parle ici de code, la couche buisness comme on dit peut etre écrite une seule fois pour les 3 plate-formes sans problemes, ainsi que la couche data, seule la présentation pose probléme, mais entre recoder la couche de présentation et tout recoder il y a un monde quand meme.

Désolé, je n’avais pas compris que tu ne te plaçais qu’au niveau du modèle. Depuis le début, je pensais que tu prônais l’usage d’une surcouche aussi pour la partie interface utilisateur (vues et contrôleurs). C’est cette idée que je trouve horrible.

Pour le modèle, en revanche, oui il est tout à fait logique d’en faire une version aussi indépendante des plateformes que possible (c’est pour ça que ça finit souvent en C++). Avec un bémol toutefois : même à ce niveau, les divers OS peuvent proposer des possibilités spécifiques qu’il est dans certains cas intéressant d’exploiter afin de proposer la meilleure appli possible. Mais c’est bien moins flagrant et fréquent que pour l’interface, et donc le choix d’une approche multiplateforme peut tout à fait se justifier (sans être systématique).

Puis avec le HTML5 il doit bien y a moyen de proposer des solutions génériques sympa ^^

Ben voilà, tu remets ça pour ce qui est de l’interface !

Non, non et non. Pas de solution générique pour ça !

Sebdraluorg

Le 19/09/2012 à 14h29

Glouk a écrit :

Ben voilà, tu remets ça pour ce qui est de l’interface !

Non, non et non. Pas de solution générique pour ça !

" /> On est d’accord, juste que c’est une possibilité bien que j’éviterai le HTML5 aussi longtemps que possible personnellement…

brazomyna

Le 18/09/2012 à 07h03

Mais si l’écosystème attire les développeurs et les clients, il trace des lignes dans le sable et impose ses propres règles. C’est notamment le cas des langages utilisés pour la création des applications. Ainsi, plus l’attraction de l’App Store s’exerce sur les développeurs, plus l’Objective-C croit en popularité.

Il serait pertinent de ne pas oublier de mentionner que restreindre ainsi les appStores à certaines technologies précises n’est pas non plus une fatalité ou une limitation technique, mais bel et bien un choix stratégique des acteurs. Cela afin d’enfermer les développeurs dans tel ou tel écosystème (ou de populariser son petit langage maison, ce qui revient grosso modo au même).

C’est aussi une pratique qu’Apple a introduite dans le monde de l’IT avec le succès de son iPhone. Et autant il est évident que ça leur est profitable, autant je suis beaucoup, beaucoup moins sûr que ça le soit pour le client final, notamment à long terme.

Gatchan

Le 18/09/2012 à 07h35

Préférant de loin coder en C# et .NET, il existe aussi le Framework MVVMCross qui permet facilement de faire du multiplateforme :

le code “métier” (toute la logique, exploitation des données) est écrit d’un côté

les interfaces utilisateurs sont spécifiques à chaque plateforme (iOS, WP7/8, Android), pour respecter la philosophie de chaque.

gargaml

Le 18/09/2012 à 07h53

Ce qui est dommage c’est que cette hétérogénéité des plateformes ainsi que des langages aurait pu ouvrir la voie au HTML5…

J’attends de voir ce que firefox OS donnera comme résultat.

psn00ps

Le 18/09/2012 à 07h58

Oungawak a écrit :

void f1(int int1, int int2) { return int1 + int2; }

Sebdraluorg a écrit :

" />

Bien vu " />

Anonyme

Le 18/09/2012 à 10h20

tiens, on commence a se rendre compte des betises faites…..

allez un convertisseur c++ vers le c serait le bienvenu aussi qu’on puisse enfin se débarasser du compilateur de fou et du runtime de dingue du c++

oposs

Le 18/09/2012 à 10h32

sylware a écrit :

tiens, on commence a se rendre compte des betises faites…..

allez un convertisseur c++ vers le c serait le bienvenu aussi qu’on puisse enfin se débarasser du compilateur de fou et du runtime de dingue du c++

Quel runtime de dingue? En C++ tu fais ce que tu veux, tu peux meme faire du code bien reutilisable et entierement resolu a la compilation.

Sebdraluorg

Le 18/09/2012 à 11h00

exactitudedotcom a écrit :

heuuuuuuu sauf que développer sur une plateforme ce n’est pas qu’une question de langage…mais aussi d’apis.

Bah la plateforme pourrait proposer des classes pour utiliser les apis

C’est comme si tu me disais on peut pas faire un éditeur C générique car les machines cibles n’ont pas tous les mêmes jeux d’instructions…

brazomyna

Le 18/09/2012 à 11h02

sylware a écrit :

tiens, on commence a se rendre compte des betises faites…..

Lesquelles ?

Proposer des langages de plus haut niveau (sans interdire pour autant ceux de plus bas niveau) permettant de gagner en qualité, maintenabilité, évolutivité, efficience et réutilisation de l’existant quand la recherche de la perf ultime n’est pas un impératif fort pour les besoins du projet ?

Bref, tu as décidé de prendre la position de l’ayatollah du bas niveau qui croit qu’il n’y a qu’une solution parfaite pour tous les besoins. " />

levhieu

Le 18/09/2012 à 11h54

brazomyna a écrit :

…

Il serait pertinent de ne pas oublier de mentionner que restreindre ainsi les appStores à certaines technologies précises n’est pas non plus une fatalité ou une limitation technique, mais bel et bien un choix stratégique des acteurs. Cela afin d’enfermer les développeurs dans tel ou tel écosystème (ou de populariser son petit langage maison, ce qui revient grosso modo au même).

…

Java un langage maison de google ?

Larry E. va pas être d’accord." />

Sebdraluorg

Le 18/09/2012 à 12h57

brazomyna a écrit :

Lesquelles ?

Proposer des langages de plus haut niveau (sans interdire pour autant ceux de plus bas niveau) permettant de gagner en qualité, maintenabilité, évolutivité, efficience et réutilisation de l’existant quand la recherche de la perf ultime n’est pas un impératif fort pour les besoins du projet ?

Bref, tu as décidé de prendre la position de l’ayatollah du bas niveau qui croit qu’il n’y a qu’une solution parfaite pour tous les besoins. " />

L’argument classic, mais naif !

A force de ‘là pas besoin de perf on fait du haut niveau, avec un max de xml’ on fini par avoir des environements qui sur-consomment pour rien !

Entre HTML, XML et JavaScript et tout ça géré par des engine haut niveau tu te rends compte du gaspillage sur une plate-forme ?

Hormis dans l’embarqué, il est rare qu’il n’y ait qu’une seule appli qui tourne sur une machine, donc dire ‘moi la ptite appli elle a pas besoin de perf donc je fais au plus rapide’ est débile, l’utilisateur final de l’appli a peut être 50 appli du genre à faire tourner.

Bon si ce n’était que ça ça irait encore, mais avant (en C/C++) on disait pas besoin d’écrire du code optimisé sauf certains cas particuliers, mais maintenant on se dit ça dans des languages haut-niveau.

Tout ça l’un dans l’autre l’informatique actuelle est bien une belle connerie !

Glouk

Le 18/09/2012 à 13h04

Sebdraluorg a écrit :

Bah la plateforme pourrait proposer des classes pour utiliser les apis

Sauf que ça, c’est loin d’être facile à partir du moment où les API concernées ne sont pas très proches l’une de l’autre. Et une fois que c’est fait, ça ne donne généralement pas un bon résultat, notamment en termes de suivi de l’évolution des API de chaque plateforme.

Bref, c’est vraiment juste un rêve de développeur flemmard pensant plus à son temps de développement qu’au respect de ses utilisateurs.

Glouk

Le 18/09/2012 à 13h05

rFlex a écrit :

Tu développes en C# (quand même plus agréable que le Java et encore plus que l’Objective-C)

Euh… non.

Sebdraluorg

Le 18/09/2012 à 13h16

Glouk a écrit :

Euh… non.

Euh si, perso j’ai jamais croisé une personne ayant pratiqué (réellement) le C# et le trouver moins confortable qu’un autre ! Pourtant j’ai des barbus dans mes collègues !

Glouk a écrit :

Sauf que ça, c’est loin d’être facile à partir du moment où les API concernées ne sont pas très proches l’une de l’autre. Et une fois que c’est fait, ça ne donne généralement pas un bon résultat, notamment en termes de suivi de l’évolution des API de chaque plateforme.

Bref, c’est vraiment juste un rêve de développeur flemmard pensant plus à son temps de développement qu’au respect de ses utilisateurs.

Euh dis ça à la communauté C, dis leurs que ce sont de fainéants et qu’ils n’ont qu’à se taper de l’asm pour chaque machine cible !

Puis j’ai pas dis que l’éditeur devait être fait avec les pieds hein ! Si c’est fait proprement ça marchera nickel, et si tu pars d’un de tes langages pour le porter vers un autre il faut être vachement tarte pour faire ça de travers :s

rFlex

Le 18/09/2012 à 16h15

Glouk a écrit :

Euh… non.

Malheureusement, ce n’est plus vraiment quelque chose de difficile à prouver, et ce n’est pas ton argumentaire impressionnant qui changera quelque chose.