je développais sur le c++(QT framework), mais apres le boom des idevices, je me suis retrouver (sans le vouloir) developper avec l'objective-c.le langage lui meme n'est plus ni moin performant que le c++ mais les frameworks qui vont avec ( coreanimation, quartz2D... ) sont vraiment le mieux de se qui se fait, apple a vraiment fait un tres bon boulot. apres j'ai compris pourquoi une meme app prend moins de temps à develpper sur ios que sur android par exemple.

@RedMak [05/07/2012 15:27] 20 ans de travail sur NeXT/Openstep/Cocoa :)

C'est normal que l'objective-c et le java monte c'est le langage de l'iPhone et d'android.

@havox79 : Le java descends...

C'est vrai qu'Objective-C + Cocoa sont excellents. Nombre de choses se font plus vite que sur d'autres plate-formes. De plus Apple depuis quelques années a enfin les moyens avec LLVM de moderniser Objective-C ce qui lui ouvre les portes d'un avenir radieux. La seule chose qui manque vraiment c'est un moyen plus performant d'accéder et d'interroger des bases de données (et qu'on me parle pas de CoreData). Le rêve serait d'avoir un équivalent à LINQ de Microsoft, mais j'ai pas l'impression que ça intéresse beaucoup Apple.

@BotteChouette56 : dsl mal lu, mais de toute façon ça n'a pas de rapport avec l'utilisation du langage si j'ai bien compris donc... Oubliez ce commentaire xD

Je pense que la montée de l'Objective-C est une mode. Ce type de langage, limité à un écosystème, ne peut pas se maintenir de façon pérenne. Typiquement, ce serait une hérésie qu'une université ou école donne des cours d'Objective-C au détriment du C, C++ et surtout Java.

@ yoa Il y a bien des universités qui enseignaient le C++ en conjonction avec les MFC (framework catastrophique conçu par Microsoft) ou qui actuellement enseignent C# et .NET. Quelle différence dans ce cas ? Quand à apprendre Java comme seul langage (si si, ça se fait) c'est former des éclopés qui face à leur premier pointeur vont rien comprendre.

@ oomu : 25 ans. ;-)

@yoa, dommage les grandes universités américaines s'y sont mises (probablement moins sous la coupe de Microsoft qu'ici). Et tu trouves certains cours sur iTunes U. Ensuite rien ne t'empêche de faire de l'Objective-C sous windows et sous Unix en gcc avec les librairies standards ...

@treizep, Je ne connais pas beaucoup d'université qui apprenne le C# et .NET. La majorité sont des écoles d'ingénieurs avec un partenariat Microsoft. L'aspect éducatif n'est donc pas la seule composante... Tu l'admettras. Après, je te rejoins qu'apprendre seulement un langage objet de haut niveau est une mauvaise méthode. Quoiqu'il en soit Objectif-C n'a pas rééllement sa place dans l'enseignement dans son état actuel.

@ yoa S'il ne l'a pas actuellement quand l'aura t'il ? On ne peut pas ignorer qu'Objective-C dispose de caractéristiques intéressantes qui peuvent ouvrir de nouveaux horizons sur des façons différentes de concevoir un programme. Rien que pour ça il serait bon de l'enseigner. De plus je ne trouve pas satisfaisant qu'en France on ait toujours quelques trains de retard sur ce qui se fait aux USA. Il faudra bien un jour prendre le problème à bras-le-corps pour espérer un jour développer le secteur de l'informatique en France en dehors des ornières noirâtres des SSII et des banques/assurances. J'exagère probablement, mais aux USA en tout cas, le secteur de l'informatique est bien plus dynamique qu'en France et je pense simplement que c'est aussi grâce à leur plus grande ouverture d'esprit.

Dans l'école où je bosse, je me suis battu pour mettre l'accent sur la méthode de travail, et non le langage lui-même qui doit être adapté au problème à résoudre, et aussi à l'environnement de son utilisation. Malheureusement, les lobbies aidant, c'est Java qui a gagné, et qui sera enseigné par les mêmes gens qui enseignaient le C avec gets() et scanf(). J'ai hâte de voir ce que ça donne ^^

@ericb2 moi a l'IUT (à l'époque) j'ai eu du bol c’était C++ donc gestion de la mémoire et tout ce qui va avec, pas de garbadge (histoire de coder comme un cochon). Je suis ok a 100% ce qui importe c'est la logique de prog et non le langage, sinon c'est qu'on a pas encore atteint la maturité de faire abstraction du langage ! Le langage comme pour l'homme reste un support pour exprimer l'idée et non l'inverse ;) Bon au final dev sur iPhone et objectiv-C c'est pas mal non plus, sauf que gestion mémoire c'est pas toujours simple a comprendre au début !

