 |
Pierre, à qui s'adresse ce livre ?
Ce livre s'adresse aux développeurs confirmés qui ont envie de se lancer dans Objective-C, sans perdre de temps avec des documentations pour débutants. Les questions que l'on se pose quand on sait déjà programmer sont souvent assez pointues ; pour prendre un exemple bateau, on ne se demande pas ce qu'est une méthode virtuelle, on veut plutôt savoir comment elles sont implémentées, quelles sont leurs limites, comment elles interfèrent avec la surcharge, etc. Un autre point très important selon moi est aussi de séparer clairement le langage Objective-C et les APIs (Application Programming Interface) d'Apple. Du coup, le livre se restreint volontairement pour aller à l'essentiel. Parler d'XCode ou Cocoa en détails doit à mon sens être le sujet d'un autre livre (et là il en existe beaucoup).
Peut-on vraiment l'appréhender sans avoir jamais fait de développement ?
Je ne crois pas ! En tous cas ce n'est pas le but. Une des difficultés de l'écriture d'un tel ouvrage est de trouver le juste équilibre entre la concision et la clarté des explications. Même en partant du principe que le lecteur a de bonnes connaissances, on ne pas peut pas faire comme si tout était évident. Et malgré tout, il faut honorer ses compétences en ne détaillant pas tout.
Quelle est selon toi la plus grosse difficulté à aborder en Objective-C, lorsqu'on vient du monde C++ ou du monde Java/C# ?
Pour moi, la plus grosse difficulté c'est "changer beaucoup d'habitudes d'un coup". Le cas typique serait un développeur Windows (en C#, Java, ou C++) qui veut essayer Objective-C. Il doit passer à MacOS X, découvrir l'environnement de développement XCode, comprendre comment sont organisées les APIs Apple, découvrir la doc, apprendre un nouveau langage... Malheureusement, il faut du temps pour se faire à l'idée de programmer différemment ; on a parfois l'impression de redevenir un débutant. Il est facile aussi de se dire "c'est nul" parce que nos habitudes ne fonctionnent plus. Pour en revenir au langage lui-même, la gestion mémoire en Objective-C, malgré toutes ses qualités, semble être souvent un point délicat pour les nouveaux arrivants. Il faut être rigoureux avec les objets manipulés pas les APIs pour ne pas faire n'importe quoi. Il y a aussi les deux écoles qui s'opposent : Garbage Collector ou pas Garbage Collector, les deux étant possibles en Objective-C.
Je dirais aussi qu'Objective-C, par nature, est un langage très permissif. Il faut donc un peu d'expérience et de la rigueur pour écrire du code
élégant.
 |
C'est flatteur, mais je n'irais pas jusque là ! Je pense que mon livre ne suffit pas pour apprendre le développement Mac/iPad/iPhone, car il faut aussi se familiariser avec les "bonnes pratiques" de Cocoa. La documentation d'Apple est très bien faite, mais ne peut remplacer un ouvrage didactique pour faire ses premières armes. Je conseille habituellement "Cocoa par la pratique" de Aaron Hillegas. Cela dit, une fois qu'on est à l'aise, on ne peut qu'apprécier le travail d'Apple sur sa documentation, car elle est est très bien organisée.
Une rumeur récente laissait entendre que l'Objective-C pourrait se voir adjoindre une machine virtuelle. Est-ce vraiment crédible selon toi ?
Autant l'abandon d'Objective-C (une autre rumeur, éphémère) semblait totalement surréaliste, autant la machine virtuelle me paraît possible. Microsoft le fait depuis longtemps avec .NET et je pense qu'Apple a dû y réfléchir. Même en ayant abandonné le PowerPC et bientôt le x86 32 bits, il reste à gérer le x86_64, les ARM de l'iPod/iPad, et les processeurs à venir. La machine virtuelle permettrait de maintenir une rétro-compatibilité, tout en garantissant des optimisations à l'exécution en fonction de l'architecture sur laquelle le code est lancé. Plus besoin donc de générer autant de binaires que d'architectures possibles. Malgré tout, certains domaines ne peuvent se passer d'utiliser intelligemment les jeux d'instructions avancés des processeurs ; il faudrait donc garder des portes vers des modules aux optimisations spécifiques, ce qui est contradictoire pour la portabilité du code. Et de plus, et on voit bien le problème avec .NET, la MV (machine virtuelle) évolue aussi, et un code peut être inutilisable sur une MV trop ancienne. Le développeur se retrouve donc avec une problématique un peu similaire à celle de l'architecture ou de la version de l'OS : quelle version de MV dois-je viser ? Comment être sûr qu'elle sera installée chez le client ? Si Apple prend cette direction, ils auront certainement à c¦ur d'éviter une trop grande hétérogénéité des configurations possibles.
Disponibilités
On remercie Pierre, de nous avoir accordé quelques minutes pour cette interview. Vous pouvez acheter son livre :
Chez EyrollesSur AmazonA la Fnac
