# Quel language pour developper sur iMac ?



## secretman (18 Octobre 2008)

Bonjour,

Je suis developpeur Windows et je passe bientôt et définitivement sur Mac après 20 ans de PC (a cause de cette m... de Vista : trop c'est trop !)

Je développe sous Delphi (pascal objet) et je connais le Basic.
Que me conseillez vous en dehors du C (j'abborrhe le C et ses dérivés  !)

- J'ai entendu parler de REALBasic Pro,  est-il bien ? pas trop limité ?
- et aussi de FreePascal et Lazarus qui permettent ensemble de développer sous Mac avec une interface à la Delphi (un clone libre).

Faites moi par de vos conseils et de votre expérience dans ce domaine.

A bon entendeur,

Denis


----------



## Dr_cube (18 Octobre 2008)

Salut, 

Si t'aime le C, tu peux passer à Objective-C et apprendre Cocoa. Bon ce n'est pas très connu et pas très utilisé sur Mac, mais ça devrait quand même te satisfaire ^^.


----------



## Mala (18 Octobre 2008)

Dr_cube a dit:


> Si t'aime le C, tu peux passer à Objective-C et apprendre Cocoa.



*abhorrer*, verbe transitif
Sens:  Exécrer, avoir en horreur quelqu'un ou quelque chose [Littéraire]. 
Synonyme: abominer.




Dr_cube a dit:


> Bon ce n'est pas très connu et pas très utilisé sur Mac, mais ça devrait quand même te satisfaire ^^.


Juste utilisé par tous les bestsellers sous OSX mais après...

Il y a des fois où je me demande si certains qui écrivent sur ce forum ont réellement un Mac.


----------



## arcank (18 Octobre 2008)

Heu... il vient de dire qu'il a horreur du C...

Et c'est vrai que Objective-C et Cocoa sont pas très utilisés et reconnus sur Mac  ?


----------



## Dr_cube (18 Octobre 2008)

J'ai lu trop vite son message, et j'ai donc lu "adore" au lieu de "abhorre". 

Concernant l'Objective-C, il s'agissait d'une boutade, visiblement incomprise. Evidemment que Objective-C / Cocoa est le langage indispensable par excellence sur Mac OS X ! 

Du coup je n'ai pas d'autres langage à conseiller. Mais je pense qu'il ne faut pas se fermer à l'Objective-C sous prétexte qu'il s'agit d'une extension du C. 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. Les outils de développement fournis sont très agréables. 
Bref, je te conseille de te diriger vers l'Objective-C en faisant fi de ton abhorration (injustifiée !) pour le langage C.


----------



## ntx (18 Octobre 2008)

secretman a dit:


> Je développe sous Delphi (pascal objet) et je connais le Basic.
> Que me conseillez vous en dehors du C (j'abborrhe le C et ses dérivés  !)
> 
> - J'ai entendu parler de REALBasic Pro,  est-il bien ? pas trop limité ?
> - et aussi de FreePascal et Lazarus qui permettent ensemble de développer sous Mac avec une interface à la Delphi (un clone libre).


Tout dépend de ton but : juste pour le fun ou à des fins professionnelles ?

Pour le fun trouve toi quelque chose de gratuit : je ne sais pas s'il y a encore une licence de RealBasic gratuite, sinon le Java à moins que tu ne le classes dans les dérivés du C :rateau:

A des fins plus pécuniaires : désolé mais ce sera avant tout le C, le C et encore le C et son dérivé de prédilection sur Mac OSX l'objective-C. Cocoa est *LE* framework pour faire des applications parfaitement intégrées à Mac OSX. Pas de chance si tu n'aimes pas ce langage car c'est la norme choisie par toutes les sociétés faisant des OS (Unix et Windows) et donc les API pour ces OS. 
Après si tu choisis d'utiliser des API plus "génériques" et moins bien intégrées à l'OS, surtout sur Mac : le Java.


----------



## secretman (18 Octobre 2008)

merci pour vos conseils. Je résume : le C, rien que le C !
Personnellement je trouve que c'est un language trop matheux pour moi, sa lecture est trop abstraite et pas évidente. Je jeterais un coup d'oeil sur objective C...

Néanmoins si vous avez une autre expérience que le C, n'hésitez pas à m'en faire part ici même. Je suis ouvert à toute suggestions.


Denis


----------



## p4bl0 (18 Octobre 2008)

secretman a dit:


> merci pour vos conseils. Je résume : le C, rien que le C !
> Personnellement je trouve que c'est un language trop matheux pour moi, sa lecture est trop abstraite et pas évidente. Je jeterais un coup d'oeil sur objective C...
> 
> Néanmoins si vous avez une autre expérience que le C, n'hésitez pas à m'en faire part ici même. Je suis ouvert à toute suggestions.
> ...


On te parle pas de spécialement de C mais de Obj C, qui est une surcouche qui amène BEAUCOUP de chose .
Mais tu peux aussi faire du Cocoa en Python, Ruby, JavaScript depuis moins longtemps... (il y a des binding qui existe pour ces langages).

Puis il y a Qt, Wx, GTK (dans X11) etc qui tourne aussi sur OS X mais seront moins dans le look'n'feel de l'OS.
Tu peux coder dans n'importe quel langages, celui que tu connais déjà c'est pas mal ^^ (REALBasic ? Mais bon ça c'est pas libre :-/).

Le C n'est pas abstrait bien au contraire, c'est ça qui le rend peut-être un peu moins facile à lire que d'autre langage, et encore...


Mais tout ça dit, si tu veux faire une appli OS X "parfaite", tu n'échappera pas à ObjC / Cocoa. C'est comme ça .


----------



## phiel13 (18 Octobre 2008)

secretman a dit:


> Personnellement je trouve que c'est un language trop matheux pour moi, sa lecture est trop abstraite et pas évidente. Je jeterais un coup d'oeil sur objective C...
> Denis



Trop matheux le C, n'exagérons rien , c'est plutôt un langage économique pour le compilateur. Non... un langage théorique, matheux et beau c'est (c'était ) ADA. D'un autre côté, ADA pour développer des applications graphiques ..bof...


----------



## Dr_cube (18 Octobre 2008)

Trop matheux ? 
Encore un qui n'est pas passé sous les fourches caudines d'Objective Caml ou de Prolog !! 
Le C est très proche de la machine, et se pose à un très faible niveau d'abstraction. C'est certainement ce côté "bidouille", "mains dans le cambouis" qui te repousse avec le C. Mais avec Objective-C et Cocoa on ne rencontre que rarement ces problèmes. Tout ce qui est bas niveau est fait pour nous dans des Frameworks de plus haut niveau. Tout ce qu'on a à faire c'est comprendre comme agencer des blocs, et les empiler, parfois les étendre. 
C'est assez rare qu'on soit obligé de retomber dans les bas fonds de la machine. Peut-être pour certaines applications réseaux, et encore.. 

Pour ce qui est d'Ada, je ne pense pas que ce soit plus "matheux" que le C, mais ça fait appel à bien plus de rigueur, c'est évident. Mais c'est en effet pas vraiment fait pour les applications graphiques. Mais beaucoup de voitures ou de machines de ce genre sont programmées en Ada. Si tu veux faire de l'embarqué, apprend l'Ada !


----------



## phiel13 (18 Octobre 2008)

Dr_cube a dit:


> Trop matheux ?
> 
> Pour ce qui est d'Ada, je ne pense pas que ce soit plus "matheux" que le C, mais ça fait appel à bien plus de rigueur, c'est évident. Mais c'est en effet pas vraiment fait pour les applications graphiques. Mais beaucoup de voitures ou de machines de ce genre sont programmées en Ada. Si tu veux faire de l'embarqué, apprend l'Ada !



Des voitures je crois pas, mais les calculateurs d'Ariane, du rafale , du char leclerc sûrement.  Sans bien sûr parler des programmes américains  (boeing 777) , après tout ce sont eux qui avait lancé l'appel d'offre gagné par l'équipe d'Ichbia (décédé depuis) ....


----------



## BS0D (18 Octobre 2008)

Dr_cube a dit:


> Le C est très proche de la machine, et se pose à un très faible niveau d'abstraction. C'est certainement ce côté "bidouille", "mains dans le cambouis" qui te repousse avec le C. Mais avec Objective-C et Cocoa on ne rencontre que rarement ces problèmes. Tout ce qui est bas niveau est fait pour nous dans des Frameworks de plus haut niveau. Tout ce qu'on a à faire c'est comprendre comme agencer des blocs, et les empiler, parfois les étendre.
> C'est assez rare qu'on soit obligé de retomber dans les bas fonds de la machine. Peut-être pour certaines applications réseaux, et encore..
> 
> Pour ce qui est d'Ada, je ne pense pas que ce soit plus "matheux" que le C, mais ça fait appel à bien plus de rigueur, c'est évident. Mais c'est en effet pas vraiment fait pour les applications graphiques. Mais beaucoup de voitures ou de machines de ce genre sont programmées en Ada. Si tu veux faire de l'embarqué, apprend l'Ada !


 
Je suis pas du tout d'accord. Le C, comme le C++, sont des langages évolués et ils sont loin d'être près de la machine. 
J'en sais quelque chose car j'ai lontemps codé en ASM. Là, on est proche de la machine. 
Surement la raison poru laquelle le C ne m'a JAMAIS correspondu, et je n'ai jamais rien su faire de bien évolué avec. Ca me chagrine, mais c'est comme ça, j'ai pas du tout la logique qu'exige ce langage, alors qu'en ASM j'avais absolument aucun problème.

Quant à l'aspect "rigueur", n'importe quel langage l'impose. Rigueur, attention et persevérance.


----------



## Céroce (19 Octobre 2008)

BS0D a dit:


> Je suis pas du tout d'accord. Le C, comme le C++, sont des langages évolués et ils sont loin d'être près de la machine.
> J'en sais quelque chose car j'ai lontemps codé en ASM. Là, on est proche de la machine.



Eh bien moi, je suis tout à fait d'accord. Si le C n'était pas un langage proche de la machine, il n'existerait pas 8 types d'entiers (char, short, long, long long, et toutes leurs versions non signées).

Pour tenter de répondre à la question de départ:
- RealBasic, c'est du Visual Basic, version Mac, avec les mêmes qualités (prise en main facile) et les mêmes défauts (syntaxe horrible, difficulté à organiser des programmes conséquents) que Visual Basic.
- le couple Python + QT est sympa, mais certainement pas aussi intégré que Delphi. Python n'est pas un langage ni matheux, ni trop proche de la machine, mais il est plutôt lent (langage interpreté). Pareil pour Ruby.
- ObjC + Cocoa: Difficile d'accès, nécessite effectivement de bien connaître le C. La solution la plus adaptée aux gros développements pour Mac, mais sa portabilité est nulle.

Il y a encore d'autres solutions, mais on en revient à une des premières questions posées: "c'est pour en faire quoi ?".


----------



## p4bl0 (19 Octobre 2008)

BS0D a dit:


> Je suis pas du tout d'accord. Le C, comme le C++, sont des langages évolués et ils sont loin d'être près de la machine.
> J'en sais quelque chose car j'ai lontemps codé en ASM. Là, on est proche de la machine.
> Surement la raison poru laquelle le C ne m'a JAMAIS correspondu, et je n'ai jamais rien su faire de bien évolué avec. Ca me chagrine, mais c'est comme ça, j'ai pas du tout la logique qu'exige ce langage, alors qu'en ASM j'avais absolument aucun problème.
> 
> Quant à l'aspect "rigueur", n'importe quel langage l'impose. Rigueur, attention et persevérance.


Le C pas proche de la machine ?

Ok on gère pas les cycle d'horloge ni dans quel secteur de quel block (à moins que ce ne soit quel block de quel secteur ?) on va écrire sur le disque. Mais bon à part l'assembleur il y a très peu de langage plus abs niveau que le C non ?

Et puis va écrire une appli Cocoa en asm 


Au passage pour les fan d'assembleur, vous connaissez Menuet ? C'est pas libre :-/ Mais c'est impressionnant ! Un OS avec interface graphique et tout qui tient sur une disquette et qui est entièrement codé en assembleur !


----------



## secretman (19 Octobre 2008)

J'entend parler beaucoup de Qt : Qu'est-ce exactement  ?

Wx, GTK (dans X11) ??? merci de préciser que quoi vous parlez. Je ne suis pas un pro de la programmation sinon je ferais du Objective-C !

Mon but est de développer des utilitaires du genre Gratuiciel, dans de nombreux domaines en général en rapport avec la sécurité informatique ou l'anonymat des internautes (fichiers cachés, effacement sécurisé des traces, etc)

Querlqu'un connait le couple Lazarus/Free Pascal ? Ca tiens la route sur Mac ?

Merci de vos nombreuses contributions,

Denis


----------



## ntx (19 Octobre 2008)

Qt, WxWidget et GTK sont des librairies C et C++ multi-plates-formes qui permettent de créer des applications utilisables sur Mac OSX (sauf GTK, bof sur Mac), Linux et Windows. Mais encore une fois, si c'est pour faire une application purement Mac, rien ne remplace Cocoa.

De toutes façons ce que tu cherches à faire sera difficilement portable car chaque OS ou application web gère différemment ces aspects.


----------



## phiel13 (19 Octobre 2008)

J'imagine que l'assembleur est de moins en moins utilisé, pour des raisons de portabilité, et par la difficulté de réaliser des programmes sophistiqués. Je pense qu'aujourd'hui, la plupart des systèmes d'exploitation l'utilisent peu


----------



## BS0D (19 Octobre 2008)

phiel13 a dit:


> J'imagine que l'assembleur est de moins en moins utilisé, pour des raisons de portabilité, et par la difficulté de réaliser des programmes sophistiqués. Je pense qu'aujourd'hui, la plupart des systèmes d'exploitation l'utilisent peu


 
C'est vrai qu'il est de moins en moins utilisé. Ce que je trouve regrettable , mais ça ne tient qu'à moi. C'est tellement fun de programmer en ASM!


----------



## tatouille (20 Octobre 2008)

phiel13 a dit:


> J'imagine que l'assembleur est de moins en moins utilisé, pour des raisons de portabilité, et par la difficulté de réaliser des programmes sophistiqués. Je pense qu'aujourd'hui, la plupart des systèmes d'exploitation l'utilisent peu



l'assembler c'est pour l'  instruction par instruction
mais bon au final c'est en ca que ton compiler traduit

la portabilite a ete regle depuis bien longtemps il y a des outils permettant de targeter pour differentes familles, c'est juste que si tu ecris tout en assembler ce n'est pas tres maintenable et au final tres limite j'aimerais bien vous voir ecrire un framework comme cocoa avec un l2g , bien que l'asm reste tres utilise pour certain tasks

pour le C je vois pas ce que tu appeles matheux? les pointeurs?


----------



## p4bl0 (20 Octobre 2008)

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 !


----------



## phiel13 (21 Octobre 2008)

tatouille a dit:


> 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...


----------



## tatouille (23 Octobre 2008)

les pointeurs c'est l'axe du mal



p4bl0 a dit:


> Pourquoi avoir peur des pointeurs  :
> Les pointeurs regarde TF1
> Les pointeurs violent des grand-mères
> Les pointeurs sont à l'origine de la crise
> ...


----------



## Rez2a (4 Décembre 2008)

Désolé de remonter ce topic, mais voilà j'étais obligé de poser la question : 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 ?
J'ai juste horreur du C, et comme vous l'avez dit, des pointeurs... autant ça me dérange pas de coder en Java, autant les pointeurs c'est vraiment ma hantise... 
J'ai survolé XCode pour voir à quoi ça ressemblait, et j'en attendais pas moins d'Apple, ça a l'air très ergonomique, agréable, élégant... mais bon voila.

Et puis quand je lis ceci :



> 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.



Ca me laisse un espoir... l'Objective-C est vraiment différent du C à ce point-là ?
Différent dans le sens, pas de pointeurs ?


----------



## ntx (4 Décembre 2008)

Rez2a a dit:


> 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 ?


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.


> Ca me laisse un espoir... l'Objective-C est vraiment différent du C à ce point-là ?
> Différent dans le sens, pas de pointeurs ?


En Obj-C tous les objets sont des pointeurs 
Si tu n'aimes pas le C, tu n'aimeras pas plus l'Obj-C.


----------



## Rez2a (4 Décembre 2008)

ntx a dit:


> 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...


----------



## tatouille (5 Décembre 2008)

Rez2a a dit:


> 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


----------



## Rez2a (5 Décembre 2008)

tatouille a dit:


> 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



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...
Pour mon "blocage psychorigide d'ado", je vais juste te dire que de mon point de vue, en ayant programmé qu'en Java, c'est pas forcément le concept le plus simple que j'ai vu oui. 
Mais je vais faire un effort et m'y remettre, si y'a que ça pour profiter des CoreAnimation & cie...


----------



## ntx (5 Décembre 2008)

Rez2a a dit:


> 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...


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.
En fait je trouve que les philosophies de l'Obj-C/Cocoa et du Java sont très proches, il y a juste les notions de référence/valeur et de gestion de la mémoire par compteur d'instance qui sont visibles en Obj-C et masquées en Java.
Le pointeur est juste un moyen pratique de retrouver une variable dans la mémoire utilisée par l'application, ni plus ni moins.


----------



## Céroce (5 Décembre 2008)

Sinon, arrêtez de conseiller "Cocoa par la pratique", (2ème édition du livre d'Aaron Hillegass) et conseillez plutôt Programmation Cocoa sous Mac OS X (qui correspond à la 3ème édition).


----------



## damien_t (7 Décembre 2008)

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é.


----------



## grumff (8 Décembre 2008)

damien_t a dit:


> 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) *
> 
> ...


Y'a quand même quelques différences non négligeables entre des langages interprétés et des langages compilés...


----------



## damien_t (8 Décembre 2008)

grumff a dit:


> Y'a quand même quelques différences non négligeables entre des langages interprétés et des langages compilés...


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)


----------



## Céroce (8 Décembre 2008)

damien_t a dit:


> 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é.


----------



## damien_t (8 Décembre 2008)

Céroce a dit:


> 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é.



Les macs actuels ont largement la puissance pour compenser une légère perte de perfomances dues à un langage interprété. Et comme tu le dis, utiliser PyOBjC ou RubyCocoa ne transforme pas magiquement Cocoa en un framework interprété. Toutes les opérations lourdes réalisées par Cocoa (création d'une fenêtre par exemple) exécutent le code compilé du framework.

Les développeur de CheckOut (logiciel de point de vente) dit :



> He adds, Python uses automatic reference counting (similar to garbage collection), meaning fewer lines of codefewer 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 its 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 its slower, by nature, than a compiled language like Objective C. But the speed of the Intel Macs really counters the difference. Checkout itself is a Universal application. It screams on Intel Macs.​In fact, since most of the heavy lifting in Checkouts interface is done by Apples 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.​


 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)


----------



## tatouille (8 Décembre 2008)

damien_t a dit:


> ...


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


----------



## grumff (8 Décembre 2008)

damien_t a dit:


> Les macs actuels ont largement la puissance pour compenser une légère perte de perfomances dues à un langage interprété.


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.


----------



## damien_t (8 Décembre 2008)

tatouille a dit:


> 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



Je ne comprends pas : 
Le contributeur original disait : "Je ne suis pas un pro de la programmation sinon je ferais du Objective-C !

Mon but est de développer des utilitaires du genre Gratuiciel, dans de nombreux domaines en général en rapport avec la sécurité informatique ou l'anonymat des internautes (fichiers cachés, effacement sécurisé des traces, etc)"

Il me semble que dans ce cas précis, PyObjC ou RubyCocoa se défendent. Je n'ai jamais dit qu'il fallait absolument utiliser Python + Cocoa pour les projets de grande envergure. Juste que pour les petits utilitaires dont la très grande majorité du temps est passée à attendre, Ruby ou Python (ou pourquoi pas AppleScript Studio) ne doivent pas être écartés juste parce que ce sont des langages interprétés. Il y a d'autres facteurs à intégrer (le temps de dév, la facilité d'apprentissage, la maturité du langage ou bridge, la qualité de la doc et des outils, le support officiel d'Apple). Là encore, certains langages traditionnellement ignorés peuvent convenir.

Je trouve également que je vais plus vite en ObjectiveC qu'en Ruby pour faire des choses compliquées, que les patterns présents dans Cocoa sont très bien faits (bien que très touffus), mais tout le monde n'a pas forcément envie ou le temps d'apprendre les subtilités du rôle de la signature d'un sélecteur dans l'implémentation des NSInvocations en ObjectiveC +Cocoa.

Bon, demain, je dépoussière mon Common Lisp + Cocoa. Cette combinaison de d'amour contre nature et franchement improblables me fera plaisir. Et j'optimiserai les parties lentes en assembleur


----------