@treizep 200% ok la mémoire et java c'est quoi ? LoL

@treizep, Je ne suis pas sur que les compétences des ingénieurs IT Américain soient si supérieurs à celle des français, surtout ramené au coût d'un étudiant. Je pense plus un problème structurelle de notre économie que un réel problème d'éducation dans le secteur IT.

@yoa Effectivement, mais je pense quand même qu'en poussant un peu du coté de l'éducation on pourrait aussi espérer changer les choses.

@ CKJBeOS "Le langage comme pour l'homme reste un support pour exprimer l'idée et non l'inverse ;)" Certaines idées ne peuvent être exprimées en l'absence des mots nécessaires. Ce n'est pas pour rien qu'on dénature la signification de certains mots à notre époque. Voir même qu'on exprime des idées avec d'autres mots de sorte d'en tirer un avantage. De même certains concepts culturels sont très complexes à traduire dans d'autres langues. Et je pense qu'il en est aussi de même pour les langages de programmation. C'est pour ça qu'il faut en apprendre plusieurs car ils ouvrent chacun de nouveaux horizons.

Ca fait 2 fois que je vois ce tableau bizarre sur votre site... la première, j'étais étonné de voir le Logo devant le Pascal (avec des gros up up up dans la case Delta). Aujourd'hui même plus là. Que vaut vraiment ce tableau ? C'est sérieux où c'est juste pour meubler ?

[quote]La seule chose qui manque vraiment c'est un moyen plus performant d'accéder et d'interroger des bases de données (et qu'on me parle pas de CoreData). Le rêve serait d'avoir un équivalent à LINQ de Microsoft, mais j'ai pas l'impression que ça intéresse beaucoup Apple.[/quote] 1. Core data est très performant et puissant. 2. Pour accéder à une BDD remote, le standard c'est un web service REST. 3. LINQ est un équivalent de NSPredicat sur iOS qui existe depuis 2006 4. Core data + Incremental Stores apporte encore une solution plus élégante. Mais pour connaitre ça, il faut savoir de quoi on parle ce qui n'est pas ton cas.

Là ou je suis étonné c'est que le javascript, poussé par HTML5 ne soit pas plus haut et ne monte pas

PHP en déclin. Mais il est remplacé par quoi ?

Kuntz "Mais pour connaitre ça, il faut savoir de quoi on parle ce qui n'est pas ton cas." Tu peux rajouter "moi je sait de quoi je parle nanananèèèère"

mouais, on mélange les langages, mais bien sûr !!! tous n'ont pas la même utilité perl, javascript, c++, ada, pourquoi pas aussi shell script, ou LaTeX, n'importe quoi et y a pas "clipper", vous connaissez pas ? et l'assembleur ? je ne vois pas l'intérêt de cet article au final, mis à part d'ouvrir un débat stérile

1. Core data est très performant et puissant. Core data fonctionne uniquement avec une "base de données" sqlite ou sur des données XML. Sqlite ça veut dire de multiples lecteurs mais qu'un seul écrivain simultané par base de données. Mais il me semble bien, si cela n'a pas changé récemment, que CoreData ne permets qu'un accès mono-utilisateur. J'imagine Amazon utiliser ça ou même Apple pour leur magasin. Ils seraient obligés de mettre une liste d'attente pour les commandes. Chaque client devrait attendre son tour pour passer une commande. Efficace... hum... Très puissant, certes, quand on cherche des arguments pour défendre à tout prix son OS préféré. LINQ accède indifféremment à des bases de données mySQL, Oracle, SQLServer et j'en passe tout plein d'autres avec de multiples lecteurs et écrivains ainsi que sur des données XML. J'espère que tu n'oseras pas comparer "les performances et la puissance" de sqlite avec Oracle par exemple ? Donc avec LINQ et les bases de données en question plusieurs personnes pourraient en même temps effectuer une commande sur le site d'Amazon. Bienvenue dans le monde réel Néo. 2. Pour accéder à une BDD remote, le standard c'est un web service REST. Moui.. et ? La BDD remote ne sera probablement pas sous sqlite de toute façon... on aura certainement du mySQL ou plus puissant derrière.

