Clair Xcode est à la fois génial et navrant ...
Les plus :
le storyboard,
Automation,
Les testscase.
Les moins:
Son instabilité,
L'intégration des outils de gestion de version.

@ tleveque

Je n'ai pas l'impression que tu aies bien saisi la différence fondamentale qu'il y a entre envoyer un message et appeler une méthode...

@ShowMeHowToLive :
tout à fait, le SDK Android est monstrueusement buggué et lent

Est-ce que l'auteur de cette "news" pourrait mettre un lien, une source quelque chose qui illustrerait l'affirmation du titre " Xcode 4 : le ras-le-bol des développeurs".

@ daito

Leur développeur iOS a probablement eu une mauvaise journée… :D

@tleveque :
en ce qui concerne l'envoi de messages, j'y vois deux gros avantages par rapport à la syntaxe Java que tu décris :
- ça passe à la compilation et ça pemet d'envoyer un message valide à un objet dont tu ne connais pas le type, sans caster
- c'est très verbeux, et au contraire de ce que tu dis, ça permet de lire un code très clairement si les noms des méthodes sont bien construits, voire de se passer de la doc.

Entre un viewController.alloc().init("uneString", "uneString"), et un [[viewController alloc] initWithNibName:@"uneString" andNavigationTitle:@"uneString"], je pense que du point de vue de quelqu'un qui n'y connaît rien, il aura beaucoup plus de facilité à savoir ce que décrivent les deux Strings en Obj-C.

Après comme je l'ai dit plus haut c'est une histoire de goûts.

"ça passe à la compilation et ça pemet d'envoyer un message valide à un objet dont tu ne connais pas le type, sans caster"

Pour le coup c'est une grande force du Java, le fait d'avoir un typage fort.

@ daito

MacG qui donne ses sources ? Tu crois rêver là ;)

@ Lemmings

Le fait de pouvoir envoyer un message à un objet qui ne peut pas y répondre forcément est une grande force, car cela permet le "message forwarding", et ainsi d'implémenter certains design patterns de façon fort élégante (par exemple le design pattern observer).

Pour travailler plusieurs heures par jour sur XCode 4, je confirme qu'il crash souvent :(

@ tleveque

Justement tu ne déclares pas de variable, mais un pointeur vers l'objet. C'est justement bien de garder la différence pour aussi des fois parler de pointeur de pointeur. Si on commence à être trop laxiste en C ça devient le bordel. Surtout qu'on peut mélanger le bas niveau avec le haut niveau. Ce n'est pas parce que Java ne fait pas appel au concept de pointeur que c'est bien tout le temps. Si on veut faire quelque-chose d'un peu bas niveau, on est coincé.

Pour les methods, si tu as trop de [] qui s'entre-mêlent c'est que tu écris mal. Mais je ne vois pas en quoi ton exemple est plus clair avec tout sur la même ligne et à la queue-leu-leu. Je suppose d'ailleurs qu'il y a moyen de clarifier cet exemple en Java. J'ai personnellement rarement plus de deux ou trois [] qui s'imbriquent. Mais évidemment si on est un fou du nesting juste pour épargner des lignes de code, forcément tout devient illisible. Et on peut rendre illisible n'importe quel code écrit dans n'importe quel langage.

Sinon, tu viens de commencer à apprendre l'Objective-C. Forcément tu te concentres sur la syntaxe. Cela m'étonnerait que tu ne te concentrais pas sur la syntaxe au début de ton apprentissage du Java.

EDIT: Tu peux appeler certaines methods sans paramètres avec des . Va lire la doc sur Objective-C 2.0.

@Lonesome Boy : c'est une des approche philosophique de la programmation, l'autre approche qui découle du typage fort c'est d'obliger envoyer aux méthodes des éléments qu'elles peuvent interpréter et traiter de la manière la plus optimale. Et créer autant de méthodes optimales nécessaires pour traiter tous les cas de figures.

Dans le cadre d'un langage tel que le java, ce typage fort permet d'obtenir un code souvent bien plus optimisé ce qui a une certaine incidence après lors de son exécution sur une JVM. Chose qui a un peu moins d'intérêt dans un langage tel que l'objective-c où le compilateur pourra potentiellement refaire ce travail d'optimisation.

Depuis 8 mois je travaille sur une version Android d'une appli iOS en utilisant exclusivement la version gratuite de IntelliJ IDEA. Je dois dire que je suis bluffé par la qualité de cette IDE, passé le choc initial de la différence d'aspect avec Xcode. Il est certain que Xcode est plus joli et plus "Mac" mais au fil des mois j'ai développé une confiance absolue dans les capacités de l'équipes de JetBrains à faire un produit solide et puissant.

Tellement bien en fait que j'ai acheté AppCode, leur nouvelle IDE pour développer pour iOS et Mac OS X. Cette IDE a commencé modestement, la nouvelle version 1.5 commence à être vraiment super avec des outils pour travailler sur le code qui n'ont jamais fonctionné correctement sur Xcode. Seuls points noirs, l'interface avec le debugger est encore un peu lente, et il n'y a pas d'éditeur intégré pour les interfaces utilisateurs. Une partie du travail doit encore être fait avec Xcode.

Néanmoins, je recommande chaudement cette IDE qui n'a certes pas les qualités d'UI de Xcode, mais fonctionnellement est vraiment riche et puissante. Pas gratuite, certes, mais c'est un excellent outil.

@tleveque :

Le changement de langage est toujours délicat. Il n'y a pas que la syntaxe qui change mais aussi la « philosophie » du langage. Et cette dernière prend beaucoup de temps à cerner surtout si l'on a une expérience conséquente dans un autre langage.