la portabilite a ete regle depuis bien longtemps il y a des outils permettant de targeter pour differentes familles
Oui a condition d'utiliser un langage au dessus de l'assembleur, c'est ce que je voulais dire...
la portabilite a ete regle depuis bien longtemps il y a des outils permettant de targeter pour differentes familles
Pourquoi avoir peur des pointeurs :
Les pointeurs regarde TF1
Les pointeurs violent des grand-mères
Les pointeurs sont à l'origine de la crise
Les pointeurs mangent des enfants
Les pointeurs rendent stérile
Les pointeurs nuit à votre entourage
Les pointeurs n'aiment pas les animaux
À vous !
PS: en vrai, les pointeurs ne me dérange pas du tout, au contraire !
En effet, bien que l'Objective-C reprenne la syntaxe du C, la programmation est généralement à un tout autre niveau d'abstraction, ce qui rend les choses beaucoup plus simples. La couche objet de l'Objective-C est très intéressante.
Obj-C + Cocoa est l'idéal, après il y a d'autres solutions qui sont plus éloignées de l'idéal : Java, Python, ... mais il sera plus difficile d'obtenir des applications avec le "look and feel" Apple.j'aimerais vraiment développer des logiciels sur Mac mais, il n'y a vraiment que Cocoa/Objective-C qui permettent de faire des logiciels viables ?
En Obj-C tous les objets sont des pointeursCa me laisse un espoir... l'Objective-C est vraiment différent du C à ce point-là ?
Différent dans le sens, pas de pointeurs ?
Obj-C + Cocoa est l'idéal, après il y a d'autres solutions qui sont plus éloignées de l'idéal : Java, Python, ... mais il sera plus difficile d'obtenir des applications avec le "look and feel" Apple.
En Obj-C tous les objets sont des pointeurs
Si tu n'aimes pas le C, tu n'aimeras pas plus l'Obj-C.
Aie aie aie...
Eh bien merci pour la réponse rapide, au moins j'aurais pas eu le temps de me faire de faux espoirs !
Je vais quand même essayer de me trouver un peu de doc sur Obj-C, qui sait, peut être que les pointeurs me parleront un peu plus maintenant qu'il y a deux ans...
achete cocoa part la pratique et arrete ton blocage psychorigide d'ado sur les pointers
les pointers c'est des adresses c'est tout et en C LA VALEUR ET L'ADDR ne sont parfois pas si eloignee, c'est tres pratique d'avoir des addresses quand tu telephones/email/courrier, t'es content de ne pas te taper un porte a porte pour communiquer avec les gens ou prendre l'avion ecetera?
si tu veux t'eclater sur macos obj-c coreanimation opengl a volonter
speech sound 2d graphic whatever
Si tu as fais du Java et que tu connais la notion de pointeurs, je pense que tu as le niveau pour Cocoa par la pratique.Pour le bouquin j'avais justement lu que c'était destiné à des programmeurs qui connaissent déjà le C justement, après si tu me dis qu'il est compréhensible en ayant un niveau correct en prog hors C je veux bien te croire...
Y'a quand même quelques différences non négligeables entre des langages interprétés et des langages compilés...Je ne comprends pas pourquoi RubyCocoa (ou Python) ne convient pas. Y'a tout le framework Cocoa, sans la syntaxe du [Objective-]C. Je trouve la syntaxe de l'Objective-C tout à fait honnete, mais c'est pas le débat.
A mon humble avis, la syntaxe du Ruby est a pleurer de bonheur (zen, simple, élégante, courte, claire). De ce que j'en ai compris, Apple est en train de pousser ces bridges plutot qu'AppleScript. Les modèles d'application de base sont meme dispo dans XCode (reférences : Scripting Cocoa, Ruby and Python Programming Topics for Mac OS X, Scripting Bridge Programming Guide for Cocoa)
D'ailleurs, cela me fait penser qu'il existe également un AppleScript Studio. J'ai jamais compris le rapport entre Interface Builder / XCode / AppleScript Studio, mais ca permet de faire des applis relativement compliquées. Par contre, pour la syntaxe, AppleScript, comment dire..., je le met au meme niveau que VBA.
Y'a de quoi faire quand meme pour ceux veulent Cocoa sans le language traditionnellement associé.
Désolé, je m'étais pas apercu de cette préférence. Mais pour des petits programmes utilitaires, Ruby ou Python suffisent largement, sachant que 99% du temps CPU se fera à attendre les actions de l'utilisateur (raisonnement valable pour les langages compilés aussi)Y'a quand même quelques différences non négligeables entre des langages interprétés et des langages compilés...
La question n'est pas là. Le but c'est que l'utilisateur n'attende pas, les rares fois où il lance un calcul. Par contre, ce qu'on peut dire, c'est que l'essentiel du code est constitué d'appels à des API, dont la vitesse d'exécution ne dépend pas du langage utilisé.sachant que 99% du temps CPU se fera à attendre les actions de l'utilisateur
La question n'est pas là. Le but c'est que l'utilisateur n'attende pas, les rares fois où il lance un calcul. Par contre, ce qu'on peut dire, c'est que l'essentiel du code est constitué d'appels à des API, dont la vitesse d'exécution ne dépend pas du langage utilisé.
Par ailleurs, l'avantage d'utiliser un langage de haut niveau (Python ou Ruby sont de plus haut niveau qu'Objective-C), c'est qu'il fournit les abstractions commodes pour travailler sur le principal facteur de la vitesse d'exécution: l'algorithme utilisé.
C'est un testimonial Apple à prendre avec des pincettes, mais j'ai essayé l'application. Elle est tout à fait réactive. Notamment, les recherches, les tris, l'affichage graphique se font à la même vitesse qu'une application Cocoa / Objective-C (avis subjectif)He adds, Python uses automatic reference counting (similar to garbage collection), meaning fewer lines of codefewer than Objective C and plain C. Plus, you can also build on an enormous number of great Python libraries to save work. For example, Checkout relies on open-source Python libraries to connect to the underlying database. And although its more of a personal preference, Python syntax is very readable and easy to maintain.The performance of PyObjC applications is excellent. Dirk explains, Python is interpreted, so its slower, by nature, than a compiled language like Objective C. But the speed of the Intel Macs really counters the difference. Checkout itself is a Universal application. It screams on Intel Macs.In fact, since most of the heavy lifting in Checkouts interface is done by Apples highly optimized drawing code, any sluggishness is negligible. And in some cases, Python is even faster if you use a framework implemented in raw C, such as cPickle, which serializes and unserializes Python objects. However, in a small number of cases, user interface object subclasses were converted to Objective C.
Chers Damien je suis d'accord avec toi mais permet moi de faire quelques commentaires en tant qu'auteur de python application stub, avec lequel j'ai une legere experience concernant ceci , pyOBjc et plus lent que wxpython sans aucune mesure, toutes les features ne sont pas accessibles , et il y a une collection de leaks irresolvables par le dev car etant python internal, je m'amuse avec pyObjc mais je ne l'utileiserais jamais ds l'etat actuel pour une grosse appli, de plus il est plus rapide de dev en cocoa-obj-c qu'en python objc, et ce n'est pas 64-bit capable comme coreanimation par ailleurs
Certes, enfin tout dépend de l'application tout de même, et même en ayant des perfs correctes sur la plupart des traitements, on a vite fait de dégrader la réactivité, ce qui est particulièrement agaçant pour l'utilisateur.Les macs actuels ont largement la puissance pour compenser une légère perte de perfomances dues à un langage interprété.
Chers Damien je suis d'accord avec toi mais permet moi de faire quelques commentaires en tant qu'auteur de python application stub, avec lequel j'ai une legere experience concernant ceci , pyOBjc et plus lent que wxpython sans aucune mesure, toutes les features ne sont pas accessibles , et il y a une collection de leaks irresolvables par le dev car etant python internal, je m'amuse avec pyObjc mais je ne l'utileiserais jamais ds l'etat actuel pour une grosse appli, de plus il est plus rapide de dev en cocoa-obj-c qu'en python objc, et ce n'est pas 64-bit capable comme coreanimation par ailleurs