3. LINQ est un équivalent de NSPredicat sur iOS qui existe depuis 2006 Exemple en LINQ : Person.Select(@"Name").OrderAsc(@"Name").Where(@"Id").EqualTo(1).And(@"Id").NotEqualTo(2).Load Equivalent avec NSPredicat : NSArray *person = /* le tableau de personnes */ NSPredicate *pred = [NSPredicate predicateWithFormat:@"Id = 1 AND Id != 2"]; NSSortDescriptor *byName = [[[NSSortDescriptor alloc] initWithKey:@"Name" ascending:YES] autorelease]; NSArray *descriptors = [NSArray arrayWithObject:byName]; NSArray *matches = [people filteredArrayUsingPredicate:pred]; NSArray *sortedMatches = [matches sortedArrayUsingDescriptors:descriptors]; NSArray *justNames = [sortedMatches valueForKey:@"Name"]; En étant payé à la ligne je comprend qu'on puisse préférer NSPredicat. Et je ne parle même pas de performance, malheureusement je n'ai pas trouvé de comparatif mais je n'ai pas de doutes que LINQ gagne haut la main. 4. Core data + Incremental Stores apporte encore une solution plus élégante. Dixit Apple : An incremental store is a Core Data store that allows you piecemeal access to its content. This means that you can bring into memory just the data your program needs to operate, rather than the entire contents of the store. An incremental store is therefore much more efficient than an atomic store which must bring all the data into memory (see Atomic Store Programming Topics). Et je lis qu'il à fallut attendre le 12/10/2011 pour avoir ceci sous CoreData soit 4 ans après LINQ à vue de nez. Je te cite : "Mais pour connaitre ça, il faut savoir de quoi on parle ce qui n'est pas ton cas."

"[Francis Kuntz] la petite bête qui [b]va s'enfoncer, s'enfoncer[/b] !" lol, j'ai pas pu m'en empêcher ! (hin hin hin)

Je rappelle que les gens qui cherchent des infos sur PHP vont sur Php.net et ne passent pas par google. Ce simple exemple invalide l'utilité et la fiabilité du boudin. Next.

Rien ne vaut l'assembleur et le C, langages des OS et de l'embarqué.

@ treizep : « Moui.. et ? La BDD remote ne sera probablement pas sous sqlite de toute façon... on aura certainement du mySQL ou plus puissant derrière. » Moui… et ? Puisqu’il parle d’un cas où on ne va pas y accéder directement, à la base de données (ce qui paraît logique dans bien des cas), qu’est-ce que ça peut bien nous faire de savoir laquelle est utilisée ?

@BeePotato Pourquoi en parler alors puisque ce n'était pas le sujet ? C'est une façon de détourner l'attention de dire qu'on s'en moque dans le cas d'un accès à une BDD par le biais de REST (dans le même genre : je pardonne les pietres performances de ma voiture car je prends le train...). Le hors sujet vient de là et c'était (peut être une mauvaise manière) de le faire remarquer.

@ treizep : Désolé, je ne comprends pas bien ta dernière réponse. Ce n’était pas une histoire pour détourner l’attention : il faisait juste remarquer que, pour accéder à une base de données en ligne, on n’utiliserait pas Core Data, qui n’est pas prévu pour ça. Le hors sujet, désolé, mais c’était plutôt de venir parler d’Amazon ne pouvant pas utiliser Core Data pour sa base de données alors qu’on sait parfaitement que Core Data n’est pas destiné à cet usage. Reprocher à cette bibliothèque de se limiter à un seul accès à la fois en écriture alors que son usage est justement l’accès à du stockage local, non partagé, spécifique à chaque application, c’est un peu bizarre — c’est tout de même lui reprocher de ne faire que ce qu’il annonce qu’il fait. Le reproche, c’est quoi ? De ne pas pouvoir utiliser Core Data pour écrire un serveur de BDD ? Boarf… À noter en revanche : je n’ai rien contre LINQ, qui est en effet un petit truc pas mal du tout.

Ah, au fait… difficile de résister à la tentation. :-) L’équivalent de ta ligne LINQ, c’est plutôt ça : [[[person filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"Id = 1 AND Id != 2"]] valueForKey:@"Name"] sortedArrayUsingSelector:@selector(caseInsensitiveCompare:)]; Et ça tient donc aussi en une ligne (« évidemment », serait-on tenté de dire). Mais on peut aussi faire un effort pour se convaincre qu’on n’ira pas en enfer pour avoir écrit plus d’une ligne de code. ;-) Et il sera alors un peu plus lisible de répartir ça en deux lignes, en séparant la création du prédicat de son utilisation.

Utilisé pendant 5 ans sous windows et unix, je l'avais compilé sous OSX pour la partie server C/C++ http://www.sqlapi.com Maintenant une version précompilée existe pour OSX sur leur site. Très bonne API même si bas niveau. Ce n'est pas de l'ObjC ... je sais mais c'est déjà ça ;-)

