Quel language pour developper sur iMac ?

[phiel13]

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]

les pointeurs c'est l'axe du mal

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 !

 

[Rez2a]

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]

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]

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]

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]

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]

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]

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]

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]

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

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

 

[damien_t]

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]

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]

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]

...

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]

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]

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