@BeePotato Le problème est le suivant : quel que soit la façon d'accéder à la base de données il n'y a rien du tout qui permette de s'y connecter de manière transparente et de l’interroger de façon homogène sans écrire du code spécifique à chaque moteur de base de données et c'est bien une grosse lacune de Cocoa. La chose qui s'en rapproche le plus c'est malheureusement CoreData, sauf que CoreData est trop limité. L'API CoreData pourrait très bien être étendue pour le faire, sauf que ça n'intéresse pas Apple. D'où ma première remarque : "La seule chose qui manque vraiment c'est un moyen plus performant d'accéder et d'interroger des bases de données (et qu'on me parle pas de CoreData). Le rêve serait d'avoir un équivalent à LINQ de Microsoft, mais j'ai pas l'impression que ça intéresse beaucoup Apple." Ensuite on peut tourner autour du pot pendant 3 ans mais le fait est là : le vide règne. Pour l'exemple, on peut faire plus court comme tu l'as fait effectivement (en perdant en lisibilité cependant) ;) J'aurais dû y faire attention. Cependant on peut faire des choses très complexes avec LINQ comme des jointures entre tables de deux bases de données par exemple. Et là je n'imagine même pas le nombre de lignes de code qu'il faudrait écrire pour faire la même chose en Cocoa (en sachant que l'accès à la base de données n'est pas effectué par Cocoa). Alors oui je compare des torchons à des serviettes, mais il n'y a rien d'autre à comparer malheureusement.

Apple a EOF dans sa base de code, pourquoi ne font il pas revivre cette API ... ??? Mystère, sans doute que ça ne se justifie pas pour le moment. http://developer.apple.com/legacy/mac/library/#documentation/WebObjects/Enterprise_Objects/Introduction/Introduction.html#//apple_ref/doc/uid/TP30001011-CH202-DontLinkElementID_138 Doc de la version java, dérivée de la techno ObjC originale :-) En fait CoreData est une techno qui est un dérivé de celle ci... simplifiée

@ treizep : « Le problème est le suivant : quel que soit la façon d'accéder à la base de données il n'y a rien du tout qui permette de s'y connecter de manière transparente et de l’interroger de façon homogène sans écrire du code spécifique à chaque moteur de base de données et c'est bien une grosse lacune de Cocoa. » Une lacune, oui. Grosse, c’est subjectif. ;-) Je veux dire par là que ça ne manque pas tant que ça aux logiciels concernant les marchés où se retrouvent majoritairement utilisés les Mac et les appareils iOS. Mais bien sûr, on peut aussi se dire que ça limite l’extension à d’autres domaines. Cela dit, de mon point de vue, la quantité de code spécifique à écrire est relativement faible et pas bien gênante. Ce n’est que mon point de vue, et ça ne cherche pas à excuser l’abandon d’EOF par Apple (comme l’a fait remarquer IGerard, NeXT disposait de cette solution, bien avant l’époque de LINQ) — c’est juste pour dire que les contraintes résultant de cet abandon ne me paraissent pas insurmontables et ne représentent pas pour moi une [u]grosse[/u] lacune de Cocoa. Je n’aurais bien sûr rien contre le comblement de cette lacune, si petite qu’elle soit. « Pour l'exemple, on peut faire plus court comme tu l'as fait effectivement (en perdant en lisibilité cependant) » Par rapport au code que tu avais donné (et qui était artificiellement gonflé en incluant des choses non présentes dans la version LINQ), je trouve au contraire qu’on gagne en lisibilité (à condition d’opter pour la version en deux lignes que je suggérais). Et je trouve aussi qu’on gagne en lisibilité par rapport à la version LINQ, en fait.

@BeePotato Grosse lacune pour le développement de solutions destinées aux entreprises, j'en suis convaincu. Ensuite que ces solutions n'intéressent pas vraiment Apple je peux comprendre. Le manque n'est pas insurmontable comme tu le dis, on peut tout écrire sois-même quand on a le temps. Cependant les entreprises ne raisonnent pas vraiment comme ça. Et dans ce cas pourquoi s’embêter à développer des softs pour Mac ? Ben tiens c'est justement le fond du problème non ? Je vais retourner ton argument contre toi : l'utilisation de Windows à la place d'OSX n'est pas insurmontable à ce que je sache. On peut aller loin comme ça... Quand au fait que la version NSPredicate soit plus lisible que la version LINQ c'est une question subjective moi je trouve que c'est l'inverse... passons, c'est pas ce qui est le plus important. Personnellement j'aimerai bien un jour avoir l'occasion, de pars mon travail, d'écrire des applications natives pour OSX. Et bien ça n'en prend pas le chemin, et c'est dommage car j'adore ça.

@françois bayrou : c'est clair on a un vrai pro ;) LoL Un dîner un soir .... Ok je ->

@treizep : c'est Claude on voit clairement qui sait de quoi il parle La grosse baffe en clair ;)

@BeePotato : c'est une bataille rangée la LoL Au final votre égo se sent mieux ? Sinon pour ce qui est du sujet, Java c'est pas super car côté gestion mémoire ça ne nous apprend pas la rigueur Le C et C++ pardonne moins les "oubliés" c'est donc mieux je trouve (avis perso) M'enfin quand on voit les jeunos sortir des IUT ou on apprend du Java et que l'on compare à ce que l'on savait à leur âge ASM & Co ça fait quand même un peu peur ;( On fait dans la quantité, plus vraiment dans la qualité sniffff

@ treizep : « Grosse lacune pour le développement de solutions destinées aux entreprises, j'en suis convaincu. Ensuite que ces solutions n'intéressent pas vraiment Apple je peux comprendre. » Oui, c’est ce que je sous-entendais (en ne le disant sans doute pas bien clairement) : ce n’est pas une grosse lacune pour Cocoa du fait que ce framework n’est pas (plus) utilisé pour des développements d’applis accédant directement aux bases de données — des applis internes d’entreprises, quoi. Et manifestement Apple n’est pas intéressée par ce marché ces jours-ci et ne considère donc pas ça non plus comme une grosse lacune. Et, comme je le disais déjà dans mon précédent commentaire, il y a un effet d’œuf et de poule qui fait que ce genre de lacune ne favorisera pas l’installation sur ce genre de marchés. Cependant, on peut comprendre Apple en considérant qu’il y a beaucoup d’autres facteurs que celui-ci qui font que les Mac ne sont pas souvent achetés par les entreprises pour ce genre d’utilisation, du coup l’effort fourni pour combler cette lacune ne servirait pas à grand chose. Bref, on est bien d’accord : « grosse », c’est subjectif. « Je vais retourner ton argument contre toi : l'utilisation de Windows à la place d'OSX n'est pas insurmontable à ce que je sache. » Ah, si, tout de même ! :) « Personnellement j'aimerai bien un jour avoir l'occasion, de pars mon travail, d'écrire des applications natives pour OSX. Et bien ça n'en prend pas le chemin, et c'est dommage car j'adore ça. » Je comprends parfaitement ce point de vue, et je suis tenté de dire : « pareil pour moi ». Même si en fait, j’ai bien plus de latitude dans mon boulot pour faire de développement en Cocoa. Mais il n’y en a jamais assez. ;)

« Quand au fait que la version NSPredicate soit plus lisible que la version LINQ c'est une question subjective moi je trouve que c'est l'inverse... » Ben je trouve que, quand on ne connaît rien du tout à LINQ et qu’on lit une ligne où un Where(@"Id") semble devoir travailler sur le résultat d’un Select(@"Name"), dont on s’attend donc naturellement à ce que ça ne contienne plus que des noms et non des ID, ça ne paraît pas logique. C’est en ce sens que je trouve ça moins lisible — le choix de syntaxe est bizarre.

@BeePotato Comme quoi on a réussi à trouver un terrain d'entente ;) Ca fait plaisir de pouvoir développer ses arguments sans tomber dans les raccourcis et le trollage n'empêche :) Concernant la syntaxe de LINQ elle ne fait que me rappeler celle de SQL qui elle non plus ne semble pas toujours très naturelle en fait ^^

@ treizep : « Concernant la syntaxe de LINQ elle ne fait que me rappeler celle de SQL qui elle non plus ne semble pas toujours très naturelle en fait » C’est l’avantage de LINQ : pouvoir se lire comme du SQL. Mais je trouve aussi que c’est du coup un inconvénient, parce l’ordre en devient moins logique pour des appels de méthodes.

@ ckjbeos : « c'est une bataille rangée la LoL » Non non, on discute calmement. Et ça a bien l’air d’être comme ça que l’a interprété treizep. « Au final votre égo se sent mieux ? » Ni mieux, ni moins bien — mon égo se porte naturellement bien, il n’a pas besoin d’être regonflé à coups de commentaires sur MacGénération. :-)

@ treizep : « Ca fait plaisir de pouvoir développer ses arguments sans tomber dans les raccourcis et le trollage n’empêche » Ben dès lors que la discussion se fait entre gens aiment développer avec Cocoa, ça ne peut être qu’une discussion sereine et posée entre personnes de qualité. ;-) (je profite de ce qu’il ne doit plus rester grand monde ici pour éviter d’être contredit